An MSP running many clients inside one ServiceNow instance has solved the data problem and inherited a routing one. Domain separation keeps each client’s records walled off in their own domain, so client A never sees client B’s incidents in the queue. The moment an incident needs to wake someone up, though, that wall has to hold on the way out the door too. The worst page an on-call engineer can get is the one that belongs to another client.
This guide covers how domain separation works, where the leakage risk lives, how per-domain routing and on-call hold the line, and why correlation has to respect the same boundary. For the full integration, start with the AlertOps and ServiceNow two-way integration guide.
Table of Contents
- One Instance, Many Client Domains
- The Worst Page Is the One for Another Client
- Domain-Aware Routing Holds the Wall
- On-Call and Escalation, Scoped Per Client
- Correlation That Respects the Boundary
- With and Without Domain-Aware Routing
- Conclusion
- FAQ
One Instance, Many Client Domains
Domain separation is the ServiceNow capability that lets an MSP or a large holding company run several distinct businesses inside a single instance while keeping their data, processes, and visibility apart. Each client lives in its own domain. Incidents, assignment groups, business rules, and the records a responder sees are scoped to that domain, so a technician working client A’s queue doesn’t see client B’s tickets, and client B can’t see client A’s.
The reason MSPs run it this way is sound. A shared instance means one upgrade cycle, one set of integrations to maintain, one platform to administer, and a per-client cost that stays sane as the client list grows. The alternative, a separate ServiceNow instance per client, multiplies the operational overhead by the number of logos. Domain separation is how an MSP gets the economics of one instance without letting clients bleed into each other.
ServiceNow holds that separation cleanly inside its own walls. The records know which domain they belong to. The catch shows up at the edge, the moment an incident stops being a record and becomes a phone call, because whatever tool places that call has to honor the same boundary the instance does. Most paging tools weren’t built with that boundary in mind at all.
The Worst Page Is the One for Another Client
Picture the failure plainly. A monitoring alert opens an incident in client B’s domain. The paging layer reads the assignment group, finds a database on-call group, and dials whoever is on call for it. Except the on-call engineer who picks up works for client A. They’re now looking at an incident, with its hostnames and its context, for a company that isn’t theirs.
That’s not a noisy-alert problem. It’s a confidentiality breach and a trust problem at the same time. The engineer has seen another client’s environment. The right client’s responder never got paged, so the actual incident sits unworked while its SLA clock runs. And the MSP now has an awkward conversation with two clients instead of zero.
It happens because routing collapses to one field. Assignment group names repeat across clients, or a generic group catches incidents from more than one domain, and a router that reads only the group has no idea the two incidents belong to different worlds. The instance kept the domains apart. The page didn’t.
Domain-Aware Routing Holds the Wall
AlertOps reads the domain first. Every incident that flows in through the two-way ServiceNow integration carries its domain, and that domain scopes the routing decision before anything else runs. Client B’s incident is matched against client B’s routing rules, client B’s assignment groups, and client B’s on-call schedule. There’s no path by which it reaches a client A responder, because client A’s rules are never in scope for a client B incident in the first place.
Inside each domain, routing works the way it does for any single-client shop. The incident lands on the right assignment group, escalates through that group’s Escalation Policy when the first responder doesn’t answer, and writes its progress back to the ServiceNow record. Domain awareness doesn’t add a layer of friction on top of normal routing. It sets the perimeter that normal routing operates within, and the deeper mechanics of group-based delivery are the same ones covered in routing by ServiceNow assignment group.
The practical effect is that two clients can share an instance and still run as if each had the paging stack to itself. An on-call engineer for one client never learns the other exists, which is the whole promise of domain separation carried through to the part of the night when someone actually gets woken up.
On-Call and Escalation, Scoped Per Client
Each client domain gets its own on-call world. Schedules, rotations, and escalation chains are defined per domain, so the people who can be paged for client A are drawn only from client A’s responders, and client B’s roster is a separate set of names entirely. AlertOps supports rotating schedules, fixed schedules, and override shifts inside each domain’s scope, which matters because no two clients keep the same calendar. One runs a follow-the-sun rotation, another wants weeknights covered by a small team, a third has its own holiday list.
This also fixes a quieter version of the leakage problem: coverage gaps. When schedules are tangled together, a hole in one client’s rotation can silently fall through to whoever is on the shared escalation path, which is often someone from the wrong client. Scoping the schedule to the domain means a gap in client A’s coverage escalates up client A’s own chain, to client A’s manager, and never spills sideways.
For the MSP administering all of this, the win is that per-domain on-call is configuration, not a separate deployment per client. The schedules and policies live in one AlertOps account, organized by domain, managed in one place.
Correlation That Respects the Boundary
Grouping related alerts is where a shared instance can leak in a way that’s easy to miss. Correlation exists to fold many signals about one event into a single incident, but on a multi-client instance it has to ask which client first. Two database timeouts at the same minute might be one incident if they belong to the same client, or two unrelated incidents at two companies that happen to share a clock. Group them across domains and you’ve merged two clients’ outages into one ticket, paged a blended responder set, and leaked each client’s signals into the other’s incident.
AlertOps scopes correlation to the domain. OpsIQ runs its correlation engine inside each client’s boundary, so similarity modeling and grouping windows only ever consider alerts from the same domain. Client A’s signals group with client A’s signals. Client B’s never enter the comparison. The noise reduction an MSP wants from correlation, up to 68% fewer alerts in enterprise deployments (AlertOps platform data), still lands, but it lands per client, without a single grouped incident ever spanning two of them.
That keeps the post-incident record honest too. When an incident closes and its history syncs back, the ServiceNow record for client A carries only client A’s correlated signals, and the same for client B. The same per-event grouping logic, applied within each domain, is detailed in alert correlation before ServiceNow.
With and Without Domain-Aware Routing
| Routing on assignment group alone | Domain-aware routing | |
| What decides who gets paged | Assignment group name, regardless of client | ServiceNow domain first, then assignment group |
| Risk when group names repeat across clients | High. A shared or duplicate group name can misroute | None. Domain is checked before the group even matters |
| Correlation across clients | Possible if timing lines up, even between unrelated clients | Never. Grouping windows only compare alerts inside one domain |
| Coverage gap in one client’s schedule | Can fall through to the shared escalation path, reaching the wrong client | Escalates only within that client’s own chain |
| What the MSP manages | Routing rules that have to account for every client’s naming manually | One AlertOps account organized cleanly by domain |
Book a demo at alertops.com/demo to see domain-aware routing run against your own shared ServiceNow instance.
Conclusion
None of this is a criticism of domain separation itself. ServiceNow does exactly what it should: it keeps the records apart. The gap shows up because most paging vendors built for one company behind one instance. A shared instance serving many clients never entered that picture. Reading the domain first looks like a small addition on paper. In practice it separates two kinds of paging stack. One quietly assumes single-tenant. The other holds the wall an MSP’s clients pay for.
For an MSP on a shared instance, AlertOps inherits ServiceNow’s domain boundary. It enforces that boundary through every step that wakes a person. Incidents flow in by domain through the two-way integration. Routing reads the domain before the assignment group. AlertOps scopes on-call and escalation per client. Correlation groups only within a domain. Each client gets isolation that holds from the record all the way to the phone. The MSP runs it all from one account.
Frequently asked questions
How do I route on-call alerts per client in a domain-separated ServiceNow instance?
Route on the domain first, then the assignment group. AlertOps reads each incident’s ServiceNow domain as it arrives through the two-way integration. It scopes routing, on-call schedules, and escalation to that domain. A client’s incident only ever reaches that client’s responders.
How do I stop one client’s incidents from paging another client’s on-call team?
Use domain-aware routing rather than routing on assignment group alone. On a shared instance, assignment group names can repeat or catch incidents from more than one client, which is how a ticket reaches the wrong responder. AlertOps scopes the routing decision to the ServiceNow domain first, so leakage between domains doesn’t happen.
What is the difference between a ServiceNow instance and a domain?
A ServiceNow instance is the single environment an organization runs on, since ServiceNow is single-tenant and each customer has one instance. Domain separation divides that one instance into domains, where each domain holds the records, assignment groups, and visibility for a distinct business or client. An MSP runs many client domains inside one instance.
Does AlertOps correlation group alerts across different clients on a shared instance?
No. Correlation runs separately for each domain, which means two clients whose alerts happen to land at the exact same minute still end up as two distinct incidents rather than one merged ticket. The comparison never crosses the client boundary in the first place, so there’s nothing to accidentally group.
Can each client domain have its own on-call schedule and escalation policy?
Yes. AlertOps defines rotating schedules, fixed schedules, override shifts, and escalation policies per domain, so every client can run the rotation, coverage, and escalation depth it needs without affecting the others. The MSP manages all of it from one account organized by domain.
