Best practice for managing multi-organisation access without generic accounts
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi everyone,
I’m looking for some advice on a legacy setup we currently have in ServiceNow.
We have an older ServiceNow instance that we use internally to manage Incident, Problem, and Change. In addition, we support several external partner organisations who also log tickets into our instance.
To facilitate this, we built a separate portal for these partner organisations, where they can raise Incidents and Changes using dedicated record producers. Each organisation currently accesses the portal using shared (generic) user accounts (i.e. one account per organisation). These accounts only have basic ESS access and no role-based permissions.
The original intent behind using generic accounts was to allow multiple users within the same organisation to log in and view all tickets associated with their organisation in a shared way.
However, this design is now quite outdated (it was implemented over a decade ago), and we’re starting to see limitations around security, auditability, and user management.
I’d like to understand:
- What are the recommended modern approaches in ServiceNow for handling multi-organisation access like this?
- Is there a better way to allow users from the same external organisation to view and collaborate on their organisation’s tickets without using shared accounts?
- Any best practices around identity management, access control, or portal design in this scenario?
Appreciate any insights or examples from your experience.
- Labels:
-
Architect
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
You’re right to revisit this—shared accounts are a common legacy pattern but create clear gaps in security, auditability, and user management.
A more modern approach would be to leverage ServiceNow Customer Service Management (CSM).
Instead of generic logins, create individual external users (Contacts) and associate them with an Account (organisation). This allows:
- Proper audit trails (who raised/updated what)
- Secure access (no credential sharing)
- Organisation-level visibility (users can still see and collaborate on their company’s tickets)
Using CSM Case management + portal with account-based access control gives you the same shared visibility model—but in a much more scalable and secure way.
Regards,
Pratiksha
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi @attanhes
If you need strict data isolation—for example, ensuring that Company A can never access Company B’s data—or if each customer requires distinct workflows, domain separation is a suitable approach. It provides logical partitioning within a single instance.
Choose domain separation when stronger isolation is essential. In this setup, each partner operates within its own domain.
The advantage is robust data segregation.
KB0715934 Understanding Domain Separation - Basics
Domain Separation ELI5 (Explained Like I'm 5)
