Under advanced server options the option to stop loops after X iterations. What does this do?
Is there any way to stop workflows from initiating if X amount of the same workflow starts within a specified time frame.
It's a safety measure for runaway loops in workflow, automatically terminating them if they exceed the arbitrary limit of iterations.
The most common loop is actually not within a single workflow though. It is a starting condition that an entry changed without a check to verify the user is not workflow. These loops run infinitely.
The option applies to Repeat activities.
Here is an example. We had a workflow that started on change, and renamed the document (therefor changing it). So it ran 3 million rename workflows before it was caught. Is there anyway I can put something in place to globally catch this, the stop loops does not handle this scenario. It was set to 10,000 and never got involved.
Like I said, the option only applies to iterations of an individual Repeat activity within the same instance.
Ok got it. So there is no way to prevent these situations from happening. I was looking for something we could put in place, especially with customers who are developing their own workflow and are on the learning curve. The cleanup of logging history and audit trail is a big task and sometimes impossible since we don't understand the structure of these logs.
The usual "user does not equal <connection profile user>" condition in the starting rule usually does it.
You can exclude the workflow user at the server level, but that will ignore all its activity, including for things like satisfying wait conditions.
We teach everyone this before letting them loose, but can't prevent it entirely. We might have to start excluding workflow from everything and they just can't make any advanced workflows that communicate with each other. It just makes too much of a mess of the databases.