ServiceNow Salesforce Integration: Options, Mapping and Setup (2026)

What a ServiceNow Salesforce integration actually does

Salesforce runs the customer relationship: accounts, contacts, opportunities and, in Service Cloud, customer cases. ServiceNow runs IT and operations: incidents, problems, changes, the CMDB and often customer service through Customer Service Management (CSM). When the two don't talk, agents email the service desk, IT asks for details twice, and nobody knows when a fix is done.

Most projects fall into one of three patterns:

• Support escalation. An agent in Service Cloud escalates a case that needs IT, network or platform work. It becomes a ServiceNow incident (or is linked to a problem). State, resolution notes and selected comments come back to the case.
• Sales and service on different platforms. Sales lives in Salesforce, customer service in ServiceNow CSM. Accounts and contacts flow to ServiceNow; open cases, entitlements and asset status flow back to the Salesforce account so account managers see them before a renewal call.
• Vendor and customer bonding. You use Salesforce, your customer or managed service provider uses ServiceNow, and tickets must move between the two companies. This is what ServiceNow people call eBonding.

Whichever pattern fits, the goal is the same: move a small, deliberate set of fields. Mirroring everything burns API limits, leaks internal notes and creates conflicts nobody can resolve.

Your options: spoke, sync app, iPaaS or custom

As of October 2026, Service Cloud has no built-in case-to-incident sync with ServiceNow. ServiceNow offers a Salesforce spoke for Integration Hub; Salesforce’s ServiceNow connectors come with its MuleSoft products; the rest of the market is partner apps, integration platforms and custom code.

The Integration Hub Salesforce spoke

According to ServiceNow’s documentation, the Salesforce spoke lets ServiceNow access and manage data in Salesforce objects including Account, Contact, Case, Lead, Opportunity, Order and User, plus generic actions to create, retrieve, update and delete other Salesforce objects. It authenticates with OAuth 2.0 through an app you register in Salesforce (ServiceNow’s current setup guide uses an external client app; older guides describe a connected app) or with a JWT bearer token, and the connection can be set to run through a MID Server. It requires an Integration Hub subscription.

The spoke is the natural choice when ServiceNow is the hub of your process and you already license Integration Hub. It is a set of building blocks, though. The case-to-incident logic, the status mapping, the correlation of IDs and the guard against sync loops are flows your ServiceNow team designs and maintains. Salesforce agents get no button or panel unless you build one.

Sync apps

Exalate lists a two-way ServiceNow and Salesforce sync covering Salesforce cases, accounts, opportunities and other objects against ServiceNow incidents, problems, change requests and other tables, with comments, attachments and custom fields; it prices by active items in sync and bills each integration separately. Perspectium, a ServiceNow-focused vendor, offers ServiceNow-native apps that keep ServiceNow incidents and Salesforce cases in sync. These apps shorten setup, but check what the vendor’s connector needs on each side, how it stores credentials and where your data passes through.

iPaaS and MuleSoft

MuleSoft, which Salesforce owns, has a ServiceNow connector for Anypoint, and MuleSoft Composer, the low-code tool for Salesforce admins, also has one. Workato and other platforms offer prebuilt connectors for both systems. An iPaaS is the right answer if you already run one, or if ServiceNow and Salesforce are two of many systems you connect. The Salesforce MuleSoft integration guide explains when MuleSoft is worth it.

Which option fits you?

Five questions. The result points to the route most teams in your situation pick.

How the data should flow

The design that holds up: Salesforce owns the customer, the account and the case. ServiceNow owns the incident, the problem, the configuration items and the IT work. Each side keeps the other’s ID so a record is never created twice.

Case to incident mapping: what goes where

Start with this minimum set. Add a field only when someone can name the decision they will make with it.

Status mapping

Out of the box, ServiceNow incident states are New, In Progress, On Hold, Resolved, Closed and Canceled. Salesforce case statuses are whatever your org defined. Map ServiceNow states to a separate "IT state" field on the case, never to Case Status: an incident marked Resolved means IT thinks it is fixed, not that the customer agrees.

Then add a few rules on top. When the incident goes to Resolved, a flow alerts the case owner to confirm with the customer. When the incident goes On Hold waiting for information, the case moves to a "Waiting on customer" status so support chases the reply. If the customer reopens the case, the integration reopens the incident instead of creating a new one.

Comments, work notes and privacy

ServiceNow separates work notes, meant for the people working the incident, from additional comments, meant for the caller. Salesforce case comments have a public flag, and many orgs also use the case feed. Map them deliberately:

• Salesforce → ServiceNow: send only comments the agent marks for IT, into additional comments or a work note, depending on who in ServiceNow should see them.
• ServiceNow → Salesforce: send only additional comments, into an internal case comment or field. The agent decides what the customer hears. Never route IT comments straight into a customer email.
• Personal data: customer phone numbers, logs and screenshots in cases often include PII that IT does not need. Filter or redact before they reach ServiceNow, especially if ServiceNow access is broad.

