How to ensure sys_id of users and groups are same in all instances?

[Suggy]

How to ensure sys_id of users and groups are same in all instances?

I have seen SEVERAL posts in community who says "All users and groups should be created in production and migrated to sub-prods."

My question is, as per SDLC , we need to do all the developments in DEV, move to Test, do UAT and then push to PROD.

Why should we do LDAP /azure integration in PROD first and then import to DEV?

Why not start with DEV only and then push suing XML to TEST and PROD???

[Mark Roethof]

Hi there,

Creating users, groups, etc. is a normal thing on production (manually, integration, etcetera). Through regular system clones, this should be in sync.

For some development, it is understandable that users, groups, etc. already need to be created there. In such cases, export/import those records to the higher environments, or include it in update sets (for example using out-of-the-box "Create Application File" or custom "Add to Update Set" / "Force to Update Set".

[Suggy]

Hi Mark, thanks for replying. Yes, that is what we are doing today. ie creating users/groups in DEV (manual/autoamtion) and pushing via XML to Test and PROD (lower to higher instances just like any development we do)

But most of the people said the opposite way - first to create users in PROD and then push them to DEV. Thats the reason I posted this query to see how are others doing 🙂

[Mark Roethof]

Ideally indeed create on PROD (and even better: through integrations) like I mentioned. Though while developing you will encounter numerous situations where that is just not possible for several reasons. So what if you do need this on DEV first, how to get it then to higher environments, see my explanation 🙂

[Rajdeep Ganguly]

The reason for creating users and groups in production and migrating to sub-prods is to maintain the same sys_id for users and groups across all instances. This is important because sys_id is a unique identifier in ServiceNow and is used in many places to reference records. If the sys_id is different in different instances, it can cause issues with data integrity and consistency.

Here are the steps to ensure sys_id of users and groups are same in all instances:

1. Set up LDAP/Azure integration in the production instance first. This will create users and groups in the production instance.

2. Export the users and groups from the production instance to an XML file. This file will contain the sys_id of each user and group.

3. Import the XML file into the sub-prod instances. This will create the users and groups in the sub-prod instances with the same sys_id as in the production instance.

4. Repeat the process whenever new users or groups are added in the production instance.

The reason for not starting with the DEV instance is that the sys_id is generated by ServiceNow when a record is created. If you create a user or group in the DEV instance, it will have a different sys_id than if you create the same user or group in the production instance. By starting with the production instance, you ensure that the sys_id is consistent across all instances.

nowKB.com

For asking ServiceNow-related questions try this :
For a better and more optimistic result, please visit this website. It uses a Chat Generative Pre-Trained Transformer ( GPT ) technology for solving ServiceNow-related issues.
Link - https://nowgpt.ai/

For the ServiceNow Certified System Administrator exams try this :
https://www.udemy.com/course/servicenow-csa-admin-certification-exam-2023/?couponCode=NOW-DEVELOPER