How to Route Intercom Customer Events into Workflows with Jinba

Summary

• Intercom rule-based automation fails on complex cases, while AI-first tools add cost, opacity, and compliance risks.
• The core fix is an auditable four-stage pipeline (Trigger, Enrich, Act, Log) that classifies with an LLM, routes by risk threshold, and records every decision.
• Use Intercom webhooks to trigger a Jinba-published endpoint, an Anthropic (or Azure OpenAI) step to extract structured intent, priority, sentiment, and team, and approval gates for high-risk cases.
• Build a complete audit trail with Jinba's database node plus Intercom's native admin activity log, and snapshot contact state before deletion events.
• This pattern can be implemented faster with Jinba Flow, which provides deterministic, on-prem workflow execution for regulated support teams.

Support teams in fintech and enterprise encounter a structural limitation with Intercom automation: rule-based workflows handle simple cases but do not generalize to complex requests. Maintaining those rules requires ongoing operational overhead. AI-first alternatives add a different set of costs: high per-conversation pricing, opaque decision-making, and, in regulated industries, erosion of customer trust when automated answers are wrong or impersonal.

The underlying problem is architectural. Most automation tools treat Intercom as a closed system, routing and replying within it, but leaving no structured record of what the automation decided or why. That gap is untenable for organizations operating under compliance obligations.

This guide covers a four-part workflow that addresses each of those constraints. With Jinba, Intercom events are routed into a pipeline that classifies requests with an LLM, holds decisions for human review when appropriate, executes actions across the toolchain, and writes a complete audit trail on every run.

The four stages are: Trigger, Enrich, Act, and Log.

Prerequisites: Connecting Jinba and Intercom

The integration is authenticated via an Intercom access token stored as a Jinba workspace secret. Keeping the credential in secrets means it never appears in workflow code or logs.

Follow these steps to establish the connection (Jinba Intercom credential setup):

1. Sign in to the Intercom workspace.
2. Open the Intercom Developer Hub and create a new app, or select an existing one.
3. Under Authentication, generate an access token. Assign only the scopes your workflow requires — at minimum, read conversations and write messages.
4. In the Jinba Flow workspace, go to Secrets settings.
5. Add a new secret named INTERCOM_ACCESS_TOKEN and paste the token value.
6. Add a second secret, INTERCOM_ADMIN_ID, with the numeric ID of the Intercom admin account the workflow will send replies from. Outbound replies require this value in the from field.

Part 1: Trigger — Capturing Intercom Events in Real Time

Jinba's Intercom tool performs actions and data retrieval within a workflow. The workflow is triggered externally by an Intercom webhook pointing to a Jinba-published API endpoint.

Every published Jinba workflow exposes a REST endpoint at:

POST /api/v2/external/flows/{flowId}/published-run

Authenticate each inbound request with a flow-scoped API key passed as Authorization: Bearer <API key>. Full endpoint documentation is available on the Jinba API reference. Runs can be synchronous or asynchronous; inputs arrive as args in the request body.

In Intercom, configure a webhook subscription pointing to this URL. Select the topics that match the workflow's scope. The Intercom webhook model reference covers the full topic list; the ones most relevant to support routing are:

Each topic maps to specific permission scopes on the Intercom app. Verify that the access token includes those scopes before enabling the subscription.

Part 2: Enrich — AI-Powered Classification

Raw conversation text arriving from an Intercom webhook contains everything an agent would read, but nothing a routing rule can act on reliably. This step transforms that text into structured, actionable data.

Jinba's ANTHROPIC_INVOKE tool sends a prompt to a Claude model and returns a structured JSON response. Use it to extract the fields downstream steps need: intent, priority, urgency, sentiment, and the team best placed to handle the request.

