How to Auto-Tag and Route Front Conversations to the Right Inbox with AI

Build a Spojit workflow that polls Front for new conversations, classifies each one with an AI agent, applies the matching Front tags, and moves the conversation into the correct inbox automatically.

What This Integration Does

Support teams that triage everything by hand burn time reading each new message just to decide what it is about and who should own it. This workflow does that first pass for you: it reads each incoming Front conversation, has the agent classify the topic, urgency, and target team, then applies the right Front tags and routes the conversation into the inbox that owns it. Teammates open their inbox to find work already labelled and sorted, so they can start replying instead of sorting.

The workflow runs on a Schedule trigger (for example every few minutes). On each run it lists conversations that arrived since the last pass, loops over them, and for each one calls the front connector to read the message, calls an AI agent to decide a category, then applies tags and an inbox move. It is read-then-act: nothing is sent to your customers, only internal organisation changes. Re-runs are safe as long as you only fetch genuinely new conversations and skip ones you have already tagged, so the same conversation is not classified twice.

Prerequisites

A front connection added in Spojit under Connections → Add connection, with an API token that can read conversations and edit tags and inboxes.
At least one inbox per routing destination already created in Front (for example Billing, Sales, Technical Support).
The tags you want to apply already created in Front, so each has a stable tag ID.
A short routing map: which category name maps to which Front inbox ID and which tag IDs. You will paste this into the agent prompt.
AI credits available, since this workflow uses an Agent mode step.

Step 1: Add a Schedule trigger

Start a new workflow and add a Trigger node set to type Schedule. Enter a 5-field cron expression and an IANA timezone, for example */5 * * * * with Australia/Sydney to scan every five minutes during the day. A single trigger can hold multiple schedules if you want different cadences. The trigger output is {{ scheduledAt }}, which you can use later to bound which conversations count as new.

Step 2: List new Front conversations

Add a Connector node in Direct mode, choose the front connector, and select the list-conversations tool. Use the q field to narrow the result to unassigned or recently received conversations using Front search syntax, for example:

q: is:unassigned is:open

Leave page_token empty on the first call; if you expect more than one page of results, you can feed {{ list_conversations.data._pagination.next }} back into a follow-up call. Set the Output Variable to list_conversations so later steps can read it.

Step 3: Loop over each conversation

Add a Loop node in ForEach mode and point it at the conversation list, for example {{ list_conversations.data._results }}. Inside the loop body each item is available as the loop variable (referred to below as {{ conversation }}). To make sure you have the full message text and not just a summary, add a Connector node in Direct mode inside the loop, choose front, select get-conversation, and pass the conversation ID:

id: {{ conversation.id }}

Set its Output Variable to full_conversation. This gives you the subject and body to classify in the next step.

Step 4: Classify the conversation with an AI agent

Inside the loop, add a Connector node in Agent mode using the front connector. Agent mode lets the agent reason over the message and return a clean, structured decision. In the prompt, paste your routing map and ask for one category, an urgency, and the tag IDs and inbox ID to apply. For example:

Classify this customer conversation.

Subject: {{ full_conversation.data.subject }}
Body: {{ full_conversation.data.last_message.text }}

Choose exactly one category from:
- billing  -> inbox inb_billing, tags tag_billing
- sales    -> inbox inb_sales,   tags tag_sales
- support  -> inbox inb_support, tags tag_bug

Return the category, an urgency of low/normal/high,
the target inbox id, and the list of tag ids to apply.

Turn on the Response Schema so the output is forced into reliable JSON. A schema such as the following keeps the downstream steps deterministic:

{
  "type": "object",
  "properties": {
    "category": { "type": "string" },
    "urgency":  { "type": "string" },
    "inbox_id": { "type": "string" },
    "tag_ids":  { "type": "array", "items": { "type": "string" } }
  },
  "required": ["category", "inbox_id", "tag_ids"]
}

Set the Output Variable to classification. You will read {{ classification.inbox_id }} and {{ classification.tag_ids }} next.

Step 5: Apply the Front tags

Still inside the loop, add a Connector node in Direct mode, choose front, and select the add-tag tool. Map the conversation and the tag IDs the agent returned:

conversationId: {{ conversation.id }}
tag_ids:        {{ classification.tag_ids }}

The tag_ids field takes an array of Front tag IDs, which is exactly what your Response Schema produced. This labels the conversation so teammates and Front rules can see the category at a glance.

Step 6: Route the conversation to the right inbox

Front does not expose a dedicated move tool, so use the connector's escape hatch. Add a Connector node in Direct mode, choose front, and select the raw-api-request tool to update the conversation's inbox. Set:

method: PATCH
path:   /conversations/{{ conversation.id }}
body:   { "inbox_id": "{{ classification.inbox_id }}" }

This moves the conversation into the inbox the agent chose. Because tagging and routing both run inside the loop, every conversation in the batch is handled before the run completes.

Step 7: Add a Condition guard for low-confidence cases (optional)

To avoid mis-routing ambiguous messages, add a Condition node before Step 5 that checks the agent's category. If the category is empty or marked as unknown, send the true branch to a Send Email node that notifies your triage lead with the conversation subject and a link, instead of tagging and routing. Connect the false branch to the tagging and routing steps so only confident classifications are applied automatically.

Tips

Keep the Front search in list-conversations tight (for example is:unassigned is:open) so each run classifies only genuinely new work and you do not re-spend AI credits on conversations already sorted.
Pull all your tag and inbox IDs once with the list-tags and list-inboxes tools, then hard-code them into the agent prompt's routing map so the agent never has to guess an ID.
Use the Response Schema in Agent mode every time. Forcing JSON output means the add-tag and raw-api-request steps get a clean array and string rather than free-form text.
Ask Miraxa to scaffold this for you with a prompt like "Build a workflow that lists open Front conversations, classifies each with an Agent mode step, then tags and routes them," then fine-tune fields in the properties panel.

Common Pitfalls

If your Front token lacks permission to edit tags or move conversations, add-tag or the raw-api-request PATCH will fail. Re-check the token scope in your connection before going live.
Tag and inbox IDs are not the human-readable names. Passing the name (for example Billing) instead of the ID will silently mismatch. Always map names to IDs in the prompt.
Without a tight search filter, a Schedule trigger that fires every few minutes can re-classify the same conversations on every run. Filter on unassigned or open state, or add your own "already tagged" check, to keep runs idempotent.
Large result sets are paginated. If you only act on the first page, later conversations are missed. Use page_token from _pagination.next to fetch the rest when needed.

Testing

Before scheduling, switch the trigger to Manual and run the workflow with the Run button against a small batch, for example a search that returns two or three test conversations. Open the execution log to confirm the agent's classification output, that add-tag applied the expected tags, and that the raw-api-request PATCH returned success. Verify in Front that the test conversations moved to the right inbox. Once the routing looks correct, switch the trigger back to Schedule and enable the workflow.