ServiceNow and Salesforce
ServiceNow and Salesforce workflow boundaries make ownership clear when customer, employee, service, approval, and fulfilment processes cross enterprise platforms.
Start with the business outcome and the person accountable for it. Platform names are useful only after the work and authority are understood.
Describe who asks for help, what decision is needed, what service fulfils it, what information must be retained, and how completion is confirmed. Mark where a customer relationship, service operation, employee request, approval, or technical task enters the journey.
The ServiceNow solutions route provides the internal path for the ServiceNow operating model and workflow capabilities.
For each important record, assign one authoritative owner. That may include the customer relationship, case, service request, approval, fulfilment task, asset or service context, and closure evidence. A platform may display a reference without owning the decision.
Write down who may create, update, approve, close, reopen, and override the record. If two systems can make the same decision, define precedence before an integration is built.
The ServiceNow enterprise integrations route is the internal destination for considering controlled platform connections.
Send the smallest useful context that lets the receiving team act: reference, customer or service context, reason, priority, required action, owner, dependency, and return condition. Do not copy every field simply because the interface permits it.
Define the handoff event, acknowledgement, failure signal, retry decision, and human escalation. A successful API response does not necessarily mean the business handoff is complete.
The ServiceNow integration monitoring route gives the reader an internal path for ownership of integration exceptions.
Record which workflow changes can affect the other platform. Review field mappings, lifecycle states, permissions, error handling, release timing, and rollback responsibility. Make an exception visible to an owner rather than leaving it in an integration log.
The ServiceNow low-code governance route provides a related internal path when platform changes are created by multiple delivery groups.
Revisit the boundary when a new service, case type, approval, channel, integration, or operating team is introduced. Review duplicate records, conflicting updates, unowned exceptions, manual re-entry, and closure disagreements.
Only where each copy has a defined purpose and one system remains authoritative for the decision and lifecycle. Duplicate records need a clear relationship, update rule, and closure rule.
Define the source of truth for each field and lifecycle event. Limit write authority, identify the originating event, and make conflicts visible to an owner instead of allowing silent overwrites.
Treat the integration as a governed workflow: define the trigger, permitted action, context passed, human checkpoint, failure signal, and evidence of completion. The boundary is successful when the next owner can act without guessing which system is authoritative.
A boundary question arises when a customer or employee journey touches both platforms and the team argues about where the work belongs. The argument is easier to resolve if the journey is first written as stages: first contact, account and entitlement check, service request or case, approval, fulfillment, and closure. Each stage can then be assigned to the platform that owns its decision. Platform names come after that step. A team that starts from the question of which tool to use often copies a whole process into the wrong place simply because the tool was already licensed.
| Journey stage | Question the stage answers | Usual owner of the decision |
|---|---|---|
| Customer relationship and account data | Who is the customer and what has been agreed with them | The customer-facing platform, unless the data belongs to a service record |
| Commercial progression | Is there an opportunity or renewal to act on | The customer-facing platform |
| Service request or case | What has gone wrong, or what does the customer need done | The service platform, which holds the work record |
| Approval and fulfillment | Who approves, and who performs the work | The service platform, with business approvers named in it |
| Closure and customer communication | Has the outcome been confirmed to the customer | Agreed in advance, and often the platform that sent the last message |
The table describes a common pattern rather than a rule for any particular organization. What matters is that each row has one answer, written down before any connection is designed.
There are three common designs. In a reference design, one platform holds the authoritative record and the other shows a link with little or no copying. This is simple to govern, but users on both sides must accept that some information lives elsewhere. In a one-way handoff, a record is created in one platform and its essential context is sent to the other, which then owns the next stage. This suits a clean transfer of responsibility, but the sending side loses sight of progress unless a status returns. In a bidirectional design, both platforms update a shared set of fields. This is the hardest to run, because every field needs a rule for which side may change it and what happens when both try. Many journeys can work with the first or second design, and only a small number of fields may justify the third. Where the handoff uses an integration pattern that is more than a simple notice, the pattern should be chosen for the stage, not for the whole journey.
Closure is where disagreements often surface. A case can be closed in the service platform while the customer-facing platform still shows an open follow-up, or the reverse. Before the boundary is built, define what closed means for each record type, which event sets that state, and whether the other platform is told automatically or through a person. Include the reopening rule. A case reopened by a customer should not silently reopen an approval that has already been acted on, and the reason for each reopening should be visible on both sides.
When a journey moves from one platform to another, open work is the real risk. Completed history can usually be migrated as a read-only copy, but each open item needs a decision: finish it on the old platform, move it with its context to the new one, or close it with a stated reason. Count the open items at the start of cutover, assign an owner to each group and agree a date after which no new work starts on the old route. The data migration, reconciliation and cutover page looks at reconciliation evidence after a cutover. A cutover that moves everything at once without such a list can produce duplicate customer contacts in the first weeks.
They can, if a reference design is used and access is granted for a specific purpose. The question to settle is what they need to see, not whether the platform permits it. A summary showing status and the next expected step often serves them better than full access to the work record.
Name one sender for each stage. Two automated messages about the same event, sent from two systems, make the organization look disorganized and make a reply harder to answer correctly. The customer service case routing page looks at moving a customer question to the group that can make the next decision, which is related to choosing who answers.
Usually it needs a review rather than a rebuild. A new team adds stages and owners. The review should check that each new stage has an owner on one platform and that its handoff in or out is recorded.
Schedule a review after the first full business cycle and after any significant change to either platform. The review should examine records created on both sides, handoffs that were re-entered by hand, and closures that were disputed. Each of these is evidence of a boundary decision that was never written down or never followed. Record the outcome as an amendment to the boundary, so that the next person asking where a record belongs can find the answer without a meeting. The Salesforce and ServiceNow integration boundaries page looks at the same question of where customer context, service ownership, approvals, fulfillment and closure evidence live.
Every boundary produces exceptions: a handoff that did not arrive, a status that disagrees across the two platforms, or a customer who received two messages. Someone must own the queue where these appear, and that owner should not simply be whoever built the integration. The queue owner decides whether an exception is a data fault, a process gap or a genuine conflict between two decisions. Each class is routed to the person who can fix it, and the outcome is recorded against the boundary, so repeated exceptions show up as a design problem rather than a daily chore. Where customer-facing and service teams share the queue, agree in advance how quickly each team responds, so that a customer waiting for a reply is not left between two groups that each assume the other is answering.
Keep the queue manageable by measuring what reaches it. If most exceptions share one cause, that cause belongs on the agenda of the next boundary review, not the individual cases.
Bring the workflow, integration, or ownership question that needs a clearer operating model.
Discuss workflow boundariesGuides from the Oblytech ServiceNow library that explain the practice behind this page.