Where Should an Agent’s Work Run: Flow, Apex, or Somewhere Else?

Choosing tools by the work, its owner, and how it recovers from failure.

A team wants an agent to handle a claim. The request includes reading documents, calculating eligibility, waiting for approval, and calling a payment service. Flow, Apex, and a model can each help, but they suit different parts of the work.

The model may extract candidate facts from a document and explain why information is missing. Eligibility needs the applicable policy and verified facts. An approval may remain pending after the conversation ends, while the payment system owns the eventual transfer. One convenient feature does not automatically take responsibility for all these steps.

Start by asking who owns the rule, record, and result. Flow can make record-oriented automation visible. Apex provides code-level control inside Salesforce. Prompts and model calls help with language. Orchestration can represent waiting and resumption. Integration services connect systems, and an external owner may already provide the business operation the claim needs.

Before Agents: Tool Choice Followed Process Shape

Salesforce teams already made these decisions before AI.

Flow handled many declarative validations, updates, routing decisions, and notifications. Apex handled logic that needed custom code, complex data access, or integrations. Approvals represented explicit human authority. Platform events and APIs crossed asynchronous or system boundaries. External platforms owned capabilities that Salesforce should not duplicate.

The choice was not only about developer preference. It reflected determinism, transaction scope, limit behavior, testability, and ownership.

AI adds a new caller and a new coordination layer. It does not erase the reasons the process was split.

Give the agent clear operations to call

An agent should invoke a capability whose contract is stable even if the interface changes. The capability may be implemented by Flow or Apex, but the agent should not need to know every internal step.

Use a responsibility matrix:

Responsibility	Natural home	Why
Validate fields and update related records in a bounded transaction	Flow	declarative, inspectable, platform-native execution
Complex deterministic logic or specialized integration code	Apex	code-level control, typed behavior, custom error handling
Generate an explanation or draft	prompt/model call	probabilistic language work without authority over the final state
Wait for a person or callback across time	Flow Orchestration or a durable process owner	state, pause/resume, and human work are explicit
Translate protocols, mediate multiple systems, or manage enterprise APIs	MuleSoft or another integration boundary	cross-system ownership, transformation, and policy
Own a domain capability outside CRM	external system	the external owner defines truth and lifecycle
Interpret an open-ended request and coordinate governed capabilities	Agentforce	intent, routing, conversation, and bounded coordination
Coordinate document-heavy back-office work with human and external participants	Agentforce Operations or the process owner	workflow ownership beyond a single record transaction

The table is a starting point, not a license map. A team should verify current availability and fit for the target org.

A Claims Example

Imagine a claim that requires:

checking the policy and claimant;
extracting information from submitted documents;
calculating eligibility and a provisional amount;
requesting approval above a threshold;
calling an external policy or payment system; and
recording the outcome and notifying the claimant.

An agent can ask clarifying questions, summarize the documents, and explain why more information is needed. It can select the “check claim” capability or route the request to a specialist subagent.

Give the eligibility calculation to the system responsible for the policy. The agent can explain its result, but changing the explanation should not change eligibility.

If the amount requires approval, save the exact proposal the reviewer sees. Once approved, the payment request needs the appropriate credential and a stable identifier for retries. If the call times out, check the provider before resubmitting. Only then can the notification explain whether the claim is paid, rejected, or still awaiting a result.

Trying to make one prompt, one Flow, or one Apex class own every step confuses coordination with ownership.

Choose the implementation by the responsibility it can own through failure and change, rather than by which feature can produce the first demo.

Flow: Explicit Platform Automation

Flow is a good home when the responsibility is declarative, record-oriented, and bounded by a Salesforce transaction or a well-defined orchestration step.

Its value in an agent architecture is not simply that it is low-code. It gives the business a visible place for conditions, assignments, updates, and invocation. It can make a capability easier to inspect and change alongside the data model.

Flow still has limits. A complex integration, a high-volume transformation, or a long-running cross-system process may be a poor fit. An agent calling Flow does not turn a Flow into an automatically durable or idempotent workflow. The Flow must define its failure and retry behavior.

Apex: Pro-Code Control Inside Salesforce

