ServiceNow Dev/Test/Prod: Should SysIDs match across instances for reference fields used in Flow Des

[JustinB93792690]

We're relatively new to ServiceNow and are trying to establish good development and deployment practices.

We currently have integrations that create and maintain records such as Services, Service Offerings, CIs, Teams, and other objects across our Dev, Test, and Prod instances. These records are created independently in each environment, so their SysIDs don't match.

This is causing problems when I build flows in Workflow Studio (Flow Designer). When I select a record from a dropdown or reference field in Dev, the flow works as expected. However, when I commit the flow to Test using an update set, the reference is "(empty)" because the corresponding record in Test has a different SysID.

For example, I have a catalog item that should assign a request to the Help Desk team. The flow works in Dev, but after importing the update set into Test, the assignment group value is "(empty)" because the SysID from Dev doesn't match the Help Desk record in Test.

I've raised this concern internally because we're expanding our integrations, and I expect this could become a larger issue as we develop more flows and move them between environments. So far, I've been unsuccessful.

My questions are:

1.  Am I configuring my flows incorrectly, or is this an expected limitation when deploying flows that contain references to records with different SysIDs?

2.  Is it standard practice to keep SysIDs consistent across Dev, Test, and Prod for records that configuration depends on, or is there a different recommended approach?

3.  If the records are intentionally created independently by integrations in each environment, how should flows reference those records so that they continue to work after being moved between instances?

I'd appreciate any guidance on this.

[vaishali231]

Hey @JustinB93792690 

This is expected behavior when SysIDs differ across instances. Update sets do not automatically map independently created records between Dev, Test, and Prod.

Instead of hardcoding SysIDs in flows, use the Look Up Record action with a stable, unique identifier, such as an integration key, to retrieve the correct record in each environment.

For integration-managed records, using a common external ID or a mapping table is generally a more reliable approach.

*********************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb

[JustinB93792690]

Thank you for your advice.

Something I want to clarify, I am not hardcoding the SysIDs.   In the example I am using the workflow builder in ServiceNow, using the native "Update Record" action, selecting the target RITM, adding the "Assignment group", and selecting one of the groups from the dropdown.  So everything is OOB ServiceNow no hardcoding.  

I assume the problem between the environments is that behind the scenes Workflow studio uses the SysID. 

[vaishali231]

Yes, that’s likely what’s happening. Even when you select a group from the dropdown in the OOB Update Record action, the flow stores the reference to that record, typically using its SysID.

If the corresponding group has a different SysID in Test, the reference may not resolve after deployment.

One option is to use a Look Up Record action to retrieve the group dynamically in each environment, then pass the returned record to the Update Record action.

*********************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb