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

[MThomas1]

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 · Accepted solution]

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.

[Tanushree Maiti · Accepted solution]

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.

[Tanushree Maiti · Accepted solution]

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.

[John Gilmore · Accepted solution]

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.

[SandhyaRanG · Accepted solution]

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.

[MThomas1]

Thank you all for your guidance , as always , appreciate the support from community.