SLAs: whose clock counts

Both systems run SLA timers: Salesforce through entitlements and milestones, ServiceNow through SLA definitions on the task. They measure different promises. The customer SLA lives on the Salesforce case; the internal operational level agreement (OLA) lives on the ServiceNow incident.

• Don’t sync SLA timers. Sync the facts that drive them: priority, state, timestamps.
• Set the IT target shorter than the customer target, so a breach shows up in ServiceNow before it hits the customer.
• Pause the customer milestone only on states you agree on, such as waiting on customer, and write that rule down.

How to set it up, step by step

The most common path: Service Cloud cases escalated to ServiceNow incidents, built with the Integration Hub spoke or a sync app. Menu names differ by tool and release, so follow the vendor’s install guide for the clicks; this is the order that avoids rework.

1. Write down the escalation workflowWhich cases go to IT, which assignment group receives them, whether they become incidents or link to problems, and what the agent does when IT resolves. One page, agreed by support and IT leads.
2. Agree ownership per recordAccounts and contacts: Salesforce. Incidents, problems, CIs: ServiceNow. Write the system of record for every synced field into your mapping sheet.
3. Prepare sandboxes on both sidesA Salesforce sandbox and a ServiceNow sub-production instance. Never point a two-way sync at production first.
4. Create dedicated integration usersIn Salesforce, use an API-only user with the Salesforce Integration license (according to Salesforce Help, supported editions include a limited number at no extra cost) and a permission set limited to the objects and fields you sync. In ServiceNow, create a service account with only the roles the integration needs and select Web service access only, so it can call the APIs but cannot log in to the UI.
5. Set up authenticationFor the spoke, ServiceNow’s documentation describes a Salesforce external client app (older releases: a connected app) with OAuth or a JWT bearer setup, a credential record and a connection record under the default Salesforce connection alias. For a sync app or iPaaS, follow its OAuth setup and record which scopes it asks for.
6. Add the landing fieldsOn the case: ServiceNow incident number, link, IT state and resolution. On the incident: Salesforce case ID and link. Create them before mapping, so data has somewhere to land.
7. Map fields, priorities and statesUse the tables above. Map priority to impact and urgency explicitly, list every incident state with its Salesforce value, and add a default for anything unmapped.
8. Build the trigger and the loop guardDecide what creates the incident: a button, a case status or a flow condition. Ignore every change made by the integration user on both sides, and check the stored ID before creating a record.
9. Test real scenariosCreate, update, comment both ways, attach a file, resolve, reopen, cancel, and edit the same record on both sides at once. Check that nothing loops, nothing private crosses and nothing is created twice.
10. Pilot, then roll outOne support team and one assignment group for two weeks. Fix the mapping from their feedback, move the configuration to production, then train everyone else.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Aviation33%faster baggage weigh-inWeb and Mobile application for Airlines→Healthcare+30%lab test ordersMedical Lab Web and Native Mobile Applications→Retail · Startup700+stores aggregatedMobile application for Grocery shops→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

Pitfalls and how to fix them

When a custom integration makes sense

The spoke or a sync app covers most case escalation. Custom work starts to pay off when:

• You run several Salesforce orgs or ServiceNow instances, or bond with customers who each run their own ServiceNow.
• Cases need routing, enrichment or approval before IT sees them, by product line, region or contract tier.
• You must prove redaction and data residency to an auditor.
• Per-item app pricing grows faster than a one-time build.
• The same events should also feed a customer portal, a status page or analytics.

A typical custom build is a small middleware service. It listens to Salesforce Platform Events or Change Data Capture and to ServiceNow outbound REST calls from business rules or flows, writes through the ServiceNow Table API (or a Scripted REST API that validates input) and the Salesforce REST API, and keeps an ID map. It needs idempotency, a queue that respects rate limits, retries with alerts and, if agents should see IT data in context, a small Lightning component on the case page.

These ranges come from our API integration cost guide, and the data integration cost article covers larger multi-system projects. For the full map of Salesforce integrations, start with the Salesforce integration guide. If engineering works in Jira rather than ServiceNow, see the Jira Salesforce integration guide; if your frontline support desk is Zendesk, the Zendesk Salesforce integration guide covers that link.

Go-live checklist

Tick what is already true. It shows how ready your integration is for real cases.

FAQ

Where Gilzor fits

Gilzor builds and maintains Salesforce integrations from Poland and Cyprus. Our engineers can map the case-to-incident flow with your support and IT leads, set up the spoke, a sync app or an iPaaS flow, or build a custom integration on the ServiceNow and Salesforce APIs, and support it after launch. See our Salesforce integration services for how that work is scoped.