The Salesforce craft did not disappear when agents arrived. It moved. The keynote work is the agent; the real work is the Flows and Apex underneath it, because that is what the agent actually calls. A sloppy Flow used to annoy a user. Now it misleads an agent that runs it a few hundred times a day.
We build and maintain a real Salesforce implementation, so this is less a framework debate and more a set of rules we have learned the hard way.
Flow vs Apex: our actual rule
The tired version of this debate is "clicks vs code." The useful version is: who needs to change this, and what happens when it fails?
Reach for Flow when:
- The logic is straightforward and the business owner or admin should be able to read it.
- It is record-triggered and data volumes are moderate.
- It is a guided screen process for users.
Reach for Apex when:
- The logic branches heavily or has to be reused across many entry points.
- Volumes are high and governor limits are a real risk.
- It makes external callouts that need retries, timeouts, and careful error handling.
- The behaviour is critical enough that you want real unit tests around it.
And the rule that prevents most messes: one automation strategy per object. A record-triggered Flow, a trigger, and a leftover process all firing on the same save is how orgs end up with ordering bugs nobody can reproduce.
The Flow work that actually matters
Most Flow problems we inherit are not about missing features. They are about craft:
- Entry criteria that are too broad, so the Flow runs on every save instead of the one change that matters.
- Queries and updates inside loops, which work in a sandbox and fall over on a data load.
- No fault paths, so a failure surfaces as a cryptic error to a user, or silently to nobody.
- Before-save vs after-save confusion. Field updates on the same record belong in before-save; it is faster and avoids extra DML.
- Giant Flows that do six jobs. Break them into subflows with clear inputs and outputs, which also happens to be exactly the shape an agent action wants.
An agent will call your automation more often and less patiently than any user ever did. Build it like an API, not a shortcut.
Apex architecture that ages well
On the code side, the patterns are not new, but agents raise the stakes:
- One trigger per object, logic in handler classes. Triggers stay thin; behaviour lives somewhere testable.
- Service classes with clear methods that both triggers and invocable actions can call. Do not write the same logic twice for the agent.
- Bulk-safe everything. Assume every method receives a list, because sooner or later it will.
- Tests that assert behaviour, not tests written to hit a coverage number. If an agent depends on a method, its test is your safety net.
- Respect sharing and field-level security explicitly. Code that runs in system mode by default is a quiet way to give an agent more access than intended.
See how we build Salesforce automation→
Agentforce build patterns that hold up
Agent actions are usually backed by an autolaunched Flow, an invocable Apex method, or a prompt template. The patterns that work for us:
- Small, single-purpose actions. "Get order status" and "Create return request" beat one "Handle order" action. The agent reasons better about narrow tools, and you can permission them separately.
- Typed, validated inputs. Never trust that the agent passed the right ID. Check it exists, check the running user can see it, and return a clear error if not.
- Readable outputs. Return what the agent needs to explain the result, not a raw record dump.
- Reversible by default. Anything irreversible gets a human confirmation step, or lives behind a recommendation instead of an action.
- Test with ugly inputs. Misspelled names, two matching records, a closed case. Agents meet these on day one.
Clear descriptions on topics and actions matter more than people expect. The agent picks tools based on those words, so vague instructions produce vague behaviour.
The community around the craft
The ecosystem has noticed where the work went. The most useful conversations in the community right now are not about which feature launched; they are about Flow performance, trigger frameworks, testing agents, and how to keep orgs maintainable as automation multiplies. That is a healthy sign. It means the craft is maturing around the hype instead of being replaced by it.
Our takeaway is simple: agents raised the floor on quality for everything underneath them. Clean Flows and well-structured Apex were always good practice. Now they are the difference between an agent you can trust and one you have to babysit.
Good to know
When should I use Flow instead of Apex?
Use Flow for record-triggered automation and screen processes that admins need to read and change, with moderate data volumes and simple logic. Use Apex when you need complex logic, heavy data volumes, callouts with careful error handling, reusable services, or proper unit tests around critical behaviour.
How do Agentforce agents use Flow and Apex?
Agent actions are typically backed by autolaunched Flows, invocable Apex methods, or prompt templates. The agent decides when to call an action and with what inputs, so those Flows and methods need clear inputs, validation, and predictable outputs.
Is Flow replacing Apex?
No. Flow has absorbed a lot of work that used to need code, but Apex remains the right tool for complex, high-volume, or integration-heavy logic. Most healthy orgs use both, with a clear rule for which goes where.
We engineer ideas into working software.
Tarka · logic · Shila · stone