Standard Actions and Custom Actions: How to Extend an Agent the Right Way

In Agentforce, the real quality of an agent is defined less by how well it talks and more by what it can actually do. A strong agent is one that can execute real tasks, follow business rules, and connect to systems that matter. Salesforce supports two main ways to give an agent capabilities: standard actions and custom actions. Understanding the difference is essential because many configuration mistakes happen when teams assume the agent can do something just because it “sounds possible” in conversation.

Standard actions are built-in capabilities that come out of the box. They cover common and widely used operations, so they help you build a working agent quickly without custom development. However, it is important to remember that some standard actions may require the right license, feature enablement, or permissions. In other words, an action can exist as part of the platform, but still be unavailable until the organization has the correct access configuration. When a use case matches a standard action, this is typically the fastest and simplest route, because you rely on supported functionality rather than building from scratch.

Custom actions exist to extend the agent for your specific business needs. When standard actions are not enough, custom actions let you build exactly the operation your organization requires. This can include internal business rules, unique validation steps, specialized workflows, or integrations with systems outside Salesforce such as billing, logistics, ERP, or customer data platforms. Custom actions are the foundation of an enterprise-grade agent because they connect conversation to real execution in the environment your company operates in.

When you create a custom action, one of the most important choices is the reference action type. The reference action type defines what the custom action is built on and how it runs.

If you choose Apex, the action is backed by an invocable Apex class. This option is ideal when you need precise logic, strict validation, complex decision-making, integration handling, or fine-grained error control. Apex gives you maximum flexibility and predictability because it is code-driven and can enforce exact business rules.

If you choose Flow, the action is backed by an autolaunched flow. This is a strong option when the business process can be modeled in declarative automation. It is often easier to maintain and update without code, which makes it attractive for teams that want to iterate quickly while keeping the logic organized and governed.

If you choose Prompt Template, the action is backed by a predefined prompt template designed to generate structured content. This option is especially useful when the “task” is producing standardized text, such as a customer email, a case summary, a troubleshooting guide, or a response in a specific corporate format. It helps reduce variability and ensures consistent communication output.

If you choose API, the action is backed by a call to an external endpoint. This option is critical when the capability lives outside Salesforce and you want the agent to interact with external services. The action becomes a bridge that sends a request, receives a response, and maps returned values into variables so the agent can continue the workflow in a controlled way.

Creating a custom action happens in Salesforce Setup, on the Agent Actions page. You use the New Agent Action button to define the action and select the appropriate reference action type. After the action exists, it can be added to topics so the agent can access it as part of a governed set of allowed operations.

A good way to extend an agent correctly is to treat this as a disciplined design decision. Use standard actions when the platform already provides what you need and the access requirements are satisfied. Use custom actions when you must implement your organization’s unique process, rules, or integrations. Then choose the reference action type based on the nature of the task, whether it is best handled by code, by declarative process automation, by controlled text generation, or by external APIs.

Next, we move from “what actions exist” to “how actions behave at runtime.” The next topic is action instructions and input and output parameters, including settings such as Require Input, Collect Data, Filter, and Show in Conversation. These are the details that make actions reliable, controllable, and exam-ready, because they define how data is gathered, how actions are executed, and how results are presented and reused.