This works great but I noticed the RITM will close only the last task that is closed is a WF generated task.

If the last task that is closed is a manually created task the RITM stays open.

I tested this in our own instance and in a brand new developer instance. Is there a way around this?

My recommendation is what’s posted above. It really sounds like you’ve got some other issue in your system that might be causing a conflict with what’s been posted here.

I also am having an issue where the workflow generated task is closing the RITM, even if a manual task has been added before the completion of the workflow task. Using Join only appears to work for the taks that have been created in the workflow and has no impact on the manual task which still closes the RITM. I tried using the below wait for condition but now it is keeping the RITM open even if all tasks have been completed. Is there anything you recommend for this scenario?

I don’t know if it actually does work.

I allow users to create ahdoc tasks along with the ones generated in the workflow. I use a workflow activity with this script at the end so it makes sure all tasks, regardless of who created it, are closed. If I close all the workflow-generated tasks first, and then close the manual ones, it never closes out the RITM. If I make a change on the RITM and save it, then it moves forward. But otherwise it is stuck there indefinitely.

Good question. The wiki documentation, while technically correct, is also incomplete. The ‘Wait for’ condition is evaluated whenever the workflow context is re-evaluated. This happens on any update of the ‘current’ record, but it can also be invoked at other times from a script. There is an out-of-box business rule named ‘SNC – Run parent workflows’ that checks each record when it is de-activated and then triggers the evaluation of workflow contexts for any parent record. That’s why this solution works. Catalog tasks and Change tasks are linked to a parent record and they trigger the parent workflow context when they’re de-activated.

Thanks,
Michel

That’s a built-in behavior of the tool so you shouldn’t need to modify anything to make that work. If it’s not working then there’s been a change made to your system that’s broken it. I would compare what you’ve got with a clean demo instance and make sure all of the business rules on the requested item and request tables are the same.

Is there a similar script to use a wait for condition but on the request workflow? For example, for the request to be completed automatically once all requested items are completed?

Thanks in advance,
JP

Not really. The workflow conditions are generally evaluated on updates to the associated records (which you definitely want to happen). If you’re seeing performance issues, then you probably need to look more closely at the number of workflows running and your overall workflow design.