Most teams do not need more Salesforce. They need the Salesforce they already pay for to stop making them retype things. A sales rep who updates the same three fields after every call, a coordinator who copies a record into a spreadsheet so somebody else can see it, a manager who chases status by email — all of that is automation work, and most of it is a few hours, not a project.
What I build
- Record-triggered flows — fire when a record is created or changed: assign an owner, create the follow-up task, update a related record, send the notification, start an approval.
- Scheduled flows — run on a schedule across a batch of records: nightly hygiene, renewal reminders, stage ageing, escalations on anything untouched for N days.
- Screen flows — guided steps for the people doing the work, so a multi-step process becomes one screen instead of six tabs and a checklist in someone's head.
- Approval processes — routing that reflects how decisions actually get made, including the exceptions nobody documented.
- Apex automation — triggers, batch jobs and queueable work for the cases Flow cannot reach.
Migrating from Workflow Rules and Process Builder
Salesforce has retired Workflow Rules and Process Builder for new automation and is pushing everything toward Flow. If your org still runs on them, you are maintaining tools that are no longer being developed, and you are probably running several of them against the same object without knowing which fires first.
A migration is not a mechanical copy. It is the moment to find out what each rule was for, whether anyone still needs it, and which ones quietly conflict. I usually find a meaningful share of legacy automation can simply be deleted — it was built for a process that changed years ago. What remains gets rebuilt in Flow, consolidated per object so the order of operations is visible, and documented so the next person does not have to guess.
When Flow is the wrong tool
Flow is excellent until it isn't. Bulk operations across tens of thousands of records, complex recursion, callouts with retry logic, anything that needs real error handling — these belong in Apex. A consultant who only knows declarative tools will build you a fragile flow and call it done. Because I write Apex and Lightning Web Components as well, I can tell you honestly which side of that line your problem sits on, and build either one.
The reverse matters too: plenty of things get written in Apex that should have been three clicks in Flow, which leaves you paying a developer forever for a change an admin could make.
When automation keeps breaking
If flows fail silently, fire twice, or stopped working after someone added a validation rule, the problem is usually not the flow you are looking at. It is the interaction between several pieces of automation on the same object, or a change elsewhere that nobody connected to this. Troubleshooting that is a specific skill: reading debug logs, checking the order of execution, reproducing the failure in a sandbox before touching production. That is a normal part of this work, not an extra.
If the underlying org is genuinely messy — duplicate fields, abandoned objects, three automations doing the same thing — the honest answer is often an org cleanup first. Automating on top of a broken data model just makes the breakage faster.
How this works
We start with a free 20-minute call where you describe the process, not the Salesforce feature. I come back with what I would build, how long it takes and what it costs, before you commit to anything. Work happens in a sandbox, you see it before it ships, and I stay available after go-live — the first two weeks after a flow goes live is when you find out what you forgot.
Common questions
Can you migrate our Process Builder automation to Flow?
Yes, and it is one of the most common requests. I audit what exists, confirm what is still needed, rebuild the rest in Flow consolidated per object, and test it in a sandbox before anything touches production.
Our flows fail and nobody knows why. Can you fix that without rebuilding everything?
Usually, yes. Most failures come from automation conflicting on the same object or a change made elsewhere. I reproduce the failure in a sandbox, trace it through the order of execution and fix the cause rather than adding another workaround.
Do we need a developer, or would an admin be enough?
For a lot of automation an admin is genuinely enough, and I will say so. You need a developer when the work involves bulk processing, callouts, real error handling or custom components — and when you want the declarative and coded parts to be designed together rather than fighting each other.