Workflow getting stuck at "Wait for condition"

[Dom Davidson]

Hello ServiceNow Gurus,

I am facing a challenge pertaining to workflows more specifically the "Wait for Condition" utility.

In this case, the workflow needs to wait until the underlying PtO(Permit to Operate) record has been approved.   I have created a "Ptb Approval Flag(u_pto_approved)" True or False field on the underlying table, that checks if the associated PtB record is approved or not.   If the associated PtB record is approved a BR is triggered to update the Approval Flag field to True.

My intention of using "Wait for Condition" is to wait until once the flag has been checked, and then proceed forward with the workflow. As it stands, the once the PtB record is approved, the Approval flag updates to True but the workflow stops there and doesn't proceed forward.   However, I did notice if I update any other random fields on the form, and hit save, the workflow then only proceeds forward.

Is there a way I can automate this? Such that once the PtB Approval Flag is checked by the BR, the workflow proceeds forward without any hinderance? Would I need to add in additional script to my BR such that once Approval Flag is true -> trigger back the workflow? If so, how would that additional piece of script look like?

Much thanks for your insight on this matter.

-Dominic

[ohhgr]

Hi Dominic,

When the Pto Approved field is updated, did you find the gs.log() statement being logged?   And could you add a statement outside of the if/else structure to see if the wait for condition check is being done or not. Ideally, it should be checked twice, once when the workflow control moves to this activity with u_pto_approved set to false and one more time when the u_pto_approved is set to true through a business rule.

Also, rfedoruk, do we really need the "SNC - Run Parent Workflows" BR in this case? As, the u_pto_approved field is on the same table on which this workflow runs. I believe, that BR is used to nudge parent record's workflows.

-Mandar

[Uncle Rob]

*should*, yes.   I remember at least one version where I had to build my own because the Task version wasn't taking care of business.

[ohhgr]

hmmm, that is strange..

[Dom Davidson]

Hi Mandar/Robert,

I want to clarify a few things

- The Workflow is defined on the Release(rm_table) table, which has a custom reference field pointing to the PtB(Permit to Build) table.

- The user can associate any PtB record to this custom field.

- A BR runs on the backend checking the PtB table with the associated PtB record and updates the "PtB Approval Flag" if the underlying PtB record has been approved.

newuser: As per your suggestion I added a log statement before the if/else condition.

-When a unapproved PtB record is associated with the Release, the "PtB Approval Flag" remains unchecked. Both the Precheck and PtO Not approved logs appear three times.

-However once the associated PtB record is approved, the "PtB Approval Flag(PtO Approved)" is checked to True. There are no additional logs statements are created.

-However, if I update and save any another random field on the Release record(eg- Priority), the workflow progress forward logging the approved PtB statement.

-Dominic

[Uncle Rob]

Which table is the workflow running on?

Does the u_ptb_approved field exist on the Release or the PtB?

Its sounding like the update is happening on a table that's a child of the one the workflow is running on.