Air-Gapped Support Integration: Intercom to Salesforce via MuleSoft
Security review would not let Intercom touch the Salesforce production instance. Support chat was already running. Cases were not, and the two systems could not be introduced to each other.
So we put MuleSoft between them as an authenticated proxy. It polls Intercom every 30 minutes, reshapes the data with DataWeave, and writes Salesforce cases keyed on the Intercom Conversation ID. One long chat becomes one case, not ten.
Executive Summary
Context
An enterprise architecture review board treats a direct API connection from an external chat platform to the Salesforce production instance as an unacceptable exposure. That constraint, not the data mapping, is what shapes the design. A middleware proxy satisfies it, and the batch interval becomes a rate-limit decision rather than a latency compromise.
What We Built
An integration brief specifying MuleSoft as an authenticated middleware proxy. A Mule App Scheduler polls Intercom's Search for Conversations endpoint every 30 minutes. DataWeave flattens nested conversation JSON into Salesforce Case objects, and Anypoint Connectors handle both ends. Conversation ID is the key that stops duplicates.
Tech Stack
- MuleSoft
- Anypoint Connectors
- DataWeave
- Mule App Scheduler
- Intercom
- Salesforce Service Cloud
- Connected App
Teams who can point a chat platform straight at their CRM. If no architecture review stands between the two systems, a native connector is cheaper than a middleware tier.
The Challenge
Enterprise security forbade a direct API connection between Intercom and the Salesforce production instance. The review board's position was blunt: the CRM does not get exposed to an external custom application. That ruled out the obvious build and it ruled out a point-to-point connector.
Support was running two distinct conversation shapes through one inbox. A chatbot handled some conversations end to end. Others escalated to a live agent partway through. Both had to become cases, owned by different parties, without a human deciding which was which.
Nothing in Intercom carried a stable case identity. A conversation continues after the first sync, so any naive push would create a fresh case on every poll and bury the real one in duplicates.
Our Approach
MuleSoft became the authenticated middleware tier, and that choice was made against two alternatives. Exposing Salesforce directly was refused on security grounds. Hevo was considered and dropped: it would have added a tool with no in-house experience behind it, plus its own security and budget review.
A Mule App Scheduler polls Intercom's Search for Conversations endpoint every 30 minutes. The interval is deliberate. It keeps the integration under Salesforce API rate limits and aggregates transcript updates into a single sync event instead of a stream of small writes.
DataWeave flattens nested Intercom conversation JSON into Salesforce Case objects. Cases are created or updated keyed on the Intercom Conversation ID, which is what stops a continuing conversation from becoming a pile of duplicate records.
Two case scenarios are specified rather than inferred. A chatbot-only conversation is created with the bot as case owner. A conversation that escalates is assigned to the live agent who took it.
Impact
Support cases without CRM exposure
Chat reaches Salesforce Service Cloud as structured cases, and the production instance stays closed to the outside platform. Security and reporting stop pulling against each other.
One conversation, one case
Keying on the Intercom Conversation ID means a conversation that runs for hours updates a single case. Support reporting counts conversations, not sync events.
Bot and agent work is separable
Case ownership is stamped at creation from the conversation's own shape, so chatbot-handled volume and live-agent volume can be reported apart without manual triage.
Rate limits designed for, not discovered
The 30-minute batch was chosen to sit inside Salesforce API limits. Throttling became a design parameter rather than a production incident.
When an architecture review board refuses to expose the CRM, the integration tier is not an optimization, it is the requirement. MuleSoft holds both sets of credentials so neither platform holds the other's.
A chat conversation has no natural case identity and does not end when the first sync runs. Matching on the platform's own conversation identifier is what makes a polling integration idempotent.
A 30-minute cycle is not latency tolerance, it is API budget. Aggregating transcript updates into one write per cycle keeps a high-volume support channel inside Salesforce limits.
Bot-only and bot-then-agent are different records with different owners. Deciding that in the data contract, not in a workflow afterwards, is what keeps case ownership trustworthy.
An air-gapped support integration architecture. Intercom holds the conversation, and no direct connection to Salesforce is permitted. A Mule App Scheduler polls Intercom's Search for Conversations endpoint every 30 minutes; DataWeave flattens nested conversation JSON into Salesforce Case objects; Anypoint Connectors write to Service Cloud. Cases are created or updated keyed on the Intercom Conversation ID so a continuing conversation maps to one case. Two ownership paths are shown: chatbot-only conversations owned by the bot, and escalated conversations owned by the live agent.
FAQ
Because security would not permit the direct connection. The review board's position was that the Salesforce production instance does not get exposed to an external custom application. That removed the direct build before cost entered the conversation.
MuleSoft holds the credentials for both platforms. Intercom never authenticates against Salesforce, and Salesforce never accepts an inbound call from the chat platform.
It matches on the Intercom Conversation ID. A conversation keeps going after the first 30-minute poll, so the sync has to recognise a conversation it has already seen and update that case rather than create another. The Conversation ID is stable for the life of the conversation, which makes it the right key. Without it, every poll adds a case and the real one is impossible to find.