Apex belongs where the logic needs code-level control, complex calculations, custom data access, or an integration action that declarative surfaces cannot express clearly.

The tradeoff is not merely that fewer admins can edit it. Apex is still part of the Salesforce transaction and is still bounded by platform limits, security context, deployment dependencies, and test requirements. An agent action that calls Apex inherits those constraints.

Apex should expose a narrow capability rather than a general “do anything” method. Its inputs should be typed, its outputs should report intermediate and error states, and its authorization should not depend on the agent’s natural-language instructions.

Use model calls for interpreting and explaining language

Prompt templates and model calls are well suited to transforming language: summarize a case, classify a document, draft an explanation, extract candidate fields, or propose a response.

They are poor owners of authoritative business policy unless the policy is rechecked by a deterministic capability. A model can propose that a claim appears eligible. The system of record should calculate eligibility from the applicable policy and current facts.

The distinction is easiest to enforce when the prompt output is treated as a typed proposal with provenance and confidence rather than as a committed business fact.

Give waiting work a persistent home

A claim can pause while a manager reviews it or an external system processes it. That work needs somewhere to live after the original request and conversation end.

An orchestration or workflow owner can save stages, assignments, and the conditions for resuming. For this claim, it should retain the submitted evidence, the pending approval, and the external request reference. A new user or worker should be able to find them without reconstructing the conversation.

The agent can explain that the claim is waiting for approval or help the claimant provide a document. The process owner decides whether the required input arrived and which step may run next. This separation makes the work recoverable when a channel closes or a worker fails.

Decide who owns the external call and its recovery

External Services and credential configuration can make a Salesforce callout easier to invoke. They do not remove the need to decide who owns schema, retries, transformations, rate limits, and cross-system coordination.

MuleSoft becomes relevant when the problem is broader than one callout: protocol translation, fan-out, API management, reusable mediation, legacy connectivity, or an integration product boundary that should not be embedded in a record transaction.

An external system should own the capability when it owns the business truth. Salesforce may create a request or hold a reference; it should not pretend to be the payment, policy, fulfillment, or identity authority if it is not.

Questions to answer before choosing the implementation

Before selecting the implementation surface, answer:

Lens	Question
Determinism	Must the same inputs produce the same business result?
Transaction	Which changes must commit together?
Time	Must the work survive a session, timeout, or overnight pause?
Authority	Which system owns the policy or state being changed?
Scale	What happens at batch, event, API, or concurrency volume?
Recovery	Can the operation be retried, resumed, compensated, or reconciled?
Evidence	Can the team prove what was proposed, executed, and verified?
Lifecycle	Can the owning team version, test, deploy, and change it safely?
Portability	Is the dependency intentional, and what contract survives a move?

The answer often leads to a composition rather than a single tool.

Where this can go wrong

The prompt becomes the policy engine

The model receives a paragraph of eligibility rules and is trusted to apply them consistently. Keep policy executable and testable outside the prompt.

Flow becomes a distributed system by accident

A Flow calls several remote systems, waits on an ambiguous response, and retries without a business key. Move durable coordination to an explicit process or integration owner.

Apex becomes the universal adapter

A single class accumulates routing, document handling, external mediation, notifications, and audit behavior. Split responsibilities around ownership and lifecycle.

The agent owns durable work

The conversation ends and the pending claim disappears from the operational view. Persist the work in a record-backed state machine, orchestration, queue, or external system.

”Native” decides by itself

The easiest Salesforce feature is selected even though another system owns the business truth. Use native capabilities where the native boundary is a responsibility, not where procurement made them available.

Where the platform could simplify the handoffs

Salesforce may make the composition layer more intelligent: select a Flow or Apex capability, carry context across surfaces, create a process instance, and surface the right human handoff automatically.

The platform can reduce the plumbing between surfaces. It should not make ownership invisible. The system still needs to say which runtime owns policy, state, external truth, and evidence.

The operation should remain understandable across tools

For the claim, the agent can handle interpretation while the responsible systems calculate eligibility, retain approval, and verify payment. The handoffs need enough information to recover the work when one part fails.

The next post asks how another application or AI interface should discover and call those operations without inventing its own claim rules.

Where Should an Agent's Work Run: Flow, Apex, or Somewhere Else?