I recently had a question where the developer had built a process which included a loop. Within that loop, there was a custom function which determined which level of approver was required before applying processing logic, something similar to this:
The problem was that when the “Do Something” step was being executed, it appeared that the “Find Approval Level” step was always jumping two levels – the first and third approvers were being found, but never the second or fourth. So, there must have been something wrong in the “Find Approval Level” step if it was always jumping two levels, right?
Wrong! The problem was that the loop activities in the process hadn’t been defined properly, and the code hadn’t been written correctly in a very basic manner.
The Workflow activities should have had the “On Revisit” flag set correctly for the activities that were in the loop. The standard is to have it set to “Reset” which will re-run the activities in CANCEL mode before re-running the loop in RUN mode. Instead, the activities should have had the flag set to “Loop”:
If the flag is set to “Ignore”, then the activity would only be executed once – which means that you would end up in a perpetual loop in this example, since the “More Required?” step would always return “Yes” unless there was only one approval level.
The basic change to the code is to check what the FUNCMODE is before doing any further processing. If the code was written so that the search for the approver only happened during RUN mode, then the process wouldn’t appear to skip a level. Unless there is specific code to undo an execution, then I always include a check at the start of my activities which says that if FUNCMODE does not equal WF_ENGINE.ENG_RUN (the externalized constant for RUN mode), then simply RETURN to the Workflow Engine. This saves processing time and avoids problems like the one we see here.