ServiceNow Salesforce integration

• ServiceNow: admin, IntegrationHub, and the Salesforce spoke from the Store.
• Salesforce: a System Administrator and API access enabled on the profile.
• A Salesforce Connected App for OAuth 2.0.

Before any configuration, settle the question this integration exists to answer: where does a customer issue live? Both systems have a case object, both have a lifecycle, and both have people who consider theirs authoritative. Sales and service teams work in Salesforce. Technical resolution happens in ServiceNow. If nobody decides which record is the master, you get two, and they diverge within days.

The workable answers are usually one of two. Either Salesforce owns the customer facing case and ServiceNow holds a linked technical record whose status is pushed back, or ServiceNow owns the incident and Salesforce holds a read only view of it. Both work. What does not work is both systems allowing edits to what people believe is the same thing.

The related decision is the customer identifier. Accounts in Salesforce and companies in ServiceNow are different records, and there must be one attribute joining them that neither side edits casually.

• In Salesforce Setup → App Manager → New Connected App, enable OAuth Settings.
• Set the callback URL to your instance (https://<instance>.service-now.com/oauth_redirect.do) and scopes api, refresh_token.
• Record the Consumer Key and Consumer Secret.

• Install the Salesforce spoke.
• Create an OAuth 2.0 entity (Authorization Code or JWT bearer for server-to-server) with the consumer key/secret and Salesforce token URL.
• Attach it to the spoke's Connection & Credential alias; use the Salesforce instance URL as the base.

Salesforce authentication has one property worth planning for: the refresh token is what keeps the connection alive, and it can be invalidated by a password change on the integration user, by a session policy, or by an administrator revoking access. When that happens the integration stops with an authentication error and no data moves, so the integration user should be a dedicated account exempt from the password rotation applied to people, and somebody should be alerted the moment authentication starts failing.

An afternoon against a Salesforce sandbox, and it exposes the loop problem before production does.

1. Create a case in Salesforce and confirm the corresponding ServiceNow record appears with the customer correctly resolved.
2. Update the ServiceNow record's status and confirm it appears in Salesforce.
3. Now watch what that update did on the Salesforce side. If it triggered an outbound message back to ServiceNow, you have a loop, and it will run until something stops it.
4. Update the same field in both systems within a few seconds and see which value survives.
5. Close the case in Salesforce and confirm the ServiceNow record does whatever you decided it should.
6. Delete nothing, and check what happens when a case is merged in Salesforce, because merges are common and they change record identifiers.

Step three is the one that catches teams out. Two systems that each update the other on change will keep each other busy indefinitely unless something distinguishes an update made by the integration from one made by a person. The usual answer is to check the updating user and skip when it is the integration account.

Salesforce Account       ServiceNow (core_company / account)
Name                 ->  name
AccountNumber        ->  u_sfdc_account_number
Industry             ->  u_industry
Id                   ->  u_sfdc_id  (store for correlation)

Field mapping between these two is harder than it looks because both systems have opinionated picklists and they do not agree. Status, priority and case type all exist on both sides with different values and different meanings, so the map is a translation rather than a copy.

The rule that keeps it sane is to map to the smaller vocabulary and accept the loss. If Salesforce has seven statuses and ServiceNow has four, several Salesforce values collapse into one, and that is fine provided somebody decided it. What is not fine is a mapping with no entry for a value, which silently produces a blank field or a default nobody chose. Enumerate every value on both sides and give each one a destination, including a deliberate one for anything unmapped.

• Build a flow triggered on a ServiceNow CSM case create/update.
• Use Salesforce → Create/Update Record with a SOQL upsert keyed on u_sfdc_id to avoid duplicates.

Volume is worth thinking about before this goes live. Every ServiceNow update that touches a mapped field becomes a Salesforce API call, so a business rule that updates records in bulk, or a nightly job touching thousands of cases, turns into thousands of calls against a quota shared with everything else the business runs in Salesforce. Restrict the trigger to the fields that genuinely need to travel, and batch where the spoke allows it.

• Preferred: create a Platform Event or Change Data Capture in Salesforce and subscribe with the spoke's streaming action.
• Simpler: an Apex trigger + Outbound Message/Named Credential that POSTs to a ServiceNow Scripted REST API on Account change.

// SOQL used by the spoke to pull an account
SELECT Id, Name, AccountNumber, Industry
FROM Account WHERE Id = :sfdcId

Two properties of the inbound path are worth knowing before you rely on it. It is at least once: Salesforce will retry a call it did not get a good response to, so the same event can arrive twice and your endpoint has to be safe to call twice. And it is asynchronous, so ordering is not guaranteed; two rapid updates can arrive in either order, which matters if you are applying them blindly rather than reading the current state.

Both point at the same design answer. Carry an identifier and a timestamp from the source, store them, and ignore an update older than the one you already applied. That handles duplicates and reordering together, and it is much easier to build now than to retrofit after a week of confusing data.

• Update an account in Salesforce and confirm the ServiceNow company record updates in near real time.
• Create a case in ServiceNow and confirm it appears/links in Salesforce.
• Bundle in an update set and promote.

• INVALID_SESSION_ID: refresh token expired, re-authorise the OAuth entity.
• Duplicates: your upsert external-id field isn't set, confirm u_sfdc_id mapping.
• API limits: batch high-volume syncs and respect Salesforce API call limits.

Version note: Salesforce retires older API versions on a published schedule, and an integration pinned to one will eventually stop working on a date that is known in advance. Track which version yours uses and treat the retirement as planned work. Governor limits and API call allowances also apply per organisation and per period, so a high volume integration can be throttled by something entirely outside ServiceNow, and the error will look like an intermittent failure rather than a limit. See the SailPoint integration, the Slack integration, the Workday integration and AI and ML integrations.

• No decision about which system owns the case. Two records, diverging within days.
• No loop guard. Each system updates the other indefinitely.
• Assuming events arrive once and in order. They do neither.
• An integration account subject to password rotation. It stops on a schedule nobody associates with it.
• Ignoring API limits. The symptom looks intermittent and the cause is a quota.

Connecting the two systems takes a day, and deciding which one owns the customer's problem is the conversation that makes the integration worth having.