#agentforce-studio — Public Fediverse posts

Agentforce Agent Flow Action Best Practices

I recorded an Agentforce hands-on video and published it on Salesforce Break YouTube channel in February of 2025. That video has been watched about 15K times until today. Then I participated in an Agentforce Hackathon at TDX, and published a video that sums up what our solution as a team looked like. Then I stepped away from building on Agentforce for a minute.

A lot has changed since then. If I leave the usual product renaming frenzy aside, Agentforce got a major face lift: Then new studio and builder are nicer. Many advancements have been rolled out. We have Agentscript now for deterministic solutions.

When MVP Sally ElGhoul invited me to do a Code with Sally session with her, I decided to revisit my Agentforce experience. Power Agentforce with Flow Actions session we recorded together dives into flow action best practices when building on Agentforce.

Let’s dive into the content, shall we. For those of you, who prefer video content, the video is embedded below.

What Powers Agentforce: AI, Flow, and Sub-Agents

Agentforce is Salesforce’s AI platform that completes transactions, beyond generating content and delivering predictions, forecasts, and next best actions. Agentforce powers an agent to update records, book a hotel, sell a product, even sign someone up for a class.

Salesforce groups Agentforce use cases into a few categories. Employee agents handle internal help. Service agents and sales agents cover external, customer-facing work. Under the hood, the terminology has shifted since I last built an agent. Topics are now called sub-agents. The Atlas reasoning engine still connects a user’s natural language prompt to the right sub-agent. Each sub-agent contains actions built from Flow, Apex, or prompt templates. Agents can even act as sub-agents inside other agents. That capability is still in beta.

Actions are not locked to a single sub-agent either. The same flow action can be reused across multiple sub-agents. That gives builders real modularity instead of duplicated logic everywhere.

Flow Actions vs Apex Actions in Agentforce

A natural question follows. With AI doing so much already, do developers still need Flow or Apex actions? Yes, we still need them.

Employee agents run in the context of the user submitting the prompt. They get access to a built-in Query Records action that runs SOQL or SOSL directly. Service and sales agents work differently; they run under a dedicated user instead of the running internal user. They can’t use the same query action.

Early versions of Agentforce sometimes fetched and exposed information that should have stayed private. Therefore Salesforce does not provide query access to external agents out of the box. A custom Flow or Apex action forces developers to make a deliberate choice: they must decide which fields and records an agent can see. Any action that performs a DML operation needs Flow or Apex as well. That means anything that creates, updates, or deletes records.

Inside the New Agentforce Studio and Builder

The old Agentforce builder lived strictly inside Setup. The new Agentforce Studio behaves more like the Automation app that houses flows. It sits outside Setup for users with the right permissions. It also offers a more polished, less click-heavy experience than before.

The new interface provides a pulldown on the screen that toggles between the canvas view and the script view. Builders can change between a visual layout and the underlying Agentforce scripting language.

Agentforce can generate a starting structure when given a prompt describing what the agent should do. It creates sub-agents and placeholder actions automatically but stops short of drafting an actual flow. Builders still have to create that flow themselves and connect it manually.

A few rough edges remain. The builder sometimes throws incorrect warnings on simple text (string) inputs, flagging them as though they need a Lightning-specific format when they don’t. Record collection variables can fail outright, requiring a manual fix in script view. Feedback shared in the Ohana Slack community also warns against using the new builder inside a namespaced org, where it reportedly doesn’t work reliably. The older builder remains available as a fallback.

Building Flow Actions That Power Agentforce Agents

Every flow action behind an Agentforce agent starts as an auto-launched flow with defined inputs and outputs. The descriptions attached to those variables are important. Agentforce pulls those descriptions in as the definitions shown on the agent side. Vague labels create vague, unreliable behavior.

Building in extra flexibility from the start also pays off. Adding a spare text input or output variable lets you adjust an action without deleting and rebuilding it, which used to be required any time inputs or outputs changed.

One key design decision is whether an action should stay narrow or flexible. It can do one specific thing, or it can handle several related tasks through a parameter. For anything performing a DML, the safer route is locking the action down to a single purpose. For read-only lookups, the demo took the flexible route instead, building one action that searches for accounts, opportunities, cases, or contacts based on a parameter. A second parameter controls whether the match needs to be exact or just a partial text match.

