Activity count exceeds max on workflow

pennieturner
Mega Guru

We have a workflow running which has a timer event on to wait for all the catalog tasks to be closed before it continues to the next stage.

The problem we have is that the workflow activity count exceeds 100 when its waiting for a while of the tasks to be closed, and the workflows are automatically cancelled, leaving the RITM in limbo.

I've tried to find out where the max count of 100 is found to see if I can change it, but, I don't seem to be able to find it anywhere.

Can anyone help? or if anyone has any ideas of how to get around this please let me know.   We don't want to raise the timer anymore than it is (every 2 hours).

Hoping someone can help!

Regards

1 ACCEPTED SOLUTION

If you want to change for existing workflow, Go to workflow editor > Checkout your workflow > Go to Properties > There you can change the count.


View solution in original post

19 REPLIES 19

You need to create a BR.



  1. Next, create a business rule that forces the workflow to rerun executing activities when a task that is not governed by workflow is closed. Without this business rule the workflow will stay at the 'Wait for condition' activity until the request item is updated.


Check section 4.4 of this link - Condition Activities - ServiceNow Wiki


Hi Pennie,



In the past I've had to make a change to something on the sc_req_item table to force the workflow to check the condition again.   This was on B and C releases



Simon


The last comment by Stephen Hey on Wait for condition change requests suggests that the waitFor condition is only checked when the workflow update event is fired.   I'm not 100% sure which event this yet but you can test by adding a space to the request items description which should cause the event to fire.


Ohhh, I've found this:


Condition Activities - ServiceNow Wiki



Looks like I needed a business rule in there aswell to force the workflow wait for condition to try again.   It seems to have worked!



Thank you all for your help


This is exactly how I have used it in the past. I used this in change workflows to ensure all related tasks were closed before the change request could move to the next state. I have not used this for catalog tasks, but I cannot see how it would work any differently.