Proper way to wait for Change Closed or Cancel condition

ILYA STEIN
Tera Guru

I am creating standard change requests dynamically in a Flow Designer flow in response to a user submitting a RITM. The flow is configured to wait until the change's state is closed or cancelled, and update / close the RITM accordingly. However, I get a confusing error in the Wait for Condition step.
Here is the Wait for Condition part of the flow, along with the error details:

ILYASTEIN_0-1768505068402.png

Will appreciate any advice on how to avoid / handle this error.

1 ACCEPTED SOLUTION

Thank you for sharing the screenshot — that helps clarify what’s happening.

From what’s shown, the reason this isnt working is that the value being stored is the Change Number CHG…, not the sys_id. The Wait for Condition and Look Up Record steps expect a real record reference, and if you pass the display value instead of the sys_id, the record’s attributes wont be available to the flow.

What I’d suggest is:

  • Update the variable to store Change Request → Sys ID from the create step (not the CHG number)

  • Use that sys_id in the Look Up Record step (table: change_request, condition: sys_id = <stored sys_id>)

  • Use the output of that lookup as the record for the Wait for Condition

If for some reason you can only capture the CHG number, then adjust the lookup to query by number instead of sys_id.

Also, i see it’s worth ensuring the lookup and wait steps are running as System, so ACLs don’t prevent the flow from reading the change record.

With those adjustments, the attributes should resolve correctly and the Wait for Condition should behave as expected. Hope this resolves!

@ILYA STEIN - Please mark as Accepted Solution and Thumbs Up if you find Helpful :

View solution in original post

9 REPLIES 9

Matthew_13
Mega Sage

Yeah indeed, I’ve run into this with Flow Designer before. The “Wait for Condition” step is picky about what it can “hold onto” while the flow is paused.

What’s happening is: you’re probably feeding the Wait step a record object/data pill coming back from the “Create Change” action. When the flow pauses, it has to store that value so it can resume later, and sometimes that record object doesn’t serialize cleanly—so you get that confusing [object] / action_status error.

What usually fixes it is a small change in approach:

  1. Right after you create the Change, store only the sys_id in a string variable

  2. Do a Look Up Record on change_request using that sys_id

  3. Use the Look Up Record output as the “Record” for the Wait for Condition step (wait until state is Closed/Canceled)

Same logic, but instead of trying to “pause” with a complex object, the flow pauses with just an ID and re-loads the record cleanly.

Also worth double-checking:

  • Make sure the flow is running with enough access (often easiest to run the flow/actions as System) so the Wait can re-check the record later.

  • Add a timeout path so the RITM doesn’t sit forever if the change never closes.

That pattern is usually enough to make the error go away.

 

@ILYA STEIN - Please mark as Accepted Solution and Thumbs Up if you find Helpful :

This sounds like a great idea, but unfortunately it didn't work:

ILYASTEIN_0-1768586095769.png

It's as if this change request is created, but its attributes are not available in the flow. What can possibly be the reason? And most importantly, is there anything I can do to fix it?

Thank you for sharing the screenshot — that helps clarify what’s happening.

From what’s shown, the reason this isnt working is that the value being stored is the Change Number CHG…, not the sys_id. The Wait for Condition and Look Up Record steps expect a real record reference, and if you pass the display value instead of the sys_id, the record’s attributes wont be available to the flow.

What I’d suggest is:

  • Update the variable to store Change Request → Sys ID from the create step (not the CHG number)

  • Use that sys_id in the Look Up Record step (table: change_request, condition: sys_id = <stored sys_id>)

  • Use the output of that lookup as the record for the Wait for Condition

If for some reason you can only capture the CHG number, then adjust the lookup to query by number instead of sys_id.

Also, i see it’s worth ensuring the lookup and wait steps are running as System, so ACLs don’t prevent the flow from reading the change record.

With those adjustments, the attributes should resolve correctly and the Wait for Condition should behave as expected. Hope this resolves!

@ILYA STEIN - Please mark as Accepted Solution and Thumbs Up if you find Helpful :

I don't think that's where the problem is. I made changes to only capture the sys_id of the change. The change is created successfully, but when I try to store its sys_id in the flow variable, it comes out empty, as can be seen in the screenshot below:

 

ILYASTEIN_1-1768591854299.png

Still at a loss...