Building Agent-Ready Salesforce Flows for Agentforce

Architecting Flows for Agentforce integration

Salesforce automation is moving toward agentic workflows. Traditional Flows leaned on Record-Triggered or Screen Flows to handle human interaction or data changes, while Agentforce needs Flows an AI agent can invoke directly, with no user interface anywhere in the path.

That changes the design. You treat the Flow as a direct service endpoint, much like a microservice called through an API or an Apex subflow, instead of a UI interaction layer.

From screens to service endpoints

Older Flow work focused on collecting user input through screens or reacting to database events. Agent execution skips the visual interface. The agent reaches the Flow's capability through defined input and output variables, which carry the context going in and the results coming back. That puts an Agent-callable Flow in the same family as an Autolaunched Flow invoked from Apex or as a subflow.

Context comes from the descriptions

A human user can infer intent from a screen's layout. An agent has only the metadata and documentation inside the Flow definition, so the description fields are the documentation the agent environment reads.

Give every component a real description, the Flow itself and each input and output variable in particular. Say what the Flow is for, what each input variable expects (data type, context, constraints), and how the output variables are structured and what they mean. That text is the instruction manual the agent uses to build its invocation parameters.

Building an agent-ready Autolaunched Flow

Take a common requirement: retrieving related records from a primary record ID. The Flow has to be an Autolaunched Flow defined strictly by its input and output variables.

For this example, we want every Case linked to the same Account as a specified primary Case, with the primary Case left out.

1. Define input and output variables

Mark each variable as available for input or output. Note the Record type variables for complex outputs, collections in particular.

API Name	Description	Data Type	Collection	Available For
inputAccountId	The Id of the Account associated with the primary Case.	Text	False	Input
inputCaseId	The Id of the primary Case record to exclude from results.	Text	False	Input
outputCases	The collection of related Case records returned to the Agent.	Record (Case)	True	Output

2. Implement the logic with Get Records

To keep the service endpoint lean, do as much of the work as you can in a single query element and map the results straight into the output variable.

1. Add a Get Records element to the canvas.
2. Object: Case
3. Criteria:
   • AccountId Equals {!inputAccountId}
   • Id Does soql-not-in-not-equal-exclusion/" class="auto-link">Not Equal {!inputCaseId}
4. How many records to store: All records.
5. How to store record data: Choose fields and assign variables (advanced).
   • Map only the fields you need (e.g., CaseNumber, Subject, Description) into fields on the outputCases Record Collection Variable.

That cuts the intermediate assignment steps, loads the query results straight into the output structure, and respects the data retrieval governor limits.

Testing governor limit consumption

Testing an Agent-callable Flow means simulating the agent's request payload. Use Debug in Flow Builder:

1. Set the values for all input variables (inputAccountId, inputCaseId).
2. Turn on Show Governor Limit Consumption in the Setup panel.

The Debug details for the Get Records element then confirm how many SOQL queries ran, which should be one, and how many query rows came back, which matches the count of records assigned to {!outputCases}. That tells you the Flow runs efficiently and fills the output structure the agent expects.