ServiceNow REST and SOAP Integrations: Roles, Responsibilities and RACI
Integration Owner and Stewardship
Every integration needs a single owner who holds responsibility for the integration working and remaining current. The integration owner is typically a platform engineer or a member of the integration team. This person is accountable for: integration configuration, testing, deployment, monitoring, and escalation when issues arise.
The integration owner is not necessarily the person who built the integration, but they own its ongoing health. If the original developer leaves, the integration owner ensures knowledge transfer so continuity is not lost.
RACI Matrix for Integration Lifecycle
Define roles and responsibilities for key integration activities:
Design phase: Business Analyst (Responsible for requirements), Integration Architect (Accountable for design), API vendors (Consulted for API documentation), Compliance (Consulted for data protection requirements).
Implementation: Developer (Responsible for coding), Integration Architect (Accountable for architecture decisions), Quality Assurance (Responsible for testing), Integration Owner (Accountable for quality).
Deployment: Developer (Responsible for deployment), Integration Owner (Accountable for deployment decisions and rollback if needed), Release Manager (Consulted for deployment scheduling), Operations (Informed of deployment).
Monitoring and support: Operations (Responsible for monitoring and alerting), Integration Owner (Accountable for troubleshooting and fixes), Source system owner (Consulted if issues are on the source system side), Incident Management (Informed of integration failures).
Integration Governance and Decision Rights
Who decides whether an integration is approved? Typically, the Integration Architect reviews the integration design, the Security Officer reviews data protection measures, and business stakeholders approve the business value. Approval should be documented; do not deploy integrations without documented sign-off.
Who decides whether an integration can be updated or modified? The Integration Owner should have authority to approve changes that impact the integration. If changes are major (new data sources, new integration patterns), the Integration Architect should review. If changes are minor (parameter adjustments, routine maintenance), the Integration Owner’s approval is sufficient.
Escalation Paths for Integration Failures
Define clear escalation for integration failures. If an integration fails, Operations alerts the Integration Owner. The Integration Owner investigates and either resolves the issue or escalates to the Integration Architect (if the architecture needs to change) or the source system owner (if the problem is on the source system). Critical failures (integration down for an extended period set in the escalation policy) escalate to the Integration Program Manager or CIO.
Define response time targets: critical integration failures should be acknowledged and resolved within targets agreed by the owners, and less critical failures within longer agreed targets.
Knowledge Transfer and Documentation Responsibilities
The Developer who builds the integration is responsible for creating documentation (integration design, API references, data mapping, error handling). The Integration Owner is accountable for maintaining documentation as integrations change. When developers leave, knowledge transfer from the developer to the Integration Owner is the developer’s responsibility; the Integration Owner is accountable for ensuring transfer is complete.
Document critical information: which APIs are in use, which data is being synced, what happens if the integration fails, how to test the integration, how to troubleshoot failures.
Ownership Gaps and Escalation
Who owns integrations with external vendors? Usually, a joint team: the vendor manages their API and uptime, your organization manages the integration configuration and testing. Clarify split responsibility; do not assume the vendor handles everything or vice versa.
Who owns data quality when integration pulls bad data from the source system? The source system owner is responsible for data quality; if data is bad at the source, the integration owner escalates to the source owner for remediation. The integration owner can implement validation rules to catch bad data, but they cannot fix the data itself.
Additional Ownership Context
The integration owner role is strategic and operational. Strategic responsibilities include evaluating new integration requirements and assessing build-versus-buy decisions. Operational responsibilities include monitoring integration health, troubleshooting failures, and managing routine updates. Many organizations split these between a strategic architect and an operational owner, but both roles must be accountable and coordinate closely.
Name the role that answers at two in the morning
Roles for integrations are tested during failures, not during planning. When a scheduled feed stops or a remote endpoint starts returning rejections, the first question is who is looking at it now, and the second is who can decide to pause the flow. A roles model that answers only the design questions leaves those two gaps open. For each connection, record a primary responder, a backup, the person allowed to stop the flow, and the person allowed to restore data. Those four names matter more than any matrix that covers the project phases.
Who holds which decision during an incident
| Decision | Role that decides | Role that must be informed | Evidence the decision needs |
|---|---|---|---|
| Pause a live flow | Integration owner or delegate | Business owner of the data | The failure type and the volume of items affected |
| Replay failed items | Integration owner with the business data owner’s agreement | Consuming team | Confirmation the cause is fixed and duplicates are guarded |
| Rotate a credential after exposure | Security owner | Platform administrator and integration owner | The list of flows that use the credential |
| Change a field mapping in production | Integration owner, with change approval | Consuming team and reconciliation owner | The sample comparison from sub-production |
| Declare the incident closed | Integration owner | Business owner and service desk | Reconciled counts and a check that the backlog is empty |
What a good handover between shifts looks like
Integration incidents often span shifts, because a backlog can take hours to clear. The outgoing responder should hand over the open failure category, the items still waiting, the actions already taken and the next action with its owner. A handover that says only that the feed is broken forces the next person to repeat the diagnosis. Keep the handover note in the record of the incident rather than in a personal message, so that the next responder sees the same facts as the last one.
Owning a connection to a vendor’s system
When a vendor hosts the remote system, responsibility splits along lines that must be written down. The vendor generally owns availability of its endpoint and the changes it publishes. The instance owner generally owns the identity used, the mapping, the monitoring of the flow and the decision to pause it. Disputes arise in the gap: a vendor change that breaks a mapping, or an outage that the monitoring reports as a platform fault. A short split-responsibility statement per vendor resolves most of these before they start.
An ordered first-hour response
- The responder confirms the failure category and whether it affects one connection or several.
- The responder checks whether the credential or the remote endpoint is the common factor.
- The integration owner decides whether to pause the flow, and records the decision and its time.
- The business owner is told what data may be late and what the process will do meanwhile.
- The responder opens or updates the incident and links the failure records to it.
Coverage outside working hours
A connection that serves a process running overnight needs a named person for that period, with the authority to pause it and the instructions to do so. Assigning the alert to a shared mailbox without a named owner is a common gap. If coverage cannot be staffed around the clock, the design should degrade safely, with queued items held until a person can act, rather than failing and losing them. Write the escalation path as an ordered list of named roles, so that a responder who gets no answer from the primary contact knows exactly who comes next. Ask the backup to take a simulated alert from time to time, because a path that has never been walked tends to fail at the first missing name.
Questions about roles for integrations
Can the developer who built the connection also be the integration owner?
They can, provided the role is documented and the knowledge is shared with a backup. A developer who is the only person who understands a connection is a single point of failure, and the register should show that risk.
Who should be allowed to restore data after a failure?
The integration owner runs the restore, and the business data owner approves it. Restores done without that approval can overwrite changes that people made in the meantime.
Does a RACI chart still help?
It helps for planning and for the less frequent decisions. During an incident, the short list of four named roles per connection is faster to use than a full matrix.
Have a specialist test the named roles
A roles model is only useful if the named people accept the work. Alert routing to the responder is a monitoring question, covered in the monitoring and ownership article, and identity boundaries for integrations covers which source is authoritative for identity.
Related guides: ServiceNow REST and SOAP Integrations Governance Model.
Frequently asked questions
What should we do if the Integration Owner leaves?
Knowledge transfer is critical. Before the owner leaves, they should document the integration, train a successor, and transfer ownership. The handover should take as long as needed to transfer knowledge; do not let someone leave without ensuring continuity. The integration should not go unmaintained.
How many integrations should one person manage?
It depends on complexity. A simple integration (pull data nightly, load into a table) requires minimal ongoing effort; one person might manage 10-20 such integrations. Complex integrations (real-time, bidirectional, error-prone) require more attention; one person might manage 3-5. Monitor work hours; if integration owners are overwhelmed, hire or redistribute.
Should integration owners be on-call for integration failures?
Yes, for critical integrations. An integration failure may be urgent (customers cannot order, payroll is blocked). On-call rotation for critical integration support is necessary. For non-critical integrations, business-hours support is sufficient.
Related guides
Planning, running or fixing a ServiceNow programme? Tell us where you are and we will suggest a sensible next step.
Contact us