Hi Grant, I took a look at your process and have an idea to try. Let's simplify your three branches to branch A, B and C for the corresponding products. After initial submission, use the parallel gateway to activate all 3 branches. (In my diagram below, I have each branch simplified to 1 user task, but shouldn't make a difference, just consider that your bunch of tasks.)
In your case above, Product A and Product B are waiting at the merge gateway for Product C to finish. Your question was, what if the submitter needs to update just Product A?
My solution would include an additional field on the Initiator: My Submission task. I would have a drop down that defaults to empty with options "Product A", "Product B" and "Product C" so the submitter can update fields and then choose which product he/she is updating. If the submitter wants to update Product A, they would set the drop down to Product A and submit their changes. Meanwhile, the process still has two branches waiting at the merge gateway and Product C still waiting for that final approval. Once Product C is approved, all 3 branches will reach the INCLUSIVE gateway (this is key later). Since all active branches have completed, the 3 branches turn back into 1 branch and head to the new exclusive gateway. This gateway checks the new drop down variable. If the submitter doesn't need to make any changes, that field would be blank and the instance would move on to Approver #3 (not shown below) then the end event. If the Update task was submitted and the drop down was set to Product A, the exclusive gateway would feed back into Product A: Approver #1. This would allow the Product A team to re-evaluate the new field values and approve. Once they approve, since we changed the merge gateway to be inclusive, it will let this single branch through. Inclusive gateways only wait for active branches and since we only re-activated Product A the second time through, the inclusive gateway just waits for that.
Note:
You may want to add a signal catch event on the Update My Submission task. If Approver #3 approves, you'll still have an open user task for the initial submitter where they could modify things (or if it's read only, it will just keep the instance running). You could add a signal throw event before the end event that triggers the interruption of "Update My Submission" so the instance actually completes.
Some additional enhancements:
1. Instead of a drop down that would only let the submitter modify one product, you could try using a checkbox so they could modify any/all of the three products. If you go this route, instead of an exclusive gateway, you'd need to use an inclusive gateway and re-activate any branch that the submitter selected. Again, the inclusive gateway to merge would wait for all active branches so whether you re-activate 1, 2 or 3 branches, only 1 thread will ever reach Approver #3.
2. Along with re-activating one of the branches, you could have a flow going from the exclusive gateway back to the "Update" task. This would allow the submitter to update a second time after they submit their first update form.