ArcIntegrate | The B2B SaaS Interoperability Engine

Overview: Connecting Intercom and Salesforce

The integration between Intercom and Salesforce addresses one of the most persistent friction points in revenue operations: the gap between conversational customer data and structured CRM records. Intercom captures real-time behavioral signals, support intent, and product engagement through its Messenger and inbox. Salesforce is the system of record for pipeline, accounts, contacts, and revenue attribution. When these two platforms operate in isolation, sales teams work from incomplete context, and support agents lack the account history needed to triage conversations intelligently.

A well-architected Intercom-to-Salesforce integration synchronizes contact and lead records bidirectionally, pushes conversation metadata as Salesforce activities, and enables automated lead scoring enrichment based on Intercom engagement events. This guide covers the implementation of this integration using both Intercom's native Salesforce app and a custom webhook-driven approach via iPaaS platforms such as Zapier or Make (formerly Integromat).

Core Prerequisites

Before beginning configuration, you must confirm access and permissions across both platforms. On the Intercom side, you require an Admin-level account to install and configure the Salesforce integration. If you are using the REST API or webhooks directly, you need to generate an Access Token from the Intercom Developer Hub under Settings > Your Apps > Access Token. The token must be granted the following scopes: read_users, write_users, read_conversations, write_conversations, and read_companies. For webhook-based setups, your Intercom subscription must be on a plan that supports webhook topics, which as of the current product tiers means at least the Intercom Starter plan.

On the Salesforce side, you need a System Administrator profile or a custom profile that includes the following permissions: Modify All Data on Lead and Contact objects, Customize Application to install connected apps, and API Enabled at the profile level. Salesforce Connected App configuration requires OAuth 2.0 with the following scopes enabled: api, refresh_token, and offline_access. The OAuth callback URL must be whitelisted in the Connected App settings. If your Salesforce org uses IP allowlisting, Intercom's IP ranges must be added to the trusted network list, which are published in Intercom's developer documentation under Network Security.

If you are deploying via Make, you need a Make organization with at least the Core plan to support webhooks as scenario triggers. For Zapier, a Professional plan or above is required to use multi-step Zaps with conditional paths.

Top Enterprise Use Cases

The most common enterprise deployment pattern is real-time lead creation in Salesforce from Intercom-qualified conversations. When a bot qualification sequence in Intercom reaches a terminal "hand to sales" state, the conversation data—including the lead's email, company name, phone number, and qualification answers—should be written to Salesforce as a new Lead record without any manual intervention from a sales development representative.

A second high-value use case is activity logging. Every Intercom conversation that involves a contact already present in Salesforce should be logged as a Task or Event on the corresponding Contact or Lead record. This gives account executives a chronological view of all product and support touchpoints directly within Salesforce, which is critical for account-based selling motions.

A third use case is bidirectional field sync for contact attributes. When a deal stage changes in Salesforce—for example, an Opportunity moves to Closed Won—that signal should propagate back to Intercom to update the user's custom attributes and trigger a specific onboarding message series. This requires a bidirectional sync architecture and must be implemented carefully to avoid infinite loops.

Step-by-Step Implementation Guide

Using the Native Intercom-Salesforce Integration

The fastest path to a working integration is Intercom's native Salesforce app, available from the Intercom App Store. Navigate to Settings > Integrations > App Store, search for Salesforce, and click Install. You will be redirected through a Salesforce OAuth 2.0 authorization flow. Grant access using an account that has the System Administrator profile. Once authorized, Intercom will display a field mapping interface where you configure how Intercom user attributes map to Salesforce Lead or Contact fields.

The native app syncs on a periodic schedule (approximately every 15 minutes) rather than in real time. For most use cases this is acceptable, but for time-sensitive lead routing workflows, a webhook-driven approach is preferable.

Webhook-Driven Implementation via Make

To build a real-time pipeline, start by creating a new Scenario in Make. Add a Webhooks module as the trigger, specifically a "Custom Webhook." Make will generate a unique webhook URL in the format https://hook.eu1.make.com/[unique-id] (or hook.us1.make.com depending on your Make data region). Copy this URL.

In Intercom, navigate to Settings > Developers > Webhooks and create a new webhook. Paste the Make webhook URL into the URL field. Subscribe to the following topics based on your use case: conversation.user.created, conversation.tag.created, and contact.user.updated. Save the webhook configuration. Intercom will send a verification handshake to your Make webhook URL immediately; the Make Custom Webhook module handles this automatically.

