How to Triage Inbound Front Conversations into Slack Channels by AI Priority

Build a Spojit workflow that runs on a schedule, pulls new Front conversations, lets an AI agent score each one for urgency and category, then posts it to the matching Slack channel with a priority label.

What This Integration Does

Support inboxes fill up faster than a team can read them, and not every message deserves the same attention. This workflow watches your Front inbox on a fixed cadence, reads each new conversation, and uses an Agent-mode Connector node to decide how urgent it is and what it is about. The result lands in Slack: a high-priority billing question goes to your #urgent-support channel, a routine how-to question goes to #support-triage, and every message carries a clear priority label so the right person picks it up first.

A Schedule trigger starts the run on a Unix cron expression you define. Each run lists conversations from Front, loops over them, scores each one with a Connector node in Agent mode (which returns structured JSON), branches on the score with a Condition node, and posts to Slack with a Connector node in Direct mode. The workflow leaves no state behind on its own, so the key design task is making sure you only process genuinely new conversations on each run. The Tips and Common Pitfalls sections below cover how to scope the Front search so repeated runs do not re-post the same conversations.

Prerequisites

A Front connection added in Spojit via Connections → Add connection, with an API token that can list and read conversations.
A Slack connection added in Spojit, authorized to post to the channels you intend to route to.
The Slack channel IDs for each destination channel (for example C012AB3CD4E). You can copy a channel ID from the channel details in Slack, or look them up once with the Slack list-channels tool.
A shared idea of your priority levels and categories (for example High / Normal / Low and categories like billing, technical, general) so the AI agent has a fixed vocabulary to score against.
AI credits available on your plan, since the scoring step runs in Agent mode.

Step 1: Start with a Schedule trigger

Create a new workflow in the Workflow Designer. Add a Trigger node and set Trigger Type to Schedule. Enter a 5-field Unix cron expression and an IANA timezone. For example, to run every 15 minutes during business hours, Monday to Friday, in Sydney time:

Cron:     */15 9-17 * * 1-5
Timezone: Australia/Sydney

A single Schedule trigger can hold multiple schedules if you want different cadences. The trigger output is { scheduledAt }, which you do not need downstream here, since the conversation data comes from Front in the next step.

Step 2: Pull new Front conversations

Add a Connector node, choose the Front connector, and set it to Direct mode. Select the list-conversations tool. Use the q field to search for only the conversations you want to triage so you are not re-reading the whole inbox on every run. Scope it to unassigned, open conversations in your support inbox, for example:

q: "is:open is:unassigned inbox:Support"

The tool returns a list of conversations under a results envelope, plus a pagination token at _pagination.next. Map the conversation list to an output variable such as {{ conversations }}. If you expect more than one page of results per run, see the Common Pitfalls section on pagination.

Step 3: Loop over each conversation

Add a Loop node set to ForEach and point it at the conversation list from the previous step, for example {{ conversations.results }} (use the exact field your Front output exposes). Inside the loop body, the current item is available as the loop variable, for example {{ conversation }}. Everything in Steps 4 through 6 lives inside this loop body so each conversation is scored and routed independently.

If you need the full message body rather than just the conversation summary, add a Connector node in Direct mode using the Front get-conversation tool with id set to {{ conversation.id }} as the first node inside the loop.

Step 4: Score urgency and category with an AI agent

Inside the loop, add a Connector node, choose the Front connector again (or any connector you have configured for reasoning), and switch it to Agent mode. Agent mode lets the agent read the conversation and return a judgement. Turn on the Response Schema so the output is reliable, structured JSON rather than free text. Define a schema like this:

{
  "type": "object",
  "properties": {
    "priority": { "type": "string", "enum": ["High", "Normal", "Low"] },
    "category": { "type": "string", "enum": ["billing", "technical", "general"] },
    "reason":   { "type": "string" }
  },
  "required": ["priority", "category", "reason"]
}

In the agent prompt, paste the conversation subject and body and ask for a score, referencing the variables from the loop, for example:

Read this customer conversation and classify it.
Subject: {{ conversation.subject }}
Body: {{ conversation.last_message.body }}
Return the priority, the category, and a one-line reason.

Map the structured result to an output variable such as {{ triage }}, giving you {{ triage.priority }}, {{ triage.category }}, and {{ triage.reason }} to use downstream.

Step 5: Branch on priority and category

Add a Condition node to decide which Slack channel each conversation goes to. A simple split is to send anything scored High to your urgent channel and everything else to your general triage channel. Set the condition to check {{ triage.priority }} equals High. The true branch routes to the urgent channel; the false branch routes to the general channel.

If you want a channel per category as well, chain a second Condition node on the false branch that checks {{ triage.category }}, or use a Transform node to map each category to its channel ID into a single variable like {{ targetChannel }} that you reference once in the next step.

Step 6: Post to the matching Slack channel with a priority label

On each branch, add a Connector node, choose the Slack connector, set it to Direct mode, and select the send-message tool. Set channel to the destination channel ID for that branch (for example C012AB3CD4E) and build the text from your triage variables so the priority label is front and center:

channel: C012AB3CD4E
text: ":rotating_light: [{{ triage.priority }}] {{ triage.category }} - {{ conversation.subject }}\nWhy: {{ triage.reason }}\nOpen in Front: {{ conversation.id }}"

If your team works conversations directly in Front and you want a closed loop, add an optional Connector node in Direct mode with the Front add-tag tool to tag the conversation as triaged, so the next scheduled run can exclude it via the search query in Step 2.

Tips

Keep the Agent-mode prompt short and the Response Schema strict. Fixed enum values for priority and category make the downstream Condition node reliable and keep AI cost low.
Use Slack emoji shortcodes (such as :rotating_light: or :white_check_mark:) in the text field to make priority visible at a glance in the channel.
Match the schedule cadence to your search scope. A 15-minute cron with an open-and-unassigned query keeps each run small and well within Front and Slack rate limits.
Scaffold the canvas quickly by asking Miraxa to "add a Loop node over the Front conversation list, a Connector node in Agent mode that scores priority and category, and a Slack send-message node on each Condition branch," then fine-tune fields in the properties panel.

Common Pitfalls

Re-posting the same conversations. The Schedule trigger has no memory of prior runs. If your q search matches the same conversations again, you will post duplicates. Scope the search to a state that changes once handled (open and unassigned), or tag conversations with Front add-tag after posting and exclude that tag in the query.
Missing conversations due to pagination. list-conversations returns one page plus _pagination.next. If a run can produce more results than one page, narrow the search window or fetch additional pages by passing the token into page_token on a follow-up call.
Wrong Slack channel ID. The channel field expects the channel ID (for example C012AB3CD4E), not the display name. A channel name in that field will fail to deliver.
Free-text scoring breaking the branch. Without a Response Schema, the agent may return prose instead of clean values, and the Condition node comparison on {{ triage.priority }} will not match. Always enable the schema in Step 4.

Testing

Before turning the schedule on, validate the logic on a tiny scope. Temporarily set the Step 2 q search to a single known conversation (for example by subject text), then use the Run button to execute once and watch the execution logs. Confirm the AI agent returns a valid priority and category, that the Condition node takes the branch you expect, and that the Slack message arrives in the right channel with the priority label. Once a single conversation flows end to end, widen the search query and enable the Schedule trigger.