Set Clear Boundaries Between Salesforce and ServiceNow

Which platform should hold each record type

When customer-facing teams use Salesforce and service operations teams use ServiceNow, the same real-world event often appears in both. A customer reports a fault, a contract changes, or a field visit is booked, and each platform wants a record. The boundary question is not which platform is better. It is which platform is the system of record for each kind of information, and which platform only holds a reference to it.

Start with the record types, not the features. Customer accounts, contacts, opportunities and commercial agreements usually belong to the commercial platform. Incidents, changes, configuration items and fulfillment tasks usually belong to the operations platform. The two sets overlap at the customer and the service, and that overlap is where most boundary problems start.

Customer context versus service ownership

The service team needs enough customer context to act, but it does not need every commercial detail. The boundary should say which customer facts cross into the operations platform, such as identity, service tier and contact preferences, and which stay behind. Copying the whole customer record creates a second set of data to keep accurate, and it encourages operations users to edit commercial facts they have no authority to change.

Ownership of the service itself should be explicit as well. When a case is open in both platforms, the boundary must state which one the customer should ask about, which one the agent updates, and which one the commercial owner reads. A customer who receives two different answers from two systems may attribute the difference to the vendor, whatever the cause.

Approvals that cross the boundary

Some decisions start in one platform and must be approved in the other. A credit exception raised by a service team may need a commercial approver, and a change to a contracted service may need both a commercial sign-off and an operational risk review. Each cross-boundary approval needs a single named decision owner, a defined request record on each side, and a rule for what happens if the approval is not returned.

• A request record on the originating side that states what is being asked and why.
• A decision recorded on the approving side, with the approver's name and date.
• A return message that the originating side can act on without re-reading the whole history.
• A timeout rule that escalates the request rather than letting it wait silently.

Closure evidence and who may close

A service issue that spans both platforms can look closed in one and open in the other. The boundary should say which platform's closure state counts for the customer and which counts for internal reporting. It should also say which role may close a shared issue, and what evidence that role must record. Closing from one side should not silently leave the other side open. Where a closure must be synchronized, the design needs a reconciliation step that checks both states on a schedule.

Duplicate identities and reconciliation

Duplicate customers and duplicate services are a common result of a poorly drawn boundary. Each platform may create its own identifier, and a matching rule that works in one may fail in the other because the fields differ. The design should choose a stable key, state the matching fields used when no key exists, and define who resolves an ambiguous match. Reconciliation should compare counts and key identifiers between the two sides, and the discrepancies should go to a named owner rather than into a log that nobody reads.

What this page does not cover

This page sets the boundary question and the controls that support it. It does not specify the connector, the message format or the field-level mapping for any particular pair of instances, because those depend on the current configuration and the integration design. It also does not cover the internal workflow inside either platform. A service workflow is described on the service workflow design page, and the wider integration design is described on the integration architecture page. For the ServiceNow side of the same question, the ServiceNow and Salesforce workflow boundaries page addresses workflow boundaries between the two platforms.

Testing the boundary with a realistic case

A boundary looks sound on a diagram and fails on the first case that crosses it in an unusual way. Choose a case that involves a customer whose contact has recently left, a service that was transferred mid-issue and an approval that expired over a weekend, then walk it through both platforms and record what each side shows at every step. Repeat the test after any change to a shared field or a routing rule. The exercise is quick, and it finds the gaps that a design review tends to miss.

Change of ownership for a customer or service

Customers change owners, services move between teams and contracts are novated. Each change alters which record is authoritative and which team the customer should contact. The boundary should describe the transfer event on both sides, the period during which both records may show the old owner, and the check that confirms the transfer is complete. A transfer recorded in only one platform leaves the other sending messages to the wrong person until someone notices, so the transfer should be treated as a cross-platform change with its own reconciliation step.

Reporting across two platforms without double counting

Leadership reports often combine commercial and service measures, and the boundary determines whether those measures can be combined safely. A customer who raised three service requests in one month should not appear as three customers, and an open service issue should not be counted as lost revenue in a commercial dashboard. Agree the key that joins the two data sets, the grain of each report and the owner of each measure before the dashboard is built. Where a figure cannot be reconciled, show it as a difference with its cause rather than forcing it into one total.

Access and data visibility on each side

A user in one platform may need to see a summary from the other without holding access to its full record. The boundary should define which fields are visible across the line, to which roles, and for what purpose. Copying a summary into a field is one option, and a linked reference that opens the record under its own access rules is another. Each carries a different risk: a copied summary can go stale, and a link can expose more than the user should see. Review access whenever a role changes, because cross-platform visibility often outlives the reason it was granted.

Questions teams ask about Salesforce and ServiceNow boundaries

Can both platforms hold the same customer record?

They can hold a copy, but one must be authoritative for each field. Copies without an authority rule are a common source of conflicting data.

Which platform should the customer contact?

The customer should contact the channel the business has designated for the type of request. The boundary should say so, and both teams should use the same wording.

How often should reconciliation run?

It depends on how quickly the data changes and what a mismatch costs. The schedule should be set during design and reviewed after the first few months of live use.

Who decides when the boundary should move?

The joint owner of the two platforms should decide, with the commercial and operations leads approving changes that move a record type from one side to the other.

The data migration and integration page is the related Salesforce services page.