Unanswered questions

Our operations email is basically a distribution list that consist of our shared mailbox + archiving backend.  We would like to take advantage of the auto reply feature on FRONT.Has anyone found a good workaround, or an easy way to automate replies when there’s a distribution list in the recipients field?

We use Front MCP (mcp.frontapp.com) from an inbox agent (Pit Bot / grok@xxx.com) Workflow: a teammate @mentions the agent in a Front comment and asks for a fairing-kit mockup. The agent generates a PNG and needs to post it as an internal comment on that same conversation, visible to CS, not to the customer.What we tried: add_comment with conversationId + body. The MCP schema only has those two fields. get_attachment can download comment images, but nothing can upload them.What we expected: add_comment to take an attachments list, same as Core API POST /conversations/{id}/comments which already documents attachments as multipart/form-data, max 25 MB (https://dev.frontapp.com/docs/attachments-1). Teammates already attach images to comments in the Front UI (we do this daily with color swatches).What happened: we can only post text. We have to drop the mockup in a side chat and ask a human to attach it on the thread. That breaks the workflow.Ask: please add an attachments argument on add_c

I'm currently working through Front onboarding and have only seen the platform through the training exercises so far.One thing I'm curious about is how experienced teams decide when to create new rules, tags, or automations versus keeping things manual. The examples in training make sense, but I imagine real environments can become complex pretty quickly.For those who manage Front long-term, what are some "lessons learned" or best practices you wish you had known when setting up workflows for the first time?

When Claude creates a reply draft through the Front MCP server, the draft contains only the body text - no quoted thread history and no signature. Front's own Reply button adds both.The Core API already supports this. POST /conversations/{id}/drafts accepts quote_body, signature_id and should_add_default_signature. The MCP create_draft and update_draft tools expose none of them, so an AI-created draft can never match what Front itself produces.Separately, there is no way to create a forward at all: no forward endpoint exists in the Core API, only in the Plugin SDK (Front.forward() / replyOptions.type: "forward"), which requires a plugin running in the Front UI.Impact: I have to re-add the quoted history and my signature by hand on every AI-drafted reply. The manual rework defeats the purpose of the integration - it is faster to skip the connector and hit Reply.Asks: (1) expose quote_body, signature_id and should_add_default_signature in create_draft and update_draft, ideally with quoti

Hi guysWe have unique use case where we have certain Mentors on our platform + their respective VAs, VAs go through their inbox and support our customers. Here is the structure:We treat their personal inboxes (Mentors) as support inboxes, the Mentees are our customers essentially. Currently mirroring the mentor convos into shared inboxes and only capturing mentee comms using our CRM integration and custom fields + rules.Was wondering if there’s a way that we can leverage Front AI to automatically segment normal conversations from actual tickets and tag them, actual concerns raised by the mentees.We are currently using conversation custom dropdown fields to automatically move convos to a general/no escalation inbox (e.g Conversation Type = Ticket/Conversation)

Anyone know where I can find a Front Consultant?  Front was already in place when I started here about two years ago and has been problematic since day one.  Our Front setup is a hot mess and generates way too many helpdesk tickets for all kinds of different reasons.  I really need someone that can look at our setup, analyze it, suggest and make changes.  I’m an IT Manager but I don’t have the bandwidth to revamp our whole Front setup.  A Google search turned up nothing and Front doesn’t seem to offer such a service that I can tell.  Any insight would be greatly appreciated. Thanks

I run an agency and we support many clients.  I want to be able to go to one spot and see all the emails from that company.  I had originally thought about doing this as tags. Then we made mailboxes for all the clients. This seems to be challenging though. I am seeing messages not show up in the mailboxes. I don’t think each client should have their own mailbox. How are other agencies doing this?

 Good morning,I’m trying to sync the Front conversation statuses in Front with our internal data so we can display them to our users in our app. We just need to get the Open/Waiting/Resolved value from the conversations. I'm playing with the application webhooks, as recommended in your docs, but I cannot find an event that reacts to a change in these statuses (there are some internal status changed events but for Waiting and Resolved are, internally, the same “archived” status so nothing triggers in this case). I’ve gone around this issue by creating a custom rule that adds a tag when the status changes so I can receive the “Tag added” event but then I’m getting a lot of events that are not actually changing the status… The other solution will be polling directly the API but given the API request per minute restriction, if the inflow of tickets grows it might not be realistic. Is there anything else we can do, or something that we are missing? Thanks in advance,Ruben

Hi, When did contacts become relationships? I’ve been away from the community for a while and am not up to speed on changes. Today I discovered my contacts on the right are now relationships. Sidebar still has contacts, but that is not visible or usable on the right. This didn’t seem like a big deal until I discovered you can no longer create new accounts as quickly and easily as before. We use the contacts and accounts visibility on the right all day, so this has really thrown a wrench in the works. Please tell me there is a way to fix this! 

Hello Front Community, nice to meet you all! I'm mapping out a new tagging strategy for our inbound operations. We want to ensure clean analytics without overwhelming our agents with too many manual tag choices.Currently, we are thinking about automating high-level 'Topic' tags via rules based on keywords, while leaving specific 'Sentiment' tags for agents to apply manually. For those managing high-volume inboxes, do you find it's better to keep your tag menus strictly minimal, or do you lean heavily into deep sub-tags for detailed reporting? Any tips or structure frameworks would be highly appreciated!

Does the Front MCP connector have the ability to auto-draft templates for bulk sends to a list of contacts?

Hello All,I am just getting this connector setup and the searching appears to be working as expected. However, when we ask Copilot to compose a draft it tells us that the tool is not exposed to the current session. My scope on the connector was blank but then I updated to the feature:mcp but that didn’t change anything. I asked Copilot to show me the list of tools that it is seeing and this is what it returned.  Conversation tools_search_conversations_read_conversation_read_message_list_draftsPeople / metadata tools_search_contacts_read_contact_list_inboxes_list_channels_list_tags_list_teams_list_teammates_list_statuses_search_accounts_read_account_get_my_identityNotably missing from Copilot's exposed tool list:create_draftupdate_draftsend_messagereply_to_conversationcreate_commentany other write/update operation I disconnect the session and re-connected. I can confirm that the permissions requested during the authorization show check marks for the read/write column. Is there another s

Connecting the official Front MCP (https://mcp.frontapp.com/mcp) from Cursor as a custom remote server (confidential OAuth client, no DCR). Redirect in use: http://localhost:8787/callbackFeature access: MCP onlyResource permissions: Read + Write + Send enabled on the app as a ceiling. Client requests scope=read+write only (no send on the token). Authorize returns invalid_scope: The requested scope is not supported: read, write — immediately after the company-domain screen. The same OAuth state is reused across retries even after deleting and recreating the MCP server in Cursor. app.frontapp.com/.well-known/oauth-authorization-server lists scopes_supported: ["feature:mcp"] only. Docs say MCP scopes are read, write, send. Has anyone hit this in the beta? Happy to share more details privately with Front if you need them for a per-app fix.

We have a BYO agent that can create drafts based on @-mentions in threads. Everything was working as expected for a long time, but suddenly our backend has stopped receiving webhooks since 9 am ET this morning. We validated this across multiple conversations, also ones where we knew it was working before. 

Hey everyone 👋Today we support one scorecard per workspace, and we’re working on changing that - so that you can have the flexibility of different scorecards to apply for different participants in the same conversations, with a shared criteria library to select from across your company. We’re currently exploring how to define the applicability of a scorecard, and would love your input. If you had multiple scorecards, what would be your use case / purpose for the different scorecards? How would they be ideally setup ? A scorecard per teammate group, inbox etc? 

The Front MCP to Town (town.com) connection keeps dropping, can help to troubleshoot this please? It is a critical integration for us. We need to manually reconnect it each time it drops. I’ve attached a few screenshots for reference. Thanks!  

You can now see whether a conversation is snoozed for you through the MCP server, and can snooze conversations as well. Please let us know if there are any issues using this feature!