Unanswered questions

Hi everyone,We recently rolled out Front to manage our customer support inbox, and it’s been great for collaboration — especially with assignments and shared drafts. However, one thing we’re still figuring out is how to balance teamwide visibility with clear accountability.For example, if multiple teammates jump into a thread to help, sometimes the “owner” of the conversation gets blurred. On the other hand, if we stick strictly to assignments, we lose some of the fluid teamwork that makes Front powerful.I’m curious: How do you structure ownership rules for conversations? Do you let teammates “jump in” freely, or do you enforce strict ownership until a conversation is resolved? Are there any workflows (tags, rules, or analytics dashboards) you’ve set up in Front to help track individual accountability while still encouraging collaboration? Would love to hear how other teams have struck this balance!—Do you want me to also draft a reply post that you can use to comment on someone el

So far I see only one discussion on desktop vs browser, so I am here to ask if there is a resource to give a full comparison on the differences between the two. I notice the training course deals with the web browser and I am curious how the behavior differs when creating tags. in the browser there are toggles to show in conversation and allow all inboxes. alternatively the desktop only gives an option to specify teammates that can use the tags. allowing all does not seem to be achievable efficiently. so where can i read on the distinction between applications? 

Hi Front team,We’re building a sidebar plugin that loads our plugin page https://samplesite.com/front-plugin inside the Front UI. Front adds ?auth_secret=… to our iframe URL, and we’re trying to  bootstrap the SDK per the docs:  <script src="https://app.frontapp.com/scripts/sdk.js?auth_secret=…"></script>  Our page (HTTPS, same origin as the SDK allow‑list) loads one script at a time and retries the fallback URLs:  - https://app.frontapp.com/scripts/sdk.js  - https://app.frontapp.com/plugins/sdk.js  - https://app.frontapp.com/static/frontend-plugin-sdk.js  For each request we append the auth_secret from the iframe URL. We also guard against multiple insertions, remove existing script tags, and even tried adding  type="module".  What we’re seeing  In Firefox and in Chrome the script load always fails:  - The browser console shows:    Access to script at 'https://app.frontapp.com/scripts/sdk.js?auth_secret=…' from origin 'https://www.samplesite.com' has been blocked by CORS p

Hi I’ve been struggling to have our contact list up to date and it would really help me to have the ability to mass delete auto-created contacts. Perhaps you can integrate this feature or at least allow front support to have an internal way to achieve this.

Hi, I am new to front and wanted to learn from others that have a small group of 2-5 sales reps and how they are currently using front and what type of automations are helpful to ensure a smooth customer experience while ensuring the app is being used proficiently?

Hi,In playing around with app requests, I have noticed that it’s possible to map JSON output to dynamic fields, which can in turn update a custom field on the conversation using a rule. However, this seems to only work for a single property. My question is about updating multiple custom fields on the conversation. Is it possible to update multiple custom fields in response to a single application request, without triggering duplicate app requests for each dynamic field? Or is the best approach for this use case to have my backend update the custom fields directly via an API call?For example, I would like to ping my backend with a single request to get the user’s current subscription plan and their renewal date, and update two custom fields (plan and renewal date) on the conversation without triggering a separate application request for each field. The alternative is to ping my backend once with a custom request and have the backend itself update the custom fields by hitting Front’s API

Hi, I am setting up a new support portal, and started an Enterprise Trial so that we would have access to application requests so that we can hit our custom API. After setting up an app request, testing it successfully (“Test Successful”), and the status is “Ready,” it is NOT surfacing when selecting the “Select app request” action in a new macro/rule workflow. See the screenshots below.This is the app request, showing “Ready” status: And when creating a new macro, it keeps telling me to setup a new application request, because it cannot find the ones I have created:Is there something wrong with my account setup? Why can’t I use the app requests in rules/macros?

I have customers who are filing tickets through our portal, and when they file via our help center, they are being prompted to verify their email address. They will confirm their email by clicking the button below, but will be prompted again when they submit another ticket. The customer will verify their email above, directing them to their requests.Need guidance on why this is happening and any solutions to allow customers to only verify their email once. Thank you.

I have one primary inbox with a channel setup of incoming email.  I route based on rules to a series of other Inboxes based on client’s domain from their email address.  All of the forwarded-to Inboxes work as expected except for one.  One of them, and the moved messages that land in it, does not allow me to forward or reply to the message.  The button is missing and there are no options to do so. Also, when I choose resend or forward as a new conversation, I don’t get the normal email message popup.   It feels like a rights config issue, but I’m the admin on teh account, so I’m not srue what’s missing.  Thanks in advance!

I have been using front for about a week, and initially had no topics. Then on Sept 30th, four topics were created. No new topics were created since then.My questions on topics are:Will they automatically appear or does it take 30 days (as per your docs) for Front to evaluate new topics? If it does take 30 days since the last discovery, is there a way to “trigger” new topic discovery? If a flood of new emails come in about a new topic, such as a live site issue, will Front be able to create a new topic on the fly as needed without having to wait 30 days?Thanks in advance for your clarifications!

Hello, We are a mortgage company using Front for our funding teams communication with loan officers, warehouse banks, title companies etc. Our primary tools we use are Airtable and make.com. My end goal is:When the initial contact point occurs, associate the conversation and the airtable record together by housing the convID in Airtable and the Airtable recordID as a custom object I assume?Have a sidebar plugin that users can open up and it show information about the Airtable record associated with the current conversation, Be able to make small updates to statuses etc in Airtable from inside the plugin. Is there any recommended ways to go about this? Whether it be instructions or just links to highly rated partners?Thank you! 

At the moment, at the new interface version all inboxes on the sidebar are merged together. There is no clear distinction, so it seems that all inboxes merge together. It would be great if certain boundaries were marked. Is separation planned? 

We’re an e-commerce business and use Front for communication with high value clients looking to order multiples and other operational concerns (not general customer service).  The problem:-My main problem deals with my high value clients. When we need to reference their specific order requests, delivery dates, or other specifics, we have to scroll back up in the thread and as we approach our busy season, this is very inefficient. Once the order is placed, we would track this information in Shopify or Google Sheets, which we use for invoicing on our more complicated orders. I typically drop a link to the relevant invoice/Google sheet as a Front comment, but this still involves a lot of scrolling as these email chains get very lengthy. We don’t currently use a CRM. We’re a small business and just never had the man power to leverage one enough to merit the cost. We are open to one, but I am hoping for a low cost solution.  The ideal solution I envision:-The absolute most ideal solution wo