Now return to Make and run your scenario once to capture the Intercom webhook payload structure. A sample payload for a conversation.user.created event looks like the following:

{
  "type": "notification_event",
  "app_id": "abc123",
  "data": {
    "type": "notification_event_data",
    "item": {
      "type": "conversation",
      "id": "29325834",
      "created_at": 1698765432,
      "updated_at": 1698765480,
      "source": {
        "type": "conversation",
        "delivered_as": "customer_initiated"
      },
      "contacts": {
        "contacts": [
          {
            "type": "contact",
            "id": "64e2f1a3c2b4a1001e3f0021",
            "external_id": "user_8821",
            "email": "[email protected]",
            "name": "Jane Doe",
            "custom_attributes": {
              "company_size": "201-500",
              "job_title": "VP of Engineering"
            }
          }
        ]
      }
    }
  },
  "delivery_attempts": 1,
  "first_sent_at": 1698765482
}

With this payload captured, add a Salesforce module to your Make scenario. Select the "Create a Record" action and choose "Lead" as the Salesforce object. Map the fields as follows: map data.item.contacts.contacts[].email to the Salesforce Lead Email field, data.item.contacts.contacts[].name to LastName (you may need a Text Parser module to split the full name), and data.item.contacts.contacts[].custom_attributes.company_size to a custom Salesforce field such as Company_Size__c. Set the Lead LeadSource field to the static value "Intercom" for attribution reporting.

Add a Router module between the Webhook trigger and the Salesforce module to handle cases where the contact's email is null. Route null-email payloads to an error-handling branch that logs the event to a Google Sheet or sends a Slack notification for manual review.

Zapier Implementation

In Zapier, create a new Zap with Intercom as the trigger app. Select "New Conversation" as the trigger event. During the setup wizard, Zapier will prompt you to authenticate your Intercom account via OAuth 2.0 and select a specific conversation tag or segment to filter on. For the action step, select Salesforce and choose "Create Lead." Map the Intercom conversation contact fields to the Salesforce Lead fields. Add a Filter step before the Salesforce action to only proceed when the email field is not empty.

Common Pitfalls & Troubleshooting

The most frequently encountered error during this integration is a 401 Unauthorized response from either the Intercom API or the Salesforce API. For Intercom, this almost always means the Access Token has been revoked or the app has been uninstalled and reinstalled, generating a new token that was not updated in your Make or Zapier configuration. Resolve this by regenerating the Access Token in the Intercom Developer Hub and updating the credential in your iPaaS platform.

For Salesforce 401 errors, the OAuth refresh token may have expired. Salesforce refresh tokens expire if the Connected App's OAuth policy is set to "Refresh Token is valid until revoked" but the token has not been used within the session timeout window. Re-authenticate the Salesforce connection in Make or Zapier to obtain a fresh token pair.

A 429 Too Many Requests error from the Salesforce API indicates you have exceeded the API request limits for your Salesforce edition. Salesforce enforces daily API call limits (e.g., 15,000 calls per day on Professional Edition, 100,000 on Enterprise Edition). To mitigate this, implement a bulk upsert strategy using the Salesforce Bulk API 2.0 endpoint (/services/data/vXX.0/jobs/ingest) rather than making individual REST calls for each Intercom event. Batch your Intercom events in Make using the Aggregator module before writing to Salesforce.

Duplicate Lead records are another common operational problem. Intercom does not deduplicate against existing Salesforce records natively. Use the Salesforce "Upsert a Record" action in Make (which uses an External ID field) rather than "Create a Record." Define a custom External ID field on the Salesforce Lead object, such as Intercom_Contact_ID__c, and populate it with the Intercom contact ID from the webhook payload. This ensures that repeated events for the same contact update the existing Lead rather than creating duplicates.

Finally, be aware of Intercom's webhook retry behavior. If your Make webhook URL returns anything other than a 200 OK within 30 seconds, Intercom will retry the delivery up to 5 times with exponential backoff. Ensure your Make scenario is activated and that the webhook endpoint responds promptly. If your scenario has a long-running step (such as a Salesforce lookup), consider using Make's asynchronous processing pattern to return a 200 immediately and process the payload in a subsequent scenario triggered via a data store.