Not the best title, but hopefully my description will clarify.
I have a workflow with multiple loopbacks in it. It's working (almost) entirely as desired: approvals and tasks are only reset back to 'requested' or 'open' if the workflow calls for it. Work can progress normally on each workflow. The problem is this: I've noticed that when it loops back from certain points, I start to see duplicate activities. If a 'change value' block would have run once, it runs an additional time for each time the workflow has been back over that spot: might be once if it's never looped back from that position, it might run multiple times, depending on how many times the workflow has looped back. This doesn't seem to cause problems with tasks or approvals, but with notifications it means that users are getting hit with duplicate emails.
The loop looks something like this (this is simplified, but the active players are all here):
In this example, the notification block might fire multiple times on approval, depending on whether or not the approver rejected in the past. If it helps, the workflow is running on a custom table. I'm a bit stuck; I've tried google and the community search, and I don't seem to know how to frame the question. I don't think I want to start including rollback activities; there are places where I don't want to invalidate past approvals (that's actually the point of the switch statement in the full workflow.) If I understand what the wiki is saying about 'rollback to' then I'd rather avoid it.
Here's an example of a workflow context activity history on a context that's looped back several times:
As you can see, it's almost like it splits into several workflows executing all at once. This is incomplete, but it gives you an idea.
So my question is twofold:
- What is causing these duplicate activities in my workflow log? Is it normal? If not, how do I stop it?
- If this behavior is entirely normal for 'looping back,' how should I structure my notifications so they don't fire multiple times? Would creating notifications triggered by an event control for this, or is there more that I need to do?
Thanks in advance for any advice or insight you can offer.
EDIT: Welp, I'm 99.9% sure that I figured it out. Brace yourselves, newbie mistake incoming. Here's a snapshot from my actual workflow, instead of my sanitized example. Check out what happens after "Set State". Yep, that branch is bad news. Rejection Review is getting fired twice, and after that, everything else gets fired twice, too. It spawns an evil twin every time it leaves the "Set State" block.
Lesson learned. Now to clean up my workflow and pretend this never happened.
Message was edited by: Beth Barnett
