Try Microsoft Edge
A fast and secure browser that's designed for Windows 10
We are experiencing an issue with a customer using the Payables Transaction Approval workflow with GP2016 R2. They have been using this workflow we helped setup and it has been functioning as designed for 6+ months. Recently, we added an additional step and began noticing that the final step of the workflow was being completely ignored. Our final step is set to "always be required" and would no longer evaluate. When we submit a transaction to the workflow and review the workflow history, we see every other step evaluating, and then it appears to stop on the second to last step, with the final step of the workflow not even appearing in the history. We verified all the other setup of the workflow is correct and the second to last step is set to "go to the next step".
This particular workflow has 1 first step, and then 27 additional nested steps that follow the preceding step. We created it this way so that the final step doesn't happen until all other steps have been accomplished first, which is important from a timing perspective, because they don't want the final step (and associated approval e-mails) being sent until the other steps have been evaluated and/or completed.
In the above scenario consisting of 28 total steps, all of them nested underneath the preceding step (or 27 levels deep I suppose you could say), the workflow works properly. However, once we add an additional step to this workflow somewhere in the middle of all the nested steps, the final step fails to occur. It appears that GP just ignores that last step. We then tried adding 2 additional steps for a total of 30 total steps (29 levels deep) and when we submit a workflow in that scenario, we get an error message that reads:
Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)
This leads me to think there may be either a maximum number of steps, or more likely, a maximum number of levels deep the steps can go, and it is probably hard coded into whatever SP is throwing the error above. Has anyone else experience this issue or have any knowledge pertaining to the issue? Is anyone successfully using a workflow with more than 29 levels or 30 steps?
When I was at the Technical Conference in Fargo this past August or September (can't remember), I sat in a couple of the workflow sessions. If I am not mistaken, they recommended never to go more than 16 levels deep due to performance, but I never really heard if there was a total number of steps that you could not exceed - the stored procedure clearly imposes a hard limit of 32, so I guess that's what it is. If you are experiencing issues at 27 steps, I suppose this is something Microsoft would be interested in, so I suggest you open a support case with them. Typically, these types of support cases would be non-chargeable if they turn out to be a bug in the product.
Thanks Mariano. I'll see what Microsoft support has to say about the number of steps and let everyone know what I find out.
Did you ever find out?
I looked through some WF specs and our case history but can't find anything that specifies a maximum number of steps a workflow can have.
Usually with the 'nesting level exceeded (limit 32)' message mentioned above, we've found that occurs when the 'Enable Recursive Triggers' option is set to TRUE in the properties of a GP database, but it isn't the only cause, but most common in regards to Dynamics GP.
Speaking with my colleagues here, we have seen a couple of cases where a customer had approximately 110 to 130 workflow steps and we began seeing issues with the Workflow History crashing, so I'd say about 100 would be the maximum guideline you'd want to use.
More commonly, with that many workflow steps, you're probably going to run into performance issues with all the scripts that would need to be running in the background trying to figure out which steps require approval or not, based on any conditions you have pre-defined.
Business Applications communities