Managing Users with multiple instances in sys_user table

[tomdickson2]

We have a requirement to record every employee’s Active Directory account in ServiceNow (sourced from Entra ID and/or on-prem AD). This is to support offboarding (ensuring all accounts are disabled/deleted) and to manage access extensions for accounts approaching or past expiry.

For some users, this results in multiple accounts being created in the sys_user table, for example:

• SmithJ (Standard account)
• SmithJ50 (Privileged account)
• SmithJ90 (Domain Admin account)

Each of these is currently created as a separate sys_user record.

This leads to multiple entries for the same person appearing in reference fields and catalogue variables, making it unclear which user record should be selected. While I could update reference qualifiers across catalogue items to filter by account type, we have 100+ items so this isn’t practical to maintain.

Ideally, I’d like to model this as:

• A single “person” / primary profile
• With one or more linked accounts (child records)
• Clean selection in forms (one person, not multiple accounts)

Not all users have multiple accounts, some records may only represent non-standard accounts (e.g. service accounts, vendor accounts). Data is typically sourced automatically via import/integration (not manually maintained)

Has anyone implemented a solution for managing multiple AD accounts per individual in ServiceNow without needing to retrofit all catalogue items?
Examples I’m particularly interested in:

• Leveraging existing tables
• Parent/child structure

Appreciate any guidance or real-world approaches.

We are on Yokohama with ITSM Pro, moving to Zurich in May 2026. We do not have HRSD. 

[fknell]

Hi @tomdickson2,

The identity to user mapping between Microsoft AD and ServiceNow is one-to-one, hence you will create multiple users if one person has multiple accounts / identities for different purposes. 

A best practice is to exclude the service, admin accounts from the import to ServiceNow. Will they ever raise incidents, order items or use other self-services e.g. in HRSD?

Hope this helps!

[tomdickson2]

Hi @fknell,

Yes that the issue I know I will face, and want to avoid, while still somehow being able to capture the secondary accounts. 
The intent is for users to always log requests under their primary account, but be able to select their secondary account as the one to reference for the request, such as extend expiry, or deactivate account. 

[fknell]

Should this not be done in the IAM system? 

[Niamul Arifin]

Thank you for the this architectural question.

This is a pure case of decoupling user accounts and adopting a parent-child relationship. You can create a child table and link it to your parent sys_user record for that user. In this way, you don't have to add unnecessary custom fields in the sys_user table.

If a mortal account has multiple privileged accounts in AD/Entra ID, the mortal account will live in sys_user and other types of AD accounts will live in this child table.

[tomdickson2]

Thank you, this is what I have been considering, good to have someone else recommend this approach.