Three Automations, One Field, and a Doubled Counter
On Case, three automations react to Status changing to "Reopened": a before-save record-triggered flow that sets Reopen_Count__c to Reopen_Count__c + 1, a legacy workflow rule with a field update stamping Last_Reopen_Date__c, and a Process Builder that reassigns the owner and fires an email alert. Agents report Reopen_Count__c climbing by two per reopen, a handful of cases failing with "maximum number of flow interviews" errors, and 5,000 cases loaded nightly by a data tool producing 5,000 duplicate emails plus UNABLE_TO_LOCK_ROW. A separate after-save flow on Case makes an HTTP callout to a warranty service and holds the transaction open.
1. Explain precisely why Reopen_Count__c increments twice, naming the order-of-execution step responsible.
Read the worked answer
The workflow rule is the culprit, and the mechanism is re-entry, not a duplicate automation.
- The save begins. Before-save flows run first - the counter goes from 4 to 5.
- Validation and the database save happen. After-save flows and after triggers run.
- Assignment rules, escalation rules, and workflow rules run last, inside the same transaction. The workflow's field update touches Last_Reopen_Date__c.
- A workflow field update forces Salesforce to re-execute before-save flows and before triggers (after triggers and after-save flows do not re-run). The counter goes from 5 to 6.
The flow's entry condition is Status = 'Reopened', which is still true on the second pass, so it fires again. That is the double increment. Had the entry condition included ISCHANGED(Status), the second pass would have been inert - which is why this looks intermittent to whoever wrote the criteria.
The "maximum flow interviews" errors come from a different pattern: the after-save flow updating the Case it triggered on, re-entering itself until the interview cap stops it.
2. Redesign to a target state. Justify each element, including what you do with the callout.
Read the worked answer
One before-save flow, field updates only. Counter and date stamp. Before-save flows run against the record in memory, consume no DML, and cannot re-trigger a save. Entry condition: ISCHANGED(Status) && Status = 'Reopened', plus a guard so the flow never writes a field it also evaluates.
One after-save flow, side effects only. Owner reassignment and the email alert - anything that needs DML on other records.
Delete the Process Builder and the workflow rule rather than migrating them wholesale; reproducing the current criteria is how you keep the bug. Document that the Case object has exactly two record-triggered flows and who owns each.
Get the callout out of the after-save flow. Publish a platform event from the flow and subscribe with an Apex trigger running a Queueable, or use a platform-event-triggered flow on an asynchronous path. Reasons: the callout holds the transaction open for the user, counts against the per-transaction callout cap and cumulative timeout, cannot be rolled back with the save, and a remote timeout fails the agent's save entirely. The platform event decouples it and gives you a retry path.
Add a recursion guard to any after-save flow that writes back to its own record - ISCHANGED plus a processed flag, or restructure it so it stops updating its own trigger fields.
3. The nightly load must not send 5,000 emails. Give two options and pick one.
Read the worked answer
Option A - a bypass the automation respects. Put a custom permission (or a hierarchical custom setting) in the entry condition of the after-save flow, assign it only to the integration user, and the data tool's writes skip the email path while real agents are unaffected. Scoped, reversible, auditable in the setup audit trail, and it needs no code change in the loader.
Option B - deactivate the automation for the window. Deactivate the flow and the workflow rule, load, reactivate. This works but it leaves the org unprotected for the duration of the window, needs a production deployment or setup change, and depends on someone remembering to switch it back. It also cannot be scoped to only the integration user's writes.
Pick A. Then separately attack the lock errors: run the load in Bulk API serial mode, order the batches so records sharing an owner or parent are not processed concurrently, and reduce the transaction footprint so the same record is not touched by multiple batches. The email duplication and the row locks have different fixes, and neither is "make the load smaller."