- id: classify_request
tool: ANTHROPIC_INVOKE
config:
anthropic_api_key: "{{secrets.ANTHROPIC_API_KEY}}"
model: "claude-3-7-sonnet-20250219"
input:
prompt: >
Analyze the following customer message and return a JSON object with
'intent', 'priority' (Low, Medium, High), 'sentiment' (Positive, Neutral, Negative),
and 'team' (Support, Billing, Engineering).
Message: {{steps.trigger.result.body}}
needs:
- trigger

The needs field declares the dependency on the trigger step, so Jinba executes steps in the correct order. The output at {{steps.classify_request.result}} is available to every subsequent step.

For enterprise teams with existing Azure commitments or data-residency requirements, Jinba offers an Azure OpenAI tool as a drop-in replacement. The step structure is identical; only the tool name and config keys change. This is relevant for teams whose vendor agreements or regulatory obligations require data to remain within an Azure-hosted environment.

Part 3: Act — Human-in-the-Loop and Downstream Actions

Approval gates

Automation does not have to be binary. A classification output with high confidence and low risk (a password reset request marked Low priority) can proceed without review. A classification flagged as High priority, or carrying an intent such as account closure or disputed transaction, warrants a human decision before any action is taken.

Jinba implements this through a condition node that reads the classification output and branches accordingly. The low-risk path continues automatically. The high-risk path routes to an input node, which renders an auto-generated structured form presenting the AI's proposed action to a designated reviewer. The reviewer approves or rejects before the workflow continues.

Threshold-based routing preserves efficiency for routine requests while applying human oversight to decisions where an incorrect automated response would damage trust or create a compliance exposure.

Executing actions

Once the classification or approval step resolves, the output drives actions across the toolchain. Jinba's Intercom tool exposes four nodes for direct Intercom operations:

• INTERCOM_SEND_MESSAGE: reply to an existing conversation or open a new one
• INTERCOM_CREATE_USER: create or update a contact record
• INTERCOM_TRACK_EVENT: attach a custom event to a contact
• INTERCOM_GET_CONVERSATION: retrieve a conversation by ID for downstream processing

Beyond Intercom, workflows can create issues in Jira or Linear, append rows to Google Sheets, or trigger downstream APIs. The following example sends a reply directly into the originating conversation:

- id: send_reply
tool: INTERCOM_SEND_MESSAGE
config:
intercom_access_token: "{{secrets.INTERCOM_ACCESS_TOKEN}}"
input:
message_type: "comment"
body: >
Thanks for reaching out. We have routed your request to
the {{steps.classify_request.result.team}} team.
from:
type: "admin"
id: "{{secrets.INTERCOM_ADMIN_ID}}"
conversation_id: "{{steps.trigger.result.conversation_id}}"
needs:
- classify_request

To log the same event to a Google Sheet, add a parallel step that appends a row with the conversation ID, classification output, timestamp, and the action taken. The needs field on each step controls execution order and parallelism independently.

Part 4: Log — Building a Complete Audit Trail

For fintech and enterprise teams, audit logging is a security and compliance requirement, not an optional enhancement. The question practitioners consistently raise is what the log must contain. A minimal record (user identifier, timestamp, action) is rarely sufficient for a regulatory review.

A Jinba workflow audit log should capture the full lifecycle of each run:

• The inbound event payload from Intercom
• The classification output from the AI step, including all fields returned
• Any human approval decision, including the reviewer identity and timestamp
• The action taken and its result (success, failure, or skipped)

Jinba's reference architecture for multi-level approval workflows includes a database node at the end of the pipeline that writes this complete record with timestamps and decisions. Add this as the final step in every workflow that touches customer data.

A second, independent audit source

For higher-assurance environments, configure an additional Intercom webhook subscription for the admin.activity_log_event.created topic. This pipes Intercom's own native audit log into an external data store (a SIEM solution, a data warehouse, or a compliance platform) alongside the Jinba execution log. The two records can then be cross-referenced: the Jinba log shows what the workflow decided, and the Intercom admin log shows what actions were taken inside the platform. Discrepancies between the two are auditable.

