How to Route Front Customer Messages to Slack Channels
Forward important customer conversations from Front to specific Slack channels.
What This Integration Does
Different customer issues need different audiences. A billing question should land in the finance channel; a critical bug in the engineering channel; a churn signal in the customer success channel. This workflow inspects each new Front conversation and routes a summary to the right Slack channel based on tags, inbox, or content - so the right team sees the right signal at the right time without anyone manually forwarding.
The run model is poll-based. The workflow checks Front on a schedule for newly updated conversations, classifies each one, and posts a tailored message to the matching Slack channel. The execution log keeps a record of every routing decision so you can audit (and tune) the rules.
Prerequisites
- A front connection with API access to the inboxes you care about.
- A slack connection with permission to post in each destination channel.
- A clear mapping of inbox/tag combinations to Slack channel IDs (write it down before you start).
Step 1: Schedule Trigger
Drop a Trigger node and set its type to Schedule. Run every 1 to 5 minutes. The trigger exposes the previous run timestamp, which the next step uses as the lower bound on the conversation poll. This makes runs incremental rather than re-scanning the whole inbox each time.
Step 2: List Recent Conversations
Add a Connector node pointing at the front connector and pick the list-conversations tool. Set:
inbox_idfor each inbox you care aboutq[updated_after]to the previous run timestamp
Save the response as conversations. If you need full message detail (subject lines, body snippets), call get-conversation per item in the next step.
Step 3: Loop and Classify
Wrap the routing logic in a Loop node that iterates over conversations. Inside the loop, add a Condition chain (or several condition branches) that picks the destination channel based on conversation tags and inbox. For example:
- Tag
billing-> finance Slack channel - Tag
bugor inboxengineering-> engineering Slack channel - Tag
vip-> account management channel (in addition to its primary destination) - Everything else -> general support channel
Step 4: Transform - Build the Slack Message
Add a Transform node inside the loop body to assemble a Slack mrkdwn payload. Include who, what, and a deep link back to Front so the receiving channel can act in one click:
{
"text": "*{{ conversation.tags.0.name | default('Conversation') }}* from {{ conversation.recipient.handle }}\n> {{ conversation.subject }}\n<https://app.frontapp.com/open/{{ conversation.id }}|Open in Front>",
"channel": "{{ routedChannelId }}"
}
Step 5: Post to Slack
Add a Connector node pointing at the slack connector and pick the send-message tool. Pass through the text and channel built in the Transform. For critical tags, chain a follow-up slack add-reaction with an emoji like fire so on-call sees it stand out in the channel.
Step 6: Tag and Watermark
After the post succeeds, call the front connector's add-tag tool to mark the conversation with something like routed-{channel}. This stops accidental double-posts if the watermark is ever reset, and gives you an audit trail in Front. End the loop, end the workflow.
Tips
- Test routing rules with one inbox first - tag misclassification is the most common reason messages land in the wrong channel.
- Use Slack channel IDs, not names. Names change; IDs do not.
- Keep the message body compact. A summary plus a link beats a wall of text in Slack.
Common Pitfalls
- Front pagination -
list-conversationsreturns at most one page. Loop on the pagination cursor if your poll cadence is slow or volume is high. - Outbound replies show up in the result set too. Add a Condition to skip messages your own teammates sent.
- Building the routing rules in a single tangled Condition. Use a Transform that returns the destination channel, and keep the routing logic in one place.
Testing
Pick one inbox and route to a private Slack channel. Send a test Front message with each tag you want to handle and confirm it lands in the right destination. Only once each rule has been verified should you point at the real Slack channels.