New imported Groups have mismatched sys_id between Prod and Dev, causing issues when trasnferring workflows.

[galavodasal]

Hi all,

Newly created Groups (imported from AD) do not have matching sys id's between Prod and Dev, causing an issue with workflows when transferred.

I believe we cloned Prod to Dev sometime after implementation, which made the Groups have synced sys id's.

What's the best way to "fix" this without cloning Prod to Dev?

[Chuck Tomasi]

The best way is to do one import to prod and then export XML/import XML to preserve the sys_ids in other environments.

Also, your issue indicates that you are using hard coded sys_ids somewhere in your workflows (and potentially other scripts.) Consider using properties or other ways to avoid hard coding values in to your workflows and scripts.

https://developer.servicenow.com/app.do#!/document/content/app_store_doc_technical_best_practices_ge...

[Chuck Tomasi]

Also helpful

https://developer.servicenow.com/app.do#!/document/content/app_store_doc_technical_best_practices_ge...

https://developer.servicenow.com/app.do#!/document/content/app_store_doc_technical_best_practices_ge...

[galavodasal]

Hey Chuck, thanks as always for the quick reply.

I just want to make sure I understand you correctly. Are you suggesting to export the Groups from Prod, DELETE the Groups in Dev, and then import the exported Groups from Prod?

And of course, after that, go through all of the workflows and update the Assignment Groups in the various activities?

Chuck Tomasi wrote:

Also, your issue indicates that you are using hard coded sys_ids somewhere in your workflows (and potentially other scripts.) Consider using properties or other ways to avoid hard coding values in to your workflows and scripts.

https://developer.servicenow.com/app.do#!/document/content/app_store_doc_technical_best_practices_ge... 

We're not hardcoding Group sys_id's anywhere in the workflows. The problem occurs on a simple CTASK activity or Group Approval. You select the Group from the reference field for Assignment Group, save the workflow, transfer to Prod, then open the workflow in Prod and you'll see that the CTASK or Group Approval now shows the sys_id of the Group from Dev, since it couldn't find a sys_id that matched in Prod.

[Chuck Tomasi · Accepted solution]

Either dev or prod needs to be considered the "source of truth" for your group records. I prefer to make it prod since all the related records have sys_ids that point to the current groups and users, and you don't want to get in to updating all the references throughout the system.

1. Export the groups (and if necessary, users and group members tables too). sys_user_group, sys_user, and sys_user_grmember respectively.
2. Delete the records in dev and import the tables from your XML files (from prod)
3. Update the workflows and anything else in dev that references the "old" groups.
4. Promote those changes to prod.