💬 In plain words: An action is a specific capability you give to an AI agent. In Salesforce Agentforce, there are five types of actions you can build. Choosing the right type for a specific business requirement is a core architectural skill, not just a matter of personal preference.
⚡ 1-Minute Summary:
- The five action types are: Flow, Apex, Prompt Template, External Service, and MCP.
- The AI model chooses which action to run by reading the action's description. Therefore, you must write descriptions as explicit selection criteria.
- If you use Apex, the action should return a decided value and a reasoning string, never just a raw data record.
The Module Map: Agent Capabilities
MODULE 4 Root: "What can the agent actually DO, and who decides when?" ├─ 4.1 The Five Action Types (You are here) ├─ 4.2 Descriptions as Selection Criteria ├─ 4.3 Return a Decision, Not Data └─ 4.4 Actions vs. Reasoning Actions
📌 Example: A customer service agent might need four distinct actions: Check system outage status (built with Flow), calculate a complex prorated refund (built with Apex), draft a personalized apology note (built with a Prompt Template), and read a live power-grid feed (built with an External Service).
Core Concept: The Five Action Types
Agentforce gives you five distinct tools to build actions. You should select the tool based strictly on the business requirement.
- Flow: Best for declarative logic and interacting with standard Salesforce data. Use this when a Salesforce Admin should own and maintain the logic.
- Apex: Best for complex business rules, heavy calculations, bulk processing, shaping data across multiple objects, careful error handling, and anything that requires strict unit tests.
- Prompt Template: Best when the desired output is generated natural language (prose) rather than a hard data value.
- External Service: Best when the system of record lives outside of Salesforce and exposes a standard OpenAPI specification.
- MCP (Model Context Protocol): Best when you need to expose an external tool securely over MCP to provide governed, discoverable tools for the agent.
🧠 The "FAPEM" Rule of Thumb: Flow, Apex, Prompt, External, MCP. Default to Flow first. Only step up to Apex when Flow gets too complex. Use a Prompt Template when you need prose. Use External Services or MCP when the truth lives outside Salesforce.
Architectural Constraints:
- Subagents do not share actions. If two different subagents need to do the same thing, you must assign the action to each of them separately.
- Every external callout must go through a Named Credential. Never hardcode endpoints or secrets in your Apex code.
🧭 360 Card — The Five Action Types
- Rule: Pick the action type based on the requirement. Start with Flow, and justify every step away from it.
- Gain: You build a defensible architecture based on logic, rather than just defaulting to whichever coding language you prefer.
- Reach for Apex when: You need strict eligibility decisions, complex pricing, bulk processing, robust callout retries, or unit test coverage.
- Price: A mixed technology estate. Supporting four different action types means your team needs four different skill sets and maintenance strategies.
- Limits: A subagent can have a maximum of 15 actions. Actions have a hard 60-second timeout. Standard Apex limits apply during execution.
- Mirror (Everything in Apex): It works, but it forces every minor future change to go through a developer release cycle instead of a quick admin fix.
- At Volume: The AI's ReAct loop might call a single action multiple times in one turn. Highly inefficient actions will exhaust your org limits very quickly.
⚠ INTERVIEW TRAP: If an interviewer asks why you chose Apex over Flow, never say "because Apex is more powerful." The expected answer focuses on the requirement: declarative, admin-owned logic belongs in Flow; complex business rules and logic requiring unit tests belong in Apex.
Core Q&A
Q: When would you write an Agentforce action in Apex rather than Flow?
🎯 Say this first: "I choose Apex when the requirement involves complex business rules, heavy mathematical calculations, bulk processing, or anything critical enough to require strict unit testing."
A: You always start from the requirement, not the technology:
- Flow is the correct choice when the logic is declarative, the data lives inside Salesforce, and a system admin is expected to own and maintain the changes.
- Apex earns its place when you need to make complex eligibility decisions, perform pricing calculations, process bulk data, shape data across multiple unrelated objects, manage callouts with retry logic, or handle precise errors.
- Test Coverage is the ultimate deciding factor. If a business rule is critical enough that you need to write assertions against it to prevent future regressions, it belongs in Apex.
For context, the other action types are decided by their output or origin: use a Prompt Template when the desired output is generated prose, and use an External Service or MCP when the system of truth lives outside of Salesforce.