ServiceNow enterprise platform integrations with clear boundaries

Choosing a pattern before choosing a tool

Integration projects often start with the tool and discover the pattern later. The pattern determines how failures behave, who must be available when something breaks, and how much change a single partner update can cause. A direct call between two systems is usually simple to build and can be fragile to change. A message published to a queue decouples the sender from the receiver but moves the failure question into a backlog. A scheduled file exchange is easy to audit and slow to correct. Choosing among them is a decision about tolerance for delay, tolerance for duplication, and the people who will answer the phone when things go wrong.

Identity matching across platforms

Many enterprise integrations depend on matching a record in one system to a record in another, and matching is where many quiet errors begin. A shared email address, a similar name or an identical employee number in a legacy system does not prove that two records describe the same person or asset. A defensible matching rule names the identifier that is authoritative in each system, states what happens when the identifier is missing, and says who resolves a probable match that the rule cannot settle. Ambiguous matches should go to a queue with an owner, not be resolved by whichever record was created first. Recording the rule is more important than making it clever, because the rule will be questioned in an audit or a dispute long after its author has moved on.

A status mapping that looks complete and is not

Statuses are where integrations quietly disagree. Consider a handoff in which the sending system marks a request as complete when the data has been accepted by the receiving interface. The receiving system marks the same request as in progress until a person has approved the resulting record. Both statuses are accurate within their own system, and a dashboard that shows the sender’s view will report the work as finished while the business process is still open. The fix is to write the mapping as a table that shows each sending status, each receiving status and the business meaning of the pair, including the pairs that should never occur. Partial completion needs its own row, because it is the state most likely to be lost between systems.

The example is an illustration of the reasoning pattern. It is not a description of a particular delivered integration.

Credentials and permitted actions

An integration account is a privileged identity that often outlives the project that created it. Its permitted actions should be written as a list rather than inherited from a role that happened to be convenient during testing. Each credential needs a named owner, a documented rotation schedule and a record of which integrations use it, so that a rotation does not break a process nobody remembered. Reviews should check whether the account can still do everything it was granted, because permissions tend to accumulate during build and are rarely removed afterwards. The IntegrationHub and API automation page covers authentication, error paths and ownership for ServiceNow integrations.

Changes to the other side will arrive without warning

Integrations can run cleanly on the day they are built and still break months later, when the other platform adds a mandatory field, renames a status or changes the meaning of an existing code. Vendors release changes on their own calendar, and internal teams change their own forms and workflows without telling the integration owner. A review path should therefore cover four kinds of change: new fields, changed status values, changed endpoints and changed validation rules. Each kind needs a named recipient, a test that exercises the affected handoff, and a rule for when a change can be deployed without a full retest. A connected system that is not on anyone’s change list is one that will fail silently.

Testing handoffs before any release

A handoff test should walk the status mapping from start to finish in each direction, using ordinary records, delayed records, duplicate deliveries, rejected records and a record whose schema has changed on purpose. The purpose of the last case is to confirm that the monitoring notices the change rather than discarding the message quietly. Results should be recorded against the mapping table, so that a reviewer can see which rows were exercised and which were not. Handoffs that were never exercised are the ones that surface first in production.

Questions to ask before connecting two platforms

What happens to the business process when the integration is down for a day?

A good answer describes the manual fallback, the people who run it and the point at which the backlog becomes a business problem. If the answer is that nothing happens, the integration may be carrying less weight than the project assumes.

Which system is the record of truth for each important field?

The answer should be a field list, not a general statement. Ask what happens when two systems disagree about the same field, and who is entitled to correct it.

How will changes to the other system’s schema be noticed?

Look for a review path that covers new fields, changed statuses and changed endpoints, and for a named person who receives the vendor or partner notices that announce those changes.

Where this section stops

This section does not select a middleware product, price a connector or define the monitoring of a particular interface. Those depend on the systems involved, the volume of transactions and the people responsible for each side. The Salesforce and ServiceNow integration boundaries page covers where customer context, service ownership and approvals sit between those two platforms, and the ServiceNow integrations section covers connecting ServiceNow to systems such as ERP suites, monitoring tools and HR platforms. Which pattern suits a given pairing depends on the two systems’ change calendars, which only a technical discussion can establish.

If two platforms already exchange data and nobody can say which one is right when they disagree, get in touch about the boundary and bring the list of handoffs and the people who receive the failure messages.