Three flows on one field: how to untangle a busy object
When several automations write the same field, the final value depends on an order that nobody chose. Salesforce documents that order, and one list for the object is enough to see where two automations collide.
Open a busy object in a Salesforce org that has been running for a few years. List everything that runs when a record is saved: record-triggered flows, Apex triggers, Workflow Rules and Process Builder processes.
Each one was added for a good reason. The trouble starts when two of them write to the same field, because the final value then depends on which one ran last. If nobody set that order, nobody chose the result.
What Salesforce says about the order
Salesforce documents an order of execution for every save. Read in a simplified way, the Apex Developer Guide lists these steps: before-save record-triggered flows run first, then before triggers. After triggers run next, followed by assignment rules, auto-response rules and Workflow Rules. Process Builder processes and flows launched by Workflow Rules come after that, and Salesforce says they run "not in a guaranteed order". After-save record-triggered flows run after those.
Flows have one more control. Salesforce lets you set a trigger order value on a record-triggered flow. Flows with values from 1 to 1,000 run first, in ascending order. Flows without a value run next, in the order of their activation dates. Flows that share a value run in alphabetical order by API name.
So for a flow with no value, its place in the sequence comes from when it was activated, not from a decision.
One field, four writers
An illustration, not a real client. Picture Approval Status on Opportunity. One flow sets it to Pending when the amount passes a limit. A second flow sets it to Draft when the stage changes. An old Workflow Rule field update sets it to Approved for one region. An Apex trigger writes it again after a quote sync.
Each piece works on its own. Together, one save by a rep can change the status several times, and the last writer decides what the rep sees. Every fix risks breaking one of the other three.
What to write down for each automation
Before you change anything, build one list for the object. For every automation, record:
- Its name and type: flow, Apex trigger, Workflow Rule or Process Builder process.
- When it runs: on create, on update or both, and its entry conditions.
- The fields it reads.
- The fields it writes.
- Its position in the order, or the fact that it has none.
- Who owns it and why it exists.
Sort the list by the fields written. Any field with two or more writers is where the work starts. This table shows five things to list on one object, what can go wrong with each and what to check this week.
| Automation | What can go wrong | Check this week |
|---|---|---|
| Record-triggered flow | With no trigger order value, its place follows its activation date | Open Flow Trigger Explorer and note the flows with no value |
| Apex trigger | Runs outside the flow order and can write the same field again | List each trigger and the fields it writes |
| Workflow Rule | Still runs, but no bug fixes since 31 December 2025 | List active rules that update fields |
| Process Builder process | Order among processes and workflow-launched flows is not guaranteed | List active processes and mark shared fields |
| Shared field | The last writer wins, and nobody chose it | Write down the intended final value and its owner |
Four moves to untangle it
Give each field one writer. If two flows update the same field for related reasons, merge them into one flow with clear decisions.
Move simple updates to before-save flows. Salesforce describes before-save flows as able to update the triggering record's field values, and not the values of related records. They also run ahead of before triggers, so they leave less to collide with. Test each move, because it changes when the update happens.
Set an explicit trigger order on the flows that remain, with gaps such as 10, 20 and 30, so a new flow can slot in later.
Bring in what is left. Salesforce no longer supports Workflow Rules and Process Builder as of 31 December 2025. Active ones continue to run, but Salesforce provides no customer support or bug fixes for them, and it recommends migrating to Flow. Move their logic into flows before you set the order. Our guide to moving from Workflow Rules and Process Builder to Flow sets out seven steps for that.
A check you can run this week
- Pick your busiest object and open Flow Trigger Explorer for it. It lists the record-triggered flows on that object, in the order they run.
- List the Apex triggers, Workflow Rules and Process Builder processes on the same object, because they are not flows.
- Build the list above and mark every field with two or more writers.
- Note which flows have no trigger order value.
- Write down the intended final value for each shared field, and who decides it.
- In a sandbox that matches production, save one test record and compare the result with that intended value. Then repeat with a bulk load.
None of this needs new tools. It needs a list, and a decision for each shared field.
Where we fit
We do not build more automation. We make the org fit to be used. Our Org Review gives you a costed list of what is broken, what it costs to leave it and what it takes to fix, in priority order. The fee is fixed and agreed before we start, from USD 3,500, and you keep the findings whether or not you hire us for the work.
If you would like to talk it through, book a free twenty-minute call.
Sources
Salesforce statements in this guide were checked against these pages on 30 October 2026.
Related guides
Start with the Org Review, not a contract
A fixed fee from USD 3,500, ending in a costed fix list you own outright. Book a free twenty-minute call about your Salesforce automation.