Automating inside a platform you already own is usually the cheapest automation available. It is also where a great deal of unmaintainable logic accumulates, because each individual addition seems small.
Automate the process you want, not the process you have. Automation makes a process faster and considerably harder to change. Encoding a workflow that grew by accident — with its unnecessary approval step and its handoff nobody remembers agreeing to — locks in the accident.
What deserves automating
| Characteristic | Automate | Leave manual |
|---|---|---|
| Frequency | Daily or more | Occasional |
| Rules | Clear and stable | Judgement-based |
| Variation | Low | Every case differs |
| Consequence of error | Recoverable | Serious and irreversible |
| Process stability | Settled | Under review |
| Volume | High enough to matter | A few a month |
The frequency test is the one that saves money. An automation that saves five minutes on a monthly task will never repay the effort of building and maintaining it, however satisfying it is to build.
The accumulation problem
Platform automation degrades in a characteristic way, and every step looks reasonable at the time:
- A rule is added to handle a common case. Sensible.
- An exception is added for a customer type.
- Someone else adds a similar rule, unaware of the first.
- The two interact in ways nobody anticipated.
- A third rule is added to fix the interaction.
- Nobody now knows what happens when a record is saved.
Keep a register of automation per object. A single document listing what exists, what triggers it, who asked for it and why prevents most of the above. It takes minutes to maintain and it is the difference between an org someone can reason about and one nobody will touch.
What every automation needs
- A stated purpose — the business reason, not the mechanism.
- An owner who will notice when the process changes.
- Error handling that surfaces failures to a person.
- Bulk safety — behaviour when two hundred records change at once.
- A record of executions, so you can answer whether it ran.
- A documented way to disable it quickly.
The error handling point matters most. Automation that fails silently is worse than no automation — people rely on it, it stops, and nobody knows for weeks.
Where to draw the line inside the platform
| Keep in the platform | Move outside |
|---|---|
| Field updates and validation | Heavy processing hitting limits |
| Record creation on defined triggers | Complex multi-system orchestration |
| Notifications and task assignment | Anything needing real test coverage |
| Approval routing | Business-critical with strict reliability needs |
| Simple scheduled tidying | Long-running or high-volume batch work |
A sequence that avoids the mess
- Document the process as it runs today, including the exceptions people handle informally.
- Remove the steps that exist for no current reason. This alone often delivers most of the benefit.
- Run the simplified process manually until it is stable.
- Automate the highest-frequency step first, on its own.
- Add error surfacing and logging before adding the second step.
- Register it in the automation document.
- Review quarterly — is it still needed, still correct, still firing?
Signs it has gone too far
- Nobody can explain what happens when a record is saved.
- Changes require testing that takes longer than the change.
- Automation exists for processes that ended.
- Users have built manual workarounds around the automation.
- Bulk data operations are avoided because of what they trigger.
The fourth is the most telling. When users work around your automation, the automation is encoding a process they do not actually follow.
Automation accumulated past the point of comfort? Tell us what happens on your key objects. See Apex vs Flow, the Deluge guide, and over-customisation warning signs.