Flow Integration Reference

Where the Action Lives

In the Flow Builder, add an Action element, then search for “REDA AI” or filter to the Apex action category. The action label is Send Message to REDA AI Agent. It works in any Flow type that supports Apex actions: record-triggered, screen, scheduled, platform-event-triggered and autolaunched.

For step-by-step setup, see Invoking REDA AI from Flows. This page focuses on the contract.

Inputs

Three fields are required; six are optional.

Outputs

Permissions

The action runs under the user the Flow itself runs under. The running user must be able to:

• Use REDA AI — assigned the REDA AI User permission set (or REDA AI Admin).
• Read the record passed as Record ID.
• Read the agent’s configured context fields on that record.
• Execute any tools the agent will call — tools run as the same user.
• If Auto-Execute Actions is on: write to whatever objects the agent will modify.

For record-triggered and platform-event Flows that run in system context, choose carefully whether system-mode is appropriate — the agent and any tools will inherit that elevated context. For sensitive automations, run the Flow as a specific service user with a tightly-scoped permission set.

Common Flow Patterns

Record-triggered automation

Fire on insert or update of a record (Opportunity, Case, Account, custom object), pass the triggering record’s Id and the agent’s instruction. Useful for AI-summarised case routing, opportunity scoring, lead qualification.

Scheduled automation

A scheduled Flow iterates a set of records and calls the action for each. Useful for daily summaries, periodic enrichment, batch classification. Be mindful of the daily Apex governor budget — one call per record can add up.

Platform-event triggered

A subscriber Flow on a platform event invokes the agent. The classic example is the messaging-channel pattern: an inbound message platform event fires a Flow that calls the agent, then posts the agent’s reply back through an outbound messaging tool. See Messaging Channel Integration for the full pattern.

Screen Flow

An interactive screen Flow lets a user trigger an agent on demand from a button or page action. The Flow runs in the user’s context; rendering the agent’s response back to the user happens through Flow display elements.

Multi-turn within a Flow

For Flows that need several conversational turns, capture the Conversation ID from the first call and pass it back on subsequent calls. The platform threads the turns into one Conversation record.

Error Handling

Always branch on Success after the action element:

• true — proceed using Response.
• false — read Error Message and decide how to recover. Common patterns: retry on a later cycle, set a status field on the parent record, send a notification to an admin.

Use Create Incident on Error to control whether failures end up in the Incident Log:

• Turn it on for production automations where every failure is worth investigating.
• Turn it off for high-volume Flows where individual failures are tolerable and would otherwise create incident noise.

Async Path

For heavy workloads — particularly large file payloads — the platform may route the request to async processing. When that happens, the action returns immediately with Is Async = true and an Async Request ID. The Flow is done; the agent run continues in the background.

To react to async completion, build a record-triggered Flow on Async Request that fires when the record reaches Completed or Failed status, and process the agent’s reply from the linked Conversation. See Async Agent Processing for the full lifecycle.

Bulkification & Governor Considerations

• One agent call per Flow execution. Each invocation of the action is a callout to the model. Flows that fire on bulk DML should pass the records through a loop or a record-triggered Flow per record — bulkifying within a single Flow execution doesn’t batch the model calls.
• Callout governor limits apply. Salesforce caps callouts per transaction. For Flows that may be invoked in bulk, consider the daily callout limit and the per-transaction cap.
• Credit budget. Each call consumes credits. Plan retention and frequency so the org’s monthly credit budget isn’t exhausted by automation traffic.
• Async fallback. If a heavy file payload would exceed synchronous limits, the platform falls back to async automatically. Your Flow should still branch on Is Async for completeness.

Audit & Observability

• Every Flow-driven call produces a Conversation record. Filter the Conversation list by Automated Source equal to your Flow’s name to find runs from a specific automation.
• The Channel on the conversation reflects the agent’s configured channel (typically API for Flow-driven agents).
• Failures with Create Incident on Error on land in the Incident Log with the Flow name in the context.
• Use Conversation Debugger on any conversation that didn’t produce the expected outcome.

Configuring the Agent for Flow Use

For an agent to be reachable from Flows:

• Its Channel must include API.
• Tools you want the agent to use from Flow calls must include API in their channel scope.
• If Auto-Execute Actions will be on, ensure the agent’s toolset is constrained to operations safe to run without human review.
• Consider a dedicated agent for each major Flow use case rather than one general-purpose agent — persona, prompts and toolset are easier to govern that way.

Best Practices

Always set Automated Source. It’s the single most useful field for tracing a conversation back to the Flow that produced it.

Be deliberate about Auto-Execute Actions. Without it, an agent that proposes a write returns a confirmation card — which a Flow has no way to render. Either turn on auto-execute or constrain the agent’s toolset to read-only and pre-approved write tools.

Branch on Is Async in every production Flow. Treating the response as synchronous when Is Async is true leaves the Flow waiting for an answer that never arrives in that call.

Use a service user for sensitive automations. The agent inherits the running user’s permissions. A dedicated service user with a narrow permission set is easier to audit than a Flow that runs as whoever happened to trigger it.

Pass Conversation ID when continuing a thread. Without it, every call looks like a fresh conversation and the agent has no memory across turns.

Test in sandbox before going live. Flows that drive AI calls have surprising failure modes — rate limits, credit exhaustion, async fallback — that don’t show up in unit tests. Run the Flow against representative records in sandbox and verify the Conversation transcripts before promoting.

Automation and reliability

Bulk Flow invocations can return deferred request IDs instead of immediate answers. Review downstream Flow elements that expect response, credits or action-result output in the same transaction. Automated action handling carries the configured channel and execution mode, and retains actual outcomes in conversation context; this does not guarantee an extra narrated turn. Explicit datetime offsets are preserved in supported event, scheduled-action, field-write and CSV paths. Offset-free values retain the running user's interpretation. Routine System-mode processing no longer raises warning incidents merely because it uses that mode; ERROR-level notifications and incident logs remain. File extraction respects the configured output limit, semantic status colours work across the supported Salesforce themes, and packaged tests avoid static Account record-type references that blocked installation in orgs without those record types.

Frequently Asked Questions

Next Steps

Read Invoking REDA AI from Flows for the step-by-step setup tutorial, or Messaging Channel Integration for the canonical pattern of using Flows as the bridge to external messaging systems.