Agentforce standard actions: what ships, and when to build your own

Turn on Agentforce and your agent can already do a dozen things. It can read records, answer a question from Knowledge, summarise an account, and draft an email, none of which you built. Most setup guides skip past that on the way to “now write a custom Apex action,” and teams end up rebuilding capabilities Salesforce shipped them for free.

My rule is simple. Start with the standard actions, ship the generic ones as they are, and reach for a custom action only when the task has a rule the agent must not be allowed to improvise. Get that split right and the first agent goes live in days. Get it wrong and you either drown in bespoke Apex or hand a customer-facing agent a query tool with no guardrails.

What a standard action is

An action is a tool the agent can call. A standard action is one Salesforce built, maintains, and enables for you, versus a custom action you assemble from a Flow, an Apex method, a prompt template, or an External Services API. The full catalogue lives in the Standard Agent Action Reference, and it grows every release, so treat any list, this one included, as a snapshot.

The ones you meet first sit under the Agentforce Platform group and work on any object:

Query Records and Query Records with Aggregate let the agent read records, and count or sum across them, filtered by criteria it assembles at runtime.
Identify Record by Name resolves a name the user typed (“the Acme renewal”) to an actual record ID before another action uses it.
Get Record Details pulls the fields of a specific record the agent already has in hand.
Answer Questions with Knowledge grounds a response in your Salesforce Knowledge articles instead of the model’s memory.
Summarise Record produces a readable summary of an account, case, opportunity, or lead.
Draft or Revise Email writes or rewrites an email in context.

On top of that, the Sales and Service groups add role-specific tools. On the Sales side you get actions like Find Similar Opportunities and email drafting tuned for reps. On the Service side, actions that pull the cases tied to a contact and route a conversation toward a human. The exact roster depends on the clouds you have licensed and the release you are on.

The reasoning engine picks the action, so the name is doing work

Here is the part that trips people up. You do not call these actions. You assign them to a topic, and the Atlas reasoning engine decides at runtime which one to fire, based on the user’s message, the topic’s instructions, and the name and description of every action in scope.

That means the metadata is the interface. An action named “Query Records” with a vague description is a coin flip when the agent also has “Get Record Details” available and the user’s request could plausibly need either. I made this point at length about custom Apex actions, where the description is the code that matters most, and it holds just as hard for the standard ones. You cannot rewrite what a standard action does, but you decide which actions share a topic, and you write the instructions that tell the agent when each is the right call.

So the first lever you have on standard actions is not configuration. The lever is curation. Put too many overlapping actions in one topic and the agent misroutes. The fix for “my agent keeps calling the wrong thing” is almost always fewer actions per topic and sharper instructions, not a new action.

Query Records is the one to handle with care

Query Records is the most powerful standard action and the one I trust least in a customer-facing agent. It hands the agent a general-purpose read tool and lets it decide, on its own, what to look up. That works in an internal employee agent where a wrong-but-visible answer costs a second look. On a public service agent it becomes a liability, surfacing a record, or a field on a record, you never meant to expose.

Two things keep it in bounds. First, every action runs as the agent’s assigned user, so field-level security and sharing already gate what it can read. If a field is off-limits to that user, Query Records cannot return it. Get the running user’s permission set right and you have a real floor under the behaviour.

Second, you can scope it. Rather than leaving a broad Query Records action in a customer topic, build a narrow custom action that reads exactly the object and fields the topic needs, with the filter baked in, and leave the general one out. The agent gets a tool it cannot misaim. That scoping is the single most common hardening step I make on an agent moving from demo to production.

When a standard action is the right answer

Reach for standard first when the task is generic and read-mostly:

Answering from Knowledge. The Answer Questions with Knowledge action plus a well-tended article set beats any custom retrieval you would hand-roll for the same job, and it is the backbone of most service agents.
Summarising a record for a human to read.
Drafting an email the human will review before it sends.
Resolving a named record to an ID inside a larger flow.

In each case the action is doing something with no branching business rule attached, the output is low-stakes or human-reviewed, and rebuilding it would only reproduce what Salesforce already tests and maintains through every release. Every standard action you adopt is one you do not have to version, deploy, or debug when the platform changes underneath it.

