Group sys ids are different between instances, causing problems with approval group in workflow.

[Reddy]

I'm having issues with ServiceNow Groups sys id's, Where Dev, Test, Prod groups sys ids are different. When I Pushed my workflow updates to test they have different sys ids. What is the best process to maintain them Unique Sys ids?

[Prateek kumar · Accepted solution]

You have to push XML's of the groups through instances to maintain same sys_id's.

It is not advised to create groups manually across all instances.

[DaveHertel]

Hi rama12345,

  The best practice is to have a consistent, repeatable refresh cycle where all environment are kept in sync.  How?  A copy of production environment DB is made on a routine basis, and laid down on top of DEV, TEST, etc.   Ideally, if there is a routine change/update set pushed to PROD (for example every 2 weeks), then after that PROD update is deployed sometime soon after a DB backup of PROD is made and restored (a DB-restore) to each of the sub-environments (DEV, etc.) .  This way sub environments are literally copies of PROD.   Yes, there may be tweaks you have to make to get all this worked out.  But the benefits are huge and well worth it.   

this methodology ensure code developed in DEV to be assured to 'look like' PROD.  So when updates are made in DEV, then pushed through the lifecycle (DEV -> TEST -> PROD), etc. you know that changes made to DEV will work in TEST and will also work in PROD.

The key is a healthy, repeatable, consistent refresh cycle to maintain all environments to look more/less the same.  Such as SYSIDs.... which is the root cause of the troubles in your original question.   Regular, disciplined refreshes of all environments from PROD will go a long, long, LONGGGGG way to making the deployment release cycle consistent and trustable! 🙂

Hope this helps...

[Reddy]

Thanks, Dave.

[Reddy]

Thanks for your reply Prateek.

Do you want me to delete the existing groups, and Push XML's from dev to other instances?