One compliance constraint applies specifically to deletion events. Intercom's deletion webhooks (contact.deleted and equivalent topics) send only a minimal identification payload, not the full contact object. A defensible audit strategy captures object state before any deletion event occurs. This means storing a snapshot of the contact record (via INTERCOM_GET_CONVERSATION or a prior read step) at the point of high-risk classification, not relying on the deletion webhook to reconstruct what was deleted.

What to Build Next

The workflow described here covers the four stages every scalable support automation pipeline requires: a reliable trigger, structured AI enrichment, conditional human oversight, and a defensible audit record.

Intercom automation built this way is maintainable because the logic lives in version-controlled YAML, not in a growing tangle of rule branches. It handles complexity because the LLM classification step can be updated independently of the routing logic. It preserves trust because human agents remain in the decision path for high-risk requests. And it satisfies compliance requirements because every run produces a complete, timestamped record of what happened and why.

To build a first workflow, start with the Jinba Intercom tool documentation and the Anthropic tool reference. The multi-level approval use case provides a reference architecture that can be adapted directly to the pattern described in this guide.

Frequently Asked Questions

How do I connect Jinba to Intercom for automated support workflows?

Connect Jinba to Intercom by creating an Intercom app in the Developer Hub, generating an access token, and storing that token as a Jinba workspace secret. In Jinba, save INTERCOM_ACCESS_TOKEN and INTERCOM_ADMIN_ID in Secrets settings, then point an Intercom webhook subscription to the published Jinba workflow endpoint.

Which Intercom webhook topics should I listen to for AI-powered routing?

The most useful topics are conversation.user.created, conversation.user.replied, contact.user.created, contact.lead.created, conversation.admin.replied, and admin.activity_log_event.created. Each topic maps to specific Intercom API scopes, so verify the token's permissions before enabling the subscription.

Why can't I rely on deletion webhooks for Intercom compliance records?

Intercom deletion webhooks such as contact.deleted send only a minimal identification payload, not the full object. For defensible compliance records, capture a snapshot of the contact or conversation state before deletion occurs, and store it in the audit log.

How does human-in-the-loop approval work in Jinba Intercom workflows?

Human-in-the-loop approval is implemented with a condition node that reads the AI classification output and branches high-risk or high-priority requests to an input node. A designated reviewer sees the AI's proposed action in a generated form and must approve or reject it before downstream actions continue.

What should an audit log for automated Intercom conversations include?

At minimum, include the inbound Intercom event payload, the AI classification output, any human approval decision with reviewer identity and timestamp, and the action taken with its result. Jinba's database node can write this full lifecycle record at the end of the workflow.

How can I classify Intercom conversations with AI without losing control?

Use a structured LLM extraction step that returns fields such as intent, priority, sentiment, and team. Then route lower-risk cases automatically while sending high-risk intents like account closure or disputed transactions to human review. This threshold-based pattern preserves speed while keeping sensitive decisions under oversight.

Does Jinba support Azure OpenAI for Intercom workflows?

Yes. Jinba provides an Azure OpenAI tool as a drop-in replacement for its Anthropic invoke step. Teams with Azure commitments, data-residency requirements, or regulatory constraints can keep classification processing in an Azure-hosted environment while maintaining the same step structure.

How is the trigger step set up in a Jinba Intercom workflow?

The workflow is triggered through an Intercom webhook that points to the Jinba published endpoint POST /api/v2/external/flows/{flowId}/published-run. Inbound requests authenticate with a flow-scoped API key as a Bearer token, and the event payload arrives in the request body for downstream steps.

What makes an AI-first Intercom workflow maintainable for enterprise teams?

It keeps routing and classification logic in version-controlled YAML instead of tangled rule branches, uses structured LLM outputs for decision-making, preserves human approval for high-risk requests, and logs every decision for auditability. This separation makes it easier to update classification prompts independently of routing logic.