ServiceNow MID Server: Roles, Responsibilities and RACI

Running MID Servers is a shared responsibility across the ServiceNow platform team, the infrastructure team that hosts them, the network team that opens paths, the security team that controls credentials and the database team that grants discovery access. This page sets out those roles, the RACI matrix for the common operational activities, the escalation paths, and the ownership gaps that appear at handoffs. Later sections cover who signs off which change once a MID Server is live and how to onboard a new administrator.

Core Roles and Responsibilities

MID Server Administrator: Owns MID Server configuration in ServiceNow. Creates MID Server records, configures which integrations use which MID Server, manages MID Server authentication. This person is usually a ServiceNow administrator or platform engineer. Responsible for troubleshooting MID Server connectivity issues from ServiceNow side.

Infrastructure Team (hosting MID Servers): Manages the virtual machines or containers hosting MID Servers. Owns patching, updates, performance monitoring. Ensures MID Servers have adequate CPU, memory and network. This is usually a system administration or DevOps team.

Network Team: Provides network connectivity from MID Servers to external systems. Opens firewalls, configures VPN access, provides IP allowlisting for cloud services. Troubleshoots network connectivity issues.

Security Team: Manages MID Server credentials for external systems. Stores credentials in secure vault, rotates them regularly, audits access. Ensures MID Servers do not pose security risk. Reviews integrations for security compliance.

Database Team (for discovery): Provides database credentials and permissions for discovery scans. Ensures MID Servers can query system catalogs to discover databases and schemas. Troubleshoots discovery connectivity issues at database level.

RACI Matrix for MID Server Operations

Legend: R=Responsible (does the work), A=Accountable (final decision authority), C=Consulted (provides input), I=Informed (kept in loop)

Escalation Paths and Ownership Gaps

Define escalation paths clearly. If MID Server is not communicating, who escalates and when? Usually: ServiceNow administrator troubleshoots first, escalates to infrastructure team if it is a hosting issue, to network team if it is connectivity, to security if it is credentials. Document this decision tree.

Common ownership gap: credential management. If a database password changes and discovery stops working, who is responsible? If this is not assigned clearly, discovery breaks and no one takes action. Assign explicit responsibility: “Database team will notify Security team of password changes in advance; Security team will update MID Server credentials as soon as it is notified.”

Common ownership gap: MID Server patching. Who decides when MID Servers get patched? Does it happen every month, quarterly, annually? If not decided, MID Servers fall behind on security patches. Assign responsibility to infrastructure team and agree on patch schedule upfront.

Common ownership gap: MID Server decommissioning. When an external system is retired and MID Server is no longer needed, who removes it? Who verifies no integrations are using it? If not assigned, dead MID Servers accumulate. Assign ownership to MID Server administrator to review and retire unused MID Servers quarterly.

On-Call and Incident Response

MID Servers fail frequently enough that on-call coverage is valuable. Define which team is on-call for MID Server issues: infrastructure team (MID Server not starting), network team (connectivity broken), security team (credential issues), or a combined team with escalation between them.

Create a troubleshooting runbook for common MID Server issues. When MID Server is down, the on-call person should not have to diagnose from scratch. A runbook that guides them through likely causes accelerates resolution.

Define SLAs for MID Server recovery. How quickly must a failed MID Server be restored? Is the current recovery time acceptable, or must it be faster? Different organisations have different tolerance based on whether MID Servers support critical integrations.

Training and Knowledge Transfer

MID Server operations require skills from multiple teams. Provide training so each team understands their role and how it connects to others. A network engineer who does not understand that a firewall change affects discovery will make changes without considering impact.

Maintain runbooks and documentation. When someone new joins the team, they should have documentation of how MID Servers are managed. Without this, knowledge is lost when experienced people leave.

Who signs off which change once a MID Server is live

A RACI chart tells you who does the work. It says much less about who may approve a change while the estate is running, and that is the question that causes arguments at two in the morning. A credential rotation, a new cluster member, a changed proxy setting and a retired target all look like small operational tasks. Each one can also change what a MID Server is allowed to reach. The practical fix is a second, narrower table that sits beside the RACI and answers only the approval question for each class of change, along with the evidence the approver should see before saying yes.

Many teams find that the person who can make a change is not the person who should approve it. A ServiceNow administrator may be able to edit a MID Server record, but the decision to widen what that record can reach belongs to whoever owns the target. Writing that difference down is the cheapest control you will add to the operating model.

Approval matrix for routine MID Server changes

The matrix below is a starting point for a team that already has named owners. Adjust the approver column to match your own change process. The evidence column matters most, because an approval given without evidence is a formality.

Onboarding a new MID Server administrator

Handover is where ownership often breaks. The outgoing administrator knows which hosts are fragile and which integrations are noisy, and that knowledge rarely reaches the written chart. Use this sequence when someone new takes over the estate.

1. Walk through every cluster with the outgoing administrator and record which hosts have needed manual restarts in the last quarter.
2. Match each active integration to a named service owner, and mark any integration that has no owner as a gap to close before handover is complete.
3. Give the new administrator read access to the MID Server records and logs before any write access, so they can see the normal pattern first.
4. Pair them with the outgoing administrator for at least one change of each class in the approval matrix.
5. Confirm the on-call route, including who is contacted when a target owner is unreachable and a credential expires out of hours.
6. Close the handover with a short written note of what was agreed and who now signs each change class.

What a RACI does not settle

A RACI cannot tell you what to do when two accountable people disagree. Decide in advance who breaks the tie. In most estates it is the service owner of the affected business process, because that person carries the cost of a missed scan or a failed integration.

How to keep the chart honest over time

Review the chart when an integration is added or retired, not on a fixed calendar. A chart that was accurate at launch often describes an estate that no longer exists by the next budget cycle.

When a single team should hold every role

A small organization with one platform team may reasonably hold every role. The risk is not the overlap itself but the lack of a second approver for credential and network changes. Even a small team should write down who checks whom.

Whether contractors can hold the administrator role

Contractors can administer MID Servers, but the approval matrix should not rely on a contractor as the sole approver for production targets. Keep approval with a permanent employee who can be reached during an incident.

Where the roles meet the wider platform model

The MID Server roles sit inside the broader governance of the platform. If the platform already has a model for who owns integrations and who approves platform changes, reuse it rather than building a parallel one. The governance model for MID Servers is the page on where approval decisions sit in that wider structure, and the platform operating model and governance page covers the wider model.

Where the chart is contested or the estate spans several business units, a short working session often clears the ambiguity faster than another round of email.

Frequently asked questions about approving MID Server changes

Should the MID Server administrator approve every change?

No. The administrator should own the mechanics of a change and check that it is complete. The approval for a change that affects a target belongs to the target owner, because only that person knows whether the new reach is intended.

What evidence is enough for a credential rotation?

A successful test against each consuming cluster, the change reference, and a note of who performed the rotation. A rotation that is only confirmed in the vault is not evidence that the MID Server can still authenticate.

Who is accountable when a retired server is still referenced?

The person who approved the retirement is accountable, even if the reference was added later. That is why the approval step should include a search of scheduled jobs and integrations that name the server.