how to manage group sys-id in code promotion from sub production - production ?

MThomas1 · 3 weeks ago

Hello,

Our user and group are managed thru ActiveDirectory. Groups created in AD and sync to SN application.

we are doing a project , development in sub production , and promoting to production.

Group sysids are using in code. So, DEV/test group- sysid is different from Prod group-sysid .

what is the best approach to address this? we want to keep AD sync for group/user management.

Thank you.

John Gilmore · 3 weeks ago

It is never recommended to hard code a sys_id for the exact reason that you are running into. You should convert the hard coded sys_id into a system property and reference the system property within the code. You can then setup a fix script to run as part of the deployment that will set the system properties correctly in the target instance.

This is effectively what you mention in your reply about replacing it in each instance except that's really hard to do when it appears in code but very easy to do when you are instead setting the value of a system property.

View solution in original post

Tanushree Maiti · 3 weeks ago

Hi @MThomas1 ,

My recommendation would be not to promote non-prod data to production. Instead, promote the updated configuration/setup to Prod and execute the job there.

For delta data in non-prod, the sys_id values will be different, which is expected and acceptable since those records are intended only for testing purposes.

Also, some clients prefer that production data does not match sub-production environments exactly. Because of this, we generally exclude the user table from the clone exclude list.

Please Accept the solution if it assisted you with your question & Mark this response as Helpful.
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti

View solution in original post

SandhyaRanG · 3 weeks ago

Hi,

This is a common challenge when using AD-synced groups across multiple ServiceNow environments. Since sys_ids are instance-specific, they will always differ between DEV/Test and PROD, which leads to issues when they are referenced directly in code.

The recommended approach is to avoid using sys_ids in scripts. Instead, you can:

Fetch the group dynamically using a stable attribute like group name or another unique field synced from AD (for example, samAccountName).
Alternatively, store the sys_id in a system property per environment and retrieve it dynamically in the code.

From an architectural standpoint, it is also better to treat AD/PROD as the source of truth for users and groups, and propagate that data to lower environments (via clone or controlled data sync). This helps maintain consistency and avoids mismatches during promotions.

In short, the key is to design the solution in a way that does not rely on sys_id being the same across environments, since that cannot be guaranteed.

Hope this helps.

View solution in original post

Tanushree Maiti · 3 weeks ago

Hi @MThomas1 ,

Generally, foundation data records (like group,user,location, BU etc) - BAU creates in the Production environment first as per business request.

The same data is then synchronized across all sub-production environments.

Moving foundation data from sub-production to Production is not recommended in a live instance, as it may lead to data inconsistencies or overwrite existing production configurations.

Also many integrations and backend workflows are mapped to specific sys_ids. Altering them can instantly break CMDB reconciliations, user provisioning, or catalog approvals.

Please Accept the solution if it assisted you with your question & Mark this response as Helpful.
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti

MThomas1 · 3 weeks ago

Acutally , we did created groups ( for a specific project) in AD- production first. Then did export/import the groups to subproduction and used in code.

so when we promote code to production same sysid will exist in all instaces..

our problem is AD sync to prod and DEV ( same data) , so DEV has new groups with DEV sys id .

now, future AD-DEV user sync will not work as expected.

So, how about after code promotion we replace the sysid accoding to each instace? SO, we can keep the groups as AD created them?

Just thinking of possible options to address situation.

Thank you and appreciate your guidance as always.

Tanushree Maiti · 3 weeks ago

Hi @MThomas1

Just let me know one thing - do you not have non-prod endpoint for this integration.

Please Accept the solution if it assisted you with your question & Mark this response as Helpful.
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti

MThomas1 · 3 weeks ago

Sorry, i am not sure if I understood your question correctly.

AD integration -> endpoint to Prd and DEV - YES