When to build a custom action instead

Build custom the moment the task carries a rule the agent must follow exactly the same way every time. Standard actions are read-mostly and general by design. They are the wrong tool when you need any of these:

Deterministic logic: a refund under a threshold, a discount inside a policy band, an eligibility check. The agent should never be free to reason its way to a different answer. Wrap the rule in Apex or a Flow so the outcome is the code’s, not the model’s.
A write with side effects. Creating or updating records that trigger automation, or anything that touches money, belongs in a custom action with its own validation, not a generic update the agent aims freehand.
A callout to another system. Reaching an ERP, a payment processor, or any external API means External Services or an Apex callout, not a standard action.
A multi-step task that must not half-complete. If three things have to happen together or not at all, that is one custom action with a transaction boundary, not three the agent might interleave.

The decision between Flow, Apex, and a prompt template for the custom action is its own question, and I laid out how I make it in the Flow, Apex, or Agentforce decision guide. Roughly: Flow for declarative writes and orchestration, Apex when you need logic, control, or a callout, and a prompt template when the output is generated text rather than an operation.

Configuring what you keep

You cannot change what a standard action does internally, but you are not stuck with defaults either. When you add one to a topic you can:

Write action-level instructions that tell the agent when to use it and how to phrase what it returns, disambiguating two actions that overlap.
Set inputs and outputs so the action receives the right context and its result is available to the next step, which is how you chain Identify Record by Name into Get Record Details.
Decide the human-in-the-loop posture. Draft or Revise Email drafts; a human still sends. Keep that boundary explicit for anything customer-facing, and design the escalation path before launch, not after the first bad answer.

If a standard action is close to what you need but not quite, the move is not to fight it. The move is to leave it out of that topic and add a purpose-built custom action beside the standard ones you keep. Standard and custom actions coexist in the same agent, and the best agents I see are mostly standard actions with a handful of sharp custom ones where the rules live.

A practical starting point

For a first service agent, I would enable the standard Knowledge, summarise, and record-detail actions. Add a scoped custom action for the one or two writes the use case needs, and deliberately leave broad Query Records out of any customer-facing topic. That gets you a grounded, useful agent whose every consequential action is one you wrote and can test.

Then measure. Watch which actions the agent selects in production traces, find the topic where it keeps reaching for the wrong tool, and fix that with curation and instructions before you write more code. The library is bigger than most teams use. The skill is not adding actions but knowing which few belong in each topic, and which one rule is too important to let the agent improvise.

If you are scoping a first agent and want a second pair of eyes on the build-versus-adopt split before you commit to a pile of custom Apex, that is the kind of call we help teams make on our Agentforce work.

Understanding the basics

What are standard actions in Agentforce?

Standard actions are prebuilt tools Salesforce ships and enables when you turn on Agentforce, covering common tasks like querying records, answering from Knowledge, summarising a record, and drafting email. You assign them to a topic and the reasoning engine decides when to call them. The current set is documented in the Standard Agent Action Reference.

Can you edit a standard Agentforce action?

You cannot change what a standard action does internally, but you control which actions live in a topic, the instructions that tell the agent when to use each one, and the input and output mappings. When you need different behaviour, you leave the standard action out and add a custom action built from Flow, Apex, a prompt template, or External Services.

When should I build a custom action instead of using a standard one?

Build custom when the task carries a rule the agent must follow the same way every time: a policy-bound decision, a write with side effects, a callout to another system, or a multi-step task that must not half-complete. Use standard actions for generic, read-mostly, or human-reviewed work.

Is Query Records safe to give a customer-facing agent?

It respects the agent user’s field-level security and sharing, so it can only read what that user can read, but it lets the agent decide what to look up, which is unpredictable on a public agent. In production I usually replace it with a narrowly scoped custom action that reads only the object and fields the topic needs.

Standard actions get an agent working fast; the custom ones are where the risk and the value both concentrate. If you want help drawing that line for a specific use case, talk to us, or start with the Agentforce Readiness Assessment to see whether your data and processes are ready for an agent at all.