CONTEXTWhy the seam is the whole job
Salesforce is the system of record for the relationship: who the customer is, what they bought, what they are worth, and every conversation a revenue or service team has had with them. ServiceNow is the system of record for the work: the incident, the change, the asset in the CMDB, the SLA clock, and the engineer assigned to it. Both are correct. The failure is not in either tool. It is that a single customer event, a raised case that turns out to be a platform outage, has to live truthfully in both, at the same time, and almost nobody designs that seam on purpose.
When the seam is missing, people become the integration. A service agent reads a ServiceNow ticket aloud over Slack so a Salesforce user can paste it into a case. That is the swivel-chair, and it is expensive in a way that never shows up as a line item: latency, transcription errors, and two records that describe the same reality differently within an hour. The goal of a Salesforce and ServiceNow integration is to retire that human relay.
01The shared record, kept in lock-step
The first build, and usually the highest-value one, is a two-way link between the Salesforce Case and the ServiceNow Incident. A case raised by a customer that turns out to be an infrastructure fault opens an incident; the incident's status, assignee, and resolution flow back onto the case so the service agent never leaves Salesforce to answer "where is my fix". The hard part is not the API call. It is deciding which system owns which field, so an update on one side never silently overwrites the truth on the other. Customer-facing summary and priority belong to Salesforce; technical state, work notes, and SLA timers belong to ServiceNow. Map it once, deliberately, and the two records describe the same event without arguing.
Identity and ownership first
Before a single field syncs, two questions decide whether the integration survives: how is the same customer matched across both platforms, and which system is allowed to change a given field. Resolve identity on a stable key, not a display name, and write an ownership rule for every shared field. Integrations that skip this look fine in the demo and corrupt data within a month.
02 / 03Event-driven sync, and workflow that crosses the line
Polling is the lazy default and it ages badly: it is either too slow to be useful or so frequent it hammers both APIs. Prefer events. A Salesforce Platform Event or an outbound message fires on a meaningful change, the integration layer transforms and forwards it, and ServiceNow does the same on the way back. The payloads should be idempotent and replayable, so a missed message can be re-driven without creating a duplicate. On top of the sync sits the genuinely valuable pattern: orchestrated workflow that spans both. A high-value account hits a sev-1, and the same trigger that opens the incident also alerts the account team in Salesforce and starts a Slack bridge. One event, two systems, no human relay.
Pick a winner and consolidate, and you do not get one system. You get one worse system, and a migration that outlives its sponsor.
DECISIONWhat belongs where
Most integration arguments are really ownership arguments in disguise. Settle them with a table, not a meeting. The rule of thumb: if the field describes the relationship, Salesforce owns it; if it describes the work, ServiceNow owns it. Everything shared is read-only on the side that does not own it.
| Record / field | Salesforce owns | ServiceNow owns |
|---|---|---|
| Customer identity & account | Yes | Reference |
| Case summary & customer priority | Yes | Reference |
| Incident technical state & work notes | Reference | Yes |
| SLA clock & fulfilment tasks | Reference | Yes |
| CMDB, assets & change records | Reference | Yes |
| Entitlement & contract value | Yes | Reference |
EFFORTWhere the work actually goes
Teams budget an integration as if it were the build, the API calls and the field mapping. In practice the connector is the small part. The cost lives in the decisions and the failure paths: agreeing ownership, resolving identity, and handling the message that does not arrive. Plan for that shape and the project lands; plan for the happy path only and the last twenty percent doubles the timeline.
04Governance, or it rots quietly
An integration is not done when the first record syncs. It is done when you can answer, six months later, why a field changed and whether a failed message was ever re-driven. Log every cross-system write with its source, keep a dead-letter queue for messages that fail transformation, and alert a human when the backlog grows rather than discovering it during an outage. None of this is glamorous, and all of it is the difference between an integration that is trusted and one that is quietly worked around.
The two failures we are called in to fix most often: a sync loop, where each side updates the other in an endless echo because no ownership rule breaks the tie, and silent drift, where a one-time data load was never made two-way and the records diverge until someone notices in front of a customer. Both are designed out at the ownership-map stage, and neither is cheap to fix after launch.
STARTWhere to begin
Begin with one painful, well-understood flow, almost always the case-to-incident link for a single high-volume service team. Write the ownership map, resolve identity on a stable key, make the sync event-driven and replayable, and instrument it before you widen scope. Once that one seam has run cleanly for a quarter, the harder patterns, change orchestration, CMDB-aware routing, asset-driven entitlement, become safe to attempt. What you must not do is start by asking which platform to keep. That is the question that turns a six-week integration into a two-year migration, and the customer still falls in the gap while you argue.