Six Automations, One Case Record
On Case, six automations compete: an Apex before-trigger that sets OwnerId from a Territory custom setting, a before-save flow that stamps Region, an after-save flow that emails the contact and updates the parent Account, a process builder that creates a follow-up Task, a workflow field update on Priority, and a validation rule that blocks closing a case with no Resolution. After the last release: cases closed with no Resolution still save clean, while the after-save flow's attempt to set Resolution is rejected by the validation rule; the after-save flow's Account update produces two Chatter posts per case; a 4,000-case ownership reassignment times out on CPU; and the Task-creation process silently stops around case 150 of that same bulk job.
1. The after-save flow sets Resolution, yet validation rejects the record. Explain what is happening and what you would change.
Read the worked answer
This is order of execution, not a broken flow. Custom validation rules are evaluated before the record is saved, in the same pass as before-save flows and before triggers; after-save flows and workflow field updates run after the record has already been committed. An after-save flow cannot satisfy a validation rule in the same transaction - by the time it runs, validation has already passed on the committed values, and the update it performs re-saves the record and trips the rule on that second pass.
So: move the Resolution-setting logic into a before-save flow, which runs before custom validation rules and writes to the record without an extra DML operation. That single change removes the second save, the error, and one round of CPU.
Two related traps worth naming: (1) do not make Resolution a field-level required checkbox - system validation runs before before-save flows, so the flow would never get a chance to populate it; the validation rule is the correct mechanism. (2) The reason some cases close cleanly is that the value was already populated by the UI or an API caller; the failures are the paths where nothing set it before save. Audit those paths rather than patching the rule.
2. Why does the after-save flow produce two Chatter posts per case on the Account, and how do you stop it?
Read the worked answer
Updating the parent Account from a Case after-save flow fires Account's own automations, including any record-triggered flow or Apex that posts to Chatter. Two posts per case means the Account is being written twice - a second update path exists, and each write runs the Account flow again.
Find the second path before changing anything: the Case after-save flow is one writer; the process builder, a duplicate after-save flow, or an Apex trigger that also rolls a field up to Account is likely the other. Check the Account's field history and the flow's debug logs to see whether the second update changes anything at all - if the value is identical, the flow is running on a no-op write.
The fixes, in order of preference:
- Guard the entry condition. The Account flow should fire only when the specific field it cares about actually changed; compare against the prior value rather than firing on every update.
- Stop the duplicate write. Consolidate the Case-side automations so exactly one component writes to Account, ideally from a before-save flow if it is only stamping fields on the Case, or from a scheduled path if it does not need to complete synchronously.
- Make the write idempotent. If the Account update cannot be eliminated, have the flow check whether the value it is about to write already matches, and skip the update.
Beware the tempting shortcut of a recursion flag on the Account flow - it hides double work rather than removing it, and it will suppress legitimate updates later.
3. The 4,000-case reassignment times out on CPU and the Task-creation process stops around case 150. What is the systemic problem and how do you fix it?
Read the worked answer
Both symptoms are the same disease: per-record work that does not scale, and it is failing in two different ways - one on the CPU clock, one on a hard cap.
For the CPU timeout, look for work done inside the per-record loop:
- Queries inside the Apex before-trigger per Case (a custom setting is cache-safe and cheap; a SOQL query against a custom object is not). Bulkify into one query with a WHERE Id IN :trigger.newMap.keySet() and build the owner map once.
- DML and parent updates issued per record by the after-save flow. Collect the parent IDs and do a single update, or move the parent work onto a scheduled path so it does not run inside the reassignment transaction.
- The workflow field update and process builder each cause an additional save cycle per record; consolidating them into one before-save flow cuts saves, CPU, and order-of-execution surprises at once.
The process builder stopping around 150 is a limit, not a timeout - an interview or DML governor bound being hit mid-transaction, which typically leaves the whole batch rolled back or partly applied depending on how the job was submitted. Reducing the number of DML operations per record and removing the redundant save cycles raises the effective ceiling.
Then change the operating model: for maintenance work at this scale, run it in chunks of a few hundred with a bypass flag for non-essential automations, and use the Apex flex queue for anything you can defer. A 4,000-record reassignment should be a data operation, not a user action.