How to Escalate High-Urgency Front Conversations to Slack On-Call with Human Approval

Build a Spojit workflow that classifies inbound Front conversations for urgency and sentiment, gates only the severe ones, pulls the matching escalation runbook, asks your on-call lead to approve paging, and then posts the escalation to a Slack on-call channel while tagging the conversation as escalated.

What This Integration Does

Support teams running on Front get a flood of inbound conversations, and only a handful are true incidents that warrant paging an on-call engineer. This workflow reads each new conversation as it arrives, uses an Agent-mode Connector node to judge how urgent and how negative it is, and stops everything that is routine. For the rare conversation that crosses the severity line, it looks up the right escalation runbook from your knowledge base, asks a human on-call lead to confirm before anyone gets paged, and only then fires a richly formatted Slack alert into your on-call channel. The result is fast, accountable escalation without alert fatigue.

The workflow is triggered by an inbound Webhook from Front, so it runs within seconds of a conversation being created or updated. Data flows from the Front payload, through an Agent-mode classification, through a Condition gate, into a Knowledge query, then pauses at a Human approval node. Each run leaves two visible side effects when approved: a message in your Slack on-call channel and an escalated tag added to the Front conversation. Non-severe runs end quietly after the Condition, and runs where the on-call lead rejects (or lets the approval time out) halt before any Slack message is sent, so re-running the same conversation is safe and will not double-page.

Prerequisites

A Front connection (API key) added under Connections, with permission to read conversations and add tags. See the Front connector reference.
A Slack connection added under Connections, with permission to post messages to your on-call channel. See the Slack connector reference.
A signing connection for the Webhook trigger. Front signs its webhooks, so add a Custom signing connection (or use the scheme Front provides) under Connections before wiring the trigger.
The Slack channel ID of your on-call channel (for example C0123ONCALL), and the Front tag ID for your escalated tag. Use the Front list-tags tool once to find the tag ID.
A persistent Knowledge collection named, for example, escalation-runbooks, with one document per incident type. See how to create a Knowledge collection and how to upload documents.

Step 1: Start with a Webhook trigger from Front

Add a Trigger node and set its type to Webhook. Spojit gives the workflow a unique URL and returns 202 with an executionId to the caller. Choose your Front signing connection so the incoming POST is verified before the run starts. In Front, configure a rule or app webhook that posts conversation events (such as inbound message received) to this URL.

The trigger output is the parsed JSON body, available as {{ input }}. Capture the conversation identifier early so later steps can act on the exact conversation. Front payloads expose the conversation ID at a path like {{ input.conversation.id }}; confirm the path against your own payload in the execution logs after the first test event.

Step 2: Fetch full conversation detail with Front in Direct mode

Add a Connector node on the front connector in Direct mode and select the get-conversation tool. Map its id field to {{ input.conversation.id }}. Direct mode is deterministic and costs no AI credits, which is what you want for a single, predictable lookup.

This pulls the subject, status, and recipient handles so the classification step has the full context rather than just the webhook stub. Store the result in an output variable such as conversation. You will reference fields like {{ conversation.subject }} downstream.

Step 3: Classify urgency and sentiment in Agent mode with a Response Schema

Add a Connector node on the front connector in Agent mode (Agent mode lets the agent reason over the text and return structured JSON). Give it a prompt that describes the judgment you want, and attach a Response Schema so the output is reliable, machine-readable JSON every time. A workable prompt:

Read this customer conversation and rate it.
Subject: {{ conversation.subject }}
Latest message: {{ input.conversation.last_message.body }}

Return urgency as one of low, medium, high, or critical.
Return sentiment as one of positive, neutral, negative.
Set incident_type to the closest matching category
(outage, billing, security, data-loss, or other).

Set the Response Schema so the node returns a fixed shape:

{
  "type": "object",
  "properties": {
    "urgency": { "type": "string" },
    "sentiment": { "type": "string" },
    "incident_type": { "type": "string" }
  },
  "required": ["urgency", "sentiment", "incident_type"]
}

Store the result in an output variable such as triage, giving you {{ triage.urgency }}, {{ triage.sentiment }}, and {{ triage.incident_type }}.

Step 4: Gate severe cases with a Condition node

Add a Condition node so only genuinely severe conversations continue. Configure the condition to require both a high urgency and a negative read, for example: {{ triage.urgency }} equals critical OR ({{ triage.urgency }} equals high AND {{ triage.sentiment }} equals negative).