The action also returns a result string alongside its main output. That string carries success or error messages back to the agent, useful during testing for transparency and optionally shown to the end user, too. On the security side, one practice stands out: hand-pick which fields a flow returns rather than letting Salesforce auto-select them. That is the same best practice recommended for guest-user flows on a public community site.

Live Demo: An Agentforce Agent in Action

The demo featured a business development agent tied to a dedicated service agent user. Sub-agents included finding an account by name and retrieving its details. Others pulled open opportunities and calculated a close probability using a prompt template.

When asked to find an account containing “Acme,” the agent located it right away. It offered to show details, then offered related opportunities once the user confirmed. For the final step, a Flex prompt template reviewed the opportunity record. It also pulled in recent email and task activity, then returned a probability to close. In this live run, the agent returned 35 percent, explaining its reasoning by referencing recency of contact and the tone of recent interactions.

Grouping the “find account” and “get account details” actions under the same sub-agent made the sequence more reliable. Before that change, there was no guarantee the agent would always chain the steps correctly on its own.

Common Agentforce Questions Answered

Audience questions covered practical ground throughout the session, beyond just the demo. Here’s what we covered:

• Flow vs. Apex: Default to Flow first. Move to Apex only when Flow cannot handle the requirement. The deciding factor is long-term maintenance: does the organization have a developer on staff or under contract who can support Apex code going forward?
• Handling errors: Use fault paths for any flow that performs a DML. Pass a clear result back to the agent, either through a custom output variable or the flow’s built-in error message.
• Frequent errors in the new studio: A few options can help. Consult an AI assistant (e.g. Claude). Use Agentforce itself. Open a support case with Salesforce.
• AI-assisted flow development: Agentforce Vibes came up as a strong option, especially inside tools like VS Code.
• AI-generated flows and existing bugs: One attendee asked whether letting AI generate the underlying flow would fix the input and output errors shown earlier in the session. That likely wouldn’t fix the specific bug.

Flow and Apex are tools that fit different jobs, and AI can support both without replacing good judgment about which one to use.

Security and Permissions for Agentforce Agents

Every new agent in the demo org came with an automatically generated permission set. That set ties to a dedicated Einstein Agent user. The permission set controls which objects and fields the agent can see. It does not control record-level sharing.

Record-level access has to be handled inside the flow or Apex action itself. The permission set only governs object and field visibility, nothing more. The advice here is to test both positive and negative scenarios thoroughly: confirm that an agent can retrieve the right records, then confirm it cannot retrieve records it should not see.

Lessons From Breaking the Agentforce Demo

Near the end of the session, attendees requested a stress test of the agent. The request was a single, multi-step message: find the Acme account, list its details, find the open opportunity, and return the close probability, all at once. The first attempt confused the agent, handling some steps but not the full sequence. A second attempt came closer after tightening the sub-agent grouping. It still did not complete cleanly.

Sally ElGhoul used the moment to make a broader point about agent design. Agentforce agents rarely work perfectly on the first build. They require repeated testing with different phrasing. Builders need to pay careful attention to how instructions are written. The agent should be treated as a living project, not a one-time deployment.

Bring These Agentforce Lessons to Your Org

This session offered a grounded look at where Agentforce actually stands today, beyond the marketing pitch. Flow actions and Apex actions remain essential. That is not because AI cannot handle simple tasks. Salesforce intentionally requires developers to make deliberate choices about data access and security. The new Agentforce Studio is more usable than its predecessor. It still carries bugs around input and output variables that builders need to work around.

The live demo, including the moment it broke under audience pressure, illustrated the honest reality of building with Agentforce. Success depends on thoughtful action design and careful permissioning. It also depends on repeated testing with varied phrasing before anything reaches production.

Explore related content:

​​​​What Is Vibe Coding? And What’s New in Agentforce Vibes for Developers?

Setup with Agentforce: What Admins Can Actually Do Right Now

Headless 360: Developer Lessons From a Weekend of Building