We have several Process Model that have nodes for user tasks. A lot of these nodes need to terminate based on a couple of decisions. The first being a timer (that is configured to skip this node when the timer expires) and the second being a rule such as "and(not(pv!isManageSubmit),pv!isUnlock)". We are seeing a lot of orphaned processes that never complete and most seem to be stuck on a node with this type of a configuration. In one process we were able to put the rule before the node in an XOR and just have the timer for the exception and it works great. Has anyone else experienced this situation? Is this a bad practice?
Thanks in advance for any information someone can share.
Discussion posts and replies are publicly visible
We use this type of setup and I haven't had any issues with it. I would say it is standard practice to have a few exceptions on a User Input Task. Are you able to verify in a 'stuck' process by monitoring, that the variable values are false for pv!isManageSubmit and true for pv!isUnlock, where the exception should be firing but it is not?
If you are able to share screen shots of the variables when monitoring, and the exception configurations, that would be helpful.
Thanks Chris. We will take a look. Unfortunately, I can't share a lot more information because of the client's security requirements.
Redacted screenshots of process instances would work well and should be easy to produce (my favorite freeware screenshot tool, "Greenshot", has this built right in).
If all else fails, you might be able to reproduce the issue in a separate/new process model with no sensitive information contained in it.