Connect only the true branch onward to the escalation steps. Leave the false branch empty so routine conversations end the run quietly with no Slack noise and no tag change. See using Condition nodes for the full operator reference.

Step 5: Pull the matching escalation runbook with a Knowledge query

On the true branch, add a Knowledge node in Query mode. Set Collection to your persistent escalation-runbooks collection, set Result Count to 3, and choose your synthesis Model. Write a Prompt that targets the classified incident type so the right runbook surfaces:

Provide the on-call escalation runbook for a
{{ triage.incident_type }} incident. List the immediate
response steps the on-call engineer should take, in order.

Add a Response Schema if you want the steps as a clean list, then store the result in an output variable such as runbook. You will drop {{ runbook }} into both the approval message and the Slack post so the on-call lead and the channel see the same guidance. For more on querying, see querying your knowledge base.

Step 6: Pause for the on-call lead with a Human approval node

Add a Human node so a person confirms before anyone is paged. Set a clear Label (such as Approve paging on-call) and a Message that includes the context the approver needs:

Conversation: {{ conversation.subject }}
Urgency: {{ triage.urgency }} / Sentiment: {{ triage.sentiment }}
Incident type: {{ triage.incident_type }}

Proposed runbook:
{{ runbook }}

Approve to page the on-call channel.

Set Urgency to High, set a Timeout (minutes) such as 15 so a stalled approval does not hang forever, and add one Approval slot containing your on-call lead (as a User, Role, or Team atom). Turn on Email approvers if you want them notified by email as well as in the Approvals inbox. On approval, the node outputs { approved: true, approvalId, outcome: "APPROVED" } and the run continues. A reject or timeout halts the run, so the Slack post and tag never happen. See using Human approval nodes.

Step 7: Post to Slack and tag the Front conversation

After approval, add a Connector node on the slack connector in Direct mode and select send-message. Set channel to your on-call channel ID and text to the escalation summary, including the runbook steps:

:rotating_light: Escalation approved
Conversation: {{ conversation.subject }}
Urgency: {{ triage.urgency }} | Type: {{ triage.incident_type }}

Runbook:
{{ runbook }}

Then add a final Connector node on the front connector in Direct mode with the add-tag tool. Map conversationId to {{ input.conversation.id }} and set tag_ids to an array containing your escalated tag ID. This marks the conversation in Front so agents can see at a glance that it has been escalated, and prevents confusion about whether anyone has acted on it.

Tips

Use Direct mode for every deterministic call (get-conversation, send-message, add-tag) so you only spend AI credits on the one classification step that actually needs judgment.
For a richer Slack alert, supply the optional blocks field on send-message with Block Kit JSON; keep your plain text populated as the notification fallback.
Keep one runbook document per incident type in the escalation-runbooks collection so the Knowledge query returns tightly scoped guidance instead of a blended answer.
You can ask Miraxa to scaffold this for you: "Build a workflow with a Webhook trigger, a Front Agent-mode classification with a Response Schema, a Condition that only continues on critical urgency, a Knowledge query, a Human approval, then a Slack send-message and a Front add-tag." Then fine-tune each node in the properties panel.

Common Pitfalls

If you skip the signing connection on the Webhook trigger, unverified posts will not start runs. Make sure the signing scheme matches what Front sends.
The tag_ids on add-tag expects tag IDs, not tag names. Run list-tags once to capture the exact ID for your escalated tag.
Agent-mode output is only reliable when you attach a Response Schema. Without it, your Condition comparisons against {{ triage.urgency }} may break on free-form text.
Remember that a rejected or timed-out Human approval halts the run; there is no "on reject" branch. If you want a softer fallback for rejected cases, handle that in a separate workflow rather than expecting downstream branching here.
Confirm the exact payload paths (for example {{ input.conversation.id }} and the last message body) against a real event in the execution logs, since Front payload shapes vary by event type.

Testing

Before turning the workflow on for live traffic, point a single test Front rule (or a manually replayed webhook event) at the trigger URL for one low-volume inbox. Send yourself an obviously urgent test message so the Agent-mode step returns a high or critical rating, and confirm the Condition true branch fires. Approve the Human node from the Approvals inbox and verify the Slack message lands in a test channel and the escalated tag appears on the Front conversation. Then send a routine message and confirm the run ends quietly with no Slack post and no tag. Once both paths behave, widen the Front rule to your real inboxes.