Flow + AI: Combining Automation and Intelligence

The Architectural Role of Each Layer

Flow and AI are complementary, not competing. The confusion arises because both can be described as "automation" — but they automate fundamentally different things.

Flow is deterministic automation. Given the same inputs and the same record state, it will always produce the same output. It is ideal for rule-based routing, data updates, approval processes, and anything where the correct behaviour can be precisely specified in advance. Flow's reliability comes from its determinism — you can test it comprehensively because it has no probabilistic component.

AI is probabilistic judgement. Given similar inputs, it will generally produce similar outputs, but not identical ones. It handles ambiguity, interprets natural language, generates drafts, and makes judgement calls where explicit rules would be impractical to enumerate. Its value comes precisely from its non-determinism — it can handle cases that rule-based automation cannot.

The architectural principle for combining them: use Flow for what can be precisely specified; use AI for what requires judgement. Programmes that try to use AI for deterministic tasks produce variable, harder-to-debug behaviour. Programmes that try to use Flow to replicate AI judgement produce brittle, over-engineered logic that requires constant maintenance.

Pattern 1 — Flows as Agentforce Agent Actions

This is the primary integration pattern in Agentforce deployments. The agent's reasoning model decides what action to take; the action itself is implemented as a Flow. The Flow is the "hands" of the agent — it executes transactions, queries data, creates records, and calls external APIs. The agent is the "brain" — it decides which Flow to invoke and with what parameters based on the conversation context.

This architecture has important implications for Flow design. Flows used as agent actions must be designed with the agent as the caller, which means they must handle parameter inputs cleanly (the agent passes values as variables), return structured outputs that the agent can use in its response, and handle errors gracefully rather than surfacing Salesforce error messages directly to the customer-facing agent response.

// Agentforce action invocation — conceptual representation
// The agent's reasoning loop produces something like:
{
  "action": "Get_Order_Status",
  "parameters": {
    "orderId": "extracted from conversation context",
    "customerId": "from authenticated session"
  }
}
// The Flow receives these as input variables,
// queries the order, and returns:
{
  "orderStatus": "In Transit",
  "expectedDelivery": "24 May 2026",
  "trackingNumber": "1Z999AA10123456784"
}
// The agent then synthesises this into a natural language response

Pattern 2 — Prompt Builder + Flow for Generative AI in Processes

Prompt Builder allows you to create reusable prompt templates that reference Salesforce data via merge fields, and to invoke those prompts from Flow using the Generate Text with Prompt Template action. This pattern enables generative AI steps in automated processes — not just interactive, human-facing features.

Use cases for this pattern include: generating a case summary and writing it to a field when a case is closed; generating a personalised follow-up email draft when a deal reaches a specific stage; generating an internal briefing note when a high-value lead converts. The common shape is: trigger event → Flow retrieves relevant data → Prompt Template generates text using that data → Flow writes the output to the appropriate record field.

The design consideration is latency. LLM invocations typically take 1–5 seconds. In a synchronous Record-Triggered Flow, this adds 1–5 seconds to the transaction time visible to the user. For most use cases, triggering the Prompt Builder invocation from an asynchronous Flow (After Save) rather than a before-save context eliminates this user-facing latency. The generated text appears on the record shortly after save rather than during the save transaction.

Pattern 3 — Einstein Classification in Decision Forks

This pattern uses Einstein prediction outputs — lead scores, opportunity scores, intent classifications — as decision variables within a Flow. The Flow retrieves the Einstein prediction result from a field or via a callout, then branches based on the score or classification.

A well-established example: a case-triggered Flow reads the Einstein Language intent classification result from the case, then routes the case to the appropriate queue based on the predicted intent. The AI does the classification; the Flow does the routing. Neither step is doing the other's job.

The design rule for this pattern: always include a default branch for low-confidence predictions. A Flow that branches on an Einstein classification must have a route for cases where the classification confidence is below your defined threshold — typically routing to a human review queue rather than taking automated action.

Error Handling and Testing for Non-Deterministic Steps

The hardest part of designing Flow + AI combinations is testing. Standard Flow testing assumes deterministic outputs — the same inputs produce the same results, and you can write unit tests that assert specific outputs. AI steps break this assumption.

The practical approach is to isolate the AI step behind a clear interface — a defined set of inputs and a defined output schema — and test the Flow logic separately from the AI output quality. The Flow tests assert that it handles each possible output correctly (high-confidence classification → route A; low-confidence → route B; error response → fallback). Evaluating whether the AI produces appropriate outputs for given inputs is a separate activity, performed using Salesforce's Prompt Builder evaluation tools or manual review against a representative sample set.

Error handling must address three AI-specific failure modes: API timeout (the LLM endpoint does not respond within the callout timeout — handle with a fallback default value); empty or malformed response (the AI returns no usable output — handle with null checks before using the output in Flow logic); and unexpected output format (the AI returns a response in an unexpected structure — validate output schema before processing).