Declarative Agentic Actions

No-Code Agent Integration Declarative agentic actions let you integrate agents into Salesforce Flows without writing code. Call an agent directly from automation to enhance your workflows.

What are Declarative Agentic Actions?

Declarative agentic actions are Flow actions that let you invoke a REDA AI agent from a Salesforce Flow. Instead of using Apex or APIs, you can drag-and-drop an agent action into your Flow, configure the inputs, and run the agent as part of your automation.

This enables powerful use cases:

Automated Processing — Trigger an agent when a record is created (e.g., "analyze this lead" when a lead is created)
Enrichment — Agent fills in missing fields based on external data
Routing — Agent decides which queue or user should handle a record
Notifications — Agent generates summaries to include in emails

Prerequisites

Before using an agent in a Flow:

Agent Must Exist — Create and configure the agent (prompts, tools, context fields)
Agent Must Be Active — The agent's Active Status must be turned on
Allow Automated Requests must be enabled — Set this on the Agent Definition to enable Flow invocations
Channel must be set to API — The Flow / Apex invocable surface only resolves agents whose Channel is API. Internal, Community, and External Widget agents are rejected at invocation time with a clear error.

Channel surface enforcement

An agent with Channel = API is bound to programmatic invocation only — Flow Builder, Apex, REST integrations. It cannot be placed on a record page (use the Internal channel), on a portal page (use Community), or on a public website (use External Widget). Pick the channel that matches the surface you intend to deploy on.

Setting Up an Agent for Flow Use

Open the Agent Definition
Go to the agent you want to use in a Flow.
Check Allow Automated Requests
Set this checkbox to enabled to allow Flow integration.
Configure the Agent
Ensure the agent has appropriate prompts and tools for the automation task.
Activate the Agent
Turn on the agent's Active Status.
Save
The agent is now ready to be used in Flows.

Using an Agent in a Flow

Create or Open a Flow
Open Salesforce Flow Builder (Setup → Flows or from a page).
Add an Action Element
Click "+" to add an element. Select "Action".
Search for REDA AI Agent Action
Search for "REDA AI" and select the action named "Send Message to REDA AI Agent".
Identify the Agent
Set the Agent Name input to the agent's Agent ID (e.g. "default-assistant") — the ID from the Agent Definition record, not the display name.
Configure Inputs
Map Flow variables to the action's inputs:
- Agent Name (required) — the agent's Agent ID
- Record ID (required) — the context record the agent works with
- Object API Name (required) — the record's object API name (e.g. "Opportunity")
- Message (required) — the prompt or instruction the agent should process
- Auto-Execute Actions — whether to auto-confirm and execute Action tools (true/false)
- Conversation ID — pass a previous turn's Conversation ID to continue a multi-turn conversation
- Automated Source — a label for this automation (e.g. the Flow's name), stored on the conversation for audit
- Create Incident on Error — if true, failures create an AI Incident Log record; if false, errors are returned in the output only
Configure Outputs
Capture the agent's response:
- Response — the agent's text answer
- Success / Error Message — whether the call succeeded, and the failure description if not
- Action Results JSON — JSON array of action execution results (when Auto-Execute Actions is true)
- Credits Used — AI credits the call consumed
- Conversation ID — pass into the next call to continue the conversation
- Is Async / Async Request ID — set when the response is processed asynchronously (see Async Agent Processing)
Use Outputs in Subsequent Steps
Pass the agent's response to other Flow actions (send email, update record, etc.).
Test and Save
Test the Flow with sample data. Save when ready.

Common Flow Use Cases

Lead Enrichment on Create

When a lead is created, a Flow triggers. The Flow calls an agent with the lead's information. The agent enriches the lead with company insights, identifies the best contact, and updates the lead record automatically.

Case Routing Decision

When a case is created, a Flow invokes an agent to analyze the case description and priority. The agent determines which team should handle it (Sales, Support, Billing) and the Flow assigns the case accordingly.

Opportunity Summary for Email

A Flow sends a weekly report of all open opportunities. For each opportunity, it calls an agent to generate a brief summary. The summaries are compiled into an email and sent to managers.

Passing files to the agent

A Flow can send one or more files to the agent to analyse — for example a PDF, an image, or a CSV already stored in Salesforce. Use the File Content Version IDs input: provide a collection of ContentVersion Ids for the file(s) you want the agent to read (one or several, up to 5).

In your Flow, obtain the ContentVersion Id(s) of the file(s) — for example from a Get Records element on ContentVersion — pass them into File Content Version IDs, and the agent reads the file contents as part of its response. The agent must have Allow File Upload enabled; supported types and the size limit follow your REDA AI settings — see File Upload.

Note

A single-file input, File Content Version ID, also exists for backward compatibility. For new Flows, use File Content Version IDs — it handles one or many. If both are provided, File Content Version IDs takes precedence.

Auto Execute Actions

Auto Execute Actions is a Flow input that decides whether the agent’s proposed actions actually run. There is no third option: a Flow has no screen, so a confirmation card has nowhere to appear.

Enabled — the agent’s Action tools execute, and their outcomes come back on the Action Results JSON output so the Flow can branch on them.
Disabled (the default) — the agent may still propose actions, and none of them run. Nothing is queued for approval and no error is raised; the proposal is simply dropped.

This is the trap in Flow automation. Leaving the input unset because you expect “normal confirmation behaviour” does not get you an approval step — it gets you an agent that answers as though it did the work while the record was never created and the email was never sent. If the Flow is meant to change data, set Auto Execute Actions to true and check Action Results JSON for per-action success.

With it enabled the agent treats the request as already authorised and runs its record-creation, record-update and email tools without prompting — so give a Flow-invoked agent only the Action tools you are content to have run unattended.

Multi-Step Autonomous Workflows

A single agent turn runs as one Salesforce transaction. Within that turn the agent can call the AI and its tools and then save data — but it cannot call an external service again after it has already saved. For most automations that is enough. When a task genuinely needs to create or update a record, then call an external service using that record, then write the result back, an API-channel agent can carry the work across additional automatic turns.

The agent requests a follow-up turn with the built-in continue_workflow tool. Each continued turn runs in its own fresh transaction — with its own callout and save budget — and picks up where the previous turn left off, with the records it just committed available to it. The agent decides when another turn is needed; if it can finish in one turn, it simply does.

API channel only — the capability is available exclusively to agents whose Channel is API. Internal, Community, and External Widget agents never receive it.
On by default, opt-out per agent — API agents have continue_workflow in their loadout automatically. To stop an agent from chaining turns, remove the tool from its loadout in Agent Runtime Preview → Edit Loadout, or deactivate the tool.
Bounded — a single task can chain up to a fixed number of turns (default 20, configurable in Setup), and every turn consumes credits under the normal per-turn limit, so a workflow can never run away.

Screen a new record against an external service

A Flow invokes an agent to onboard a new Account. The agent creates the Account, then calls continue_workflow because it now needs to send that Account's details to an external screening service. On the next turn it makes the screening callout, receives the result, and updates the Account with the outcome — all without a person in the loop.

When is a follow-up turn actually needed?

Only when an external call must happen after a save. An agent can already read data, reason, and create or update several records within one turn — so most Flow automations never need to continue. Reserve multi-step workflows for the create-then-call-then-write pattern.

Error Handling in Flows

If an agent action fails in a Flow:

The Flow receives an error status and can branch accordingly
You can add a Fault Handler to log the error or send a notification
The Flow can continue, retry, or stop based on the error type

Common error scenarios:

Agent Inactive — Agent is not active. Check the Active Status field and activate if needed.
Permission Denied — Flow user doesn't have access to a record. Check permissions and sharing.
Tool Call Failed — A tool called by the agent failed. Check logs for details.
Timeout — Agent took too long to respond. Check token budget and simplify if needed.

Best Practices for Flow Integration

Use Specific Prompts for Flow Tasks

Create specific prompts for Flow use cases. Example: "Analyze this lead and extract: (1) company size, (2) industry, (3) budget range. Return as JSON."

Keep Flow Calls Lightweight — Don't pass massive amounts of data to an agent in a Flow. Keep payloads focused on what the agent needs.

Monitor Token Usage — Each Flow invocation consumes credits. Monitor your credit consumption and optimize agent prompts to reduce tokens.

Set Reasonable Token Budgets — Ensure your agent's Token Budget is appropriate for the Flow task. A batch operation might use a lower budget than an interactive agent.

Test Thoroughly — Test your Flow with real data in a sandbox. Verify the agent produces correct outputs and doesn't cause unexpected side effects.

Frequently Asked Questions

No. The Flow / Apex invocable action only accepts agents whose Channel is set to API. If a Flow tries to invoke an Internal, Community, or External Widget agent, the action returns an error explaining the surface mismatch. Create a dedicated agent with the Channel set to API for Flow use cases.

Check your agent's Max Message Length setting. Flow inputs are bound by this limit. If your Flow message exceeds the limit, the agent will reject it.

Yes, if you assign write tools (record creation, record updates, etc.) and enable Auto Execute Actions. The agent can create and modify records as part of the Flow.

Capture the agent's output in a Flow variable. You can then log it to a debug record, email it, or store it in a field for audit purposes.

Not within the same turn — one turn is one transaction, and a callout cannot follow a save inside it. For a create-then-call-then-write task, an API-channel agent uses the built-in continue_workflow tool to continue on a fresh turn (see Multi-Step Autonomous Workflows above). This is available on API agents only, is bounded by a configurable turn limit, and can be removed per agent from the agent's loadout.

Next Steps

Explore prompt management to create specialized prompts for your Flow use cases, or learn about tools to enable agent actions.

← Previous: Build Agent with AI

Next: Agent Runtime Preview →