Best practice for company-based incident access control in a shared service desk model

[真治小]

Hi all,

We are designing the access control model for our ServiceNow implementation and would like to ask the community for the recommended approach.

Background:

• Our team provides IT support for all companies in our corporate group (currently several dozen companies, and the number may grow).
• We have a central service desk that receives and processes incidents from end users of all group companies. The service desk handles first-line response and closes incidents on the spot when first-call resolution is possible.
• In addition, each group company has its own specialist support team. These specialist teams only support users of their own company.

Requirements:

• The central service desk must be able to view and work on all incidents across all companies.
• Each company's specialist team must be able to view only the incidents belonging to their own company, and must not be able to view incidents from other group companies.
• The specialist teams must also be able to view incidents that were closed by the central service desk (i.e., first-call resolved tickets), not just incidents routed to them. This is required so the specialist teams can understand the full support history of their users.
• The model must scale to several dozen companies and remain maintainable as companies are added or removed.

Questions:

1. What is the recommended ServiceNow access control architecture for this kind of "shared service desk + per-company specialist teams" model?
2. Which mechanism is best suited here — Domain Separation, Before-query Business Rules / ACLs based on the Company field (company or u_company), Group-based ACLs, or a combination? What are the trade-offs (licensing, complexity, upgrade impact, performance, reporting) of each?
3. How should we model the relationship between users, groups, and companies so that visibility rules can be evaluated consistently — for example, via the sys_user.company field, group-to-company mapping tables, or another pattern?
4. Are there any pitfalls to be aware of for closed / resolved incidents, list views, global search, reports/dashboards, knowledge articles, attachments, related records (tasks, requests, problems), and notifications, so that cross-company data does not leak through any of these surfaces?

Any guidance, references to official documentation, or real-world examples from similar multi-company / managed-service-provider style deployments would be greatly appreciated.

Thanks in advance

[Mark Manders]

Deny unless ACLs for the specific teams (only allow for the central servicedesk and if the company of the group is on the incident).

Security Data policies are your best friend here.

[Tanushree Maiti]

Hi @真治小 

(In English)

To satisfy these requirements in ServiceNow, the recommended solution is to implement Domain Separation, which enables scalable management across multiple companies by ensuring strict data isolation while still allowing centralized oversight and administration.

Refer: KB0715934 Understanding Domain Separation - Basics 

ServiceNow Domain Separation