How to Build and Package Agentforce Actions, Subagents and Agent Templates for AgentExchange

An ISV ships Agentforce capability on AgentExchange as four packageable component types. Agent actions, subagents (called topics until April 2026), prompt templates and agent templates all go into a managed package, and Salesforce lists every one of them as available in both managed 2GP and managed 1GP. The agent itself never ships. You package an agent template, and your customer creates their own agent from it after install.

For a SaaS company, that changes what you are really building. You aren't shipping a finished assistant. You are shipping a set of actions your customer's admin assembles, a template that gives them a sensible default, and the Apex or flows that hold your product logic. Appnigma's marketplace apps service builds "a Salesforce managed package or HubSpot app built around your product and customer workflows," with "Salesforce security review preparation and responses." If you are an admin adding actions to your own org's agent, Salesforce's guide to building Agentforce actions is the better starting point.

Updated October 2026. Checked against the Salesforce Second-Generation Managed Packaging Developer Guide, the ISVforce Guide and Salesforce Help. This update corrects the earlier version of this post. It said Agentforce components need 2GP and that flow actions can use screen flows. It also said a prompt template calls actions and that customers can always override a packaged prompt template. It adds the agent template workflow, the Agent Script restriction, what subscribers can change after install, and the Agentforce-specific security review rules.

What each Agentforce component does, and the metadata that ships it

Each component maps to a metadata type in your package. Salesforce's Package Agentforce Metadata Components table lists all four as "Managed 2GP and Managed 1GP."

The subscriber column comes from the manageability rules in Components Available in 2GP. Packaged actions, subagents and prompt templates are "updated during package upgrade" and the subscriber can't delete them. One requirement sits in front of all of this. "Any agent action or topic that will be packaged must be in the Agentforce Asset Library," per the packaging page.

1GP works too, with a step 2GP doesn't need. To turn on Agentforce in a 1GP packaging org, "you must log a case with Salesforce Partner Support" and request Agentforce Extensibility for ISVs, and "only 1GP development orgs created from Environment Hub can have Agentforce provisioned," per Get Access to Agentforce in Your 1GP Packaging Org. That page lists actions, topics and prompt templates but not agent templates, so confirm agent template support in the same Partner Support case before you plan a 1GP release around one. Migrating to 2GP is a reasonable choice for other reasons, and our guide to moving a 1GP managed package to 2GP covers it, but Agentforce alone doesn't force the move.

Are Agentforce topics now called subagents?

Yes. Salesforce's Agent Script guide says "beginning in April 2026, agent topics are now called subagents" and "there are no changes to functionality." The metadata didn't change. A subagent is still GenAiPlugin in your package, and older docs, the packaging tables and the Metadata API still say topic.

For your listing and your customer documentation, use subagent. That is the word the customer's admin now sees when AgentExchange tells them to go to Subagents and "click Add from Asset Library," per Find PreBuilt Agentforce Assets on AgentExchange.

Which logic can back a packaged agent action?

Salesforce Help lists what a custom action can call in Create a Custom Agent Action. It covers invocable and REST Apex, external services and MuleSoft APIs. It also covers "autolaunched flows" and "prompt templates." The developer guide adds Named Query and AuraEnabled actions. Flows must be autolaunched. Every official list says autolaunched flows, and none mentions screen flows.

For most SaaS products the choice is simpler than the list, because your product logic already lives somewhere and the action is a thin wrapper around it. Invocable Apex suits logic you want to protect. Actions themselves have no IP protection, but the components list notes they "can incorporate flows or Apex code that do have IP protection." Autolaunched flows suit logic your customer's admin should be able to read and extend. API actions such as External Services and Apex REST suit calls into your own backend.

Prompt templates are an action type, not a layer that calls actions. The agent runs the template as the action and gets the LLM response back. The earlier version of this post had that relationship backwards. The agent's reasoning chooses which action to run, and a prompt template is one of the options. Apex or a flow can still supply grounding data to the template.

MCP is the exception to plan around. You can package an MCP server registration. The tool actions that reference its tools are another matter, and MCP for Agentforce Metadata in Managed Packages says "MCP tool actions" aren't packageable at this time. If your product already exposes an MCP server, the customer still builds those tool actions in their own org.

Packaged Apex has one rule that trips up teams who built the action in a scratch org first. The class, the invocable method and the invocable variables "must all be marked as global," per Components Available in 2GP. Here is a minimal action written that way.

global with sharing class ClosingSoonAction {
  global class Request {
    @InvocableVariable(required=true label='Days ahead' description='How many days ahead to look for close dates')
    global Integer daysAhead;
  }
  global class Result {
    @InvocableVariable(label='Opportunity names')
    global List<String> names;
  }
  @InvocableMethod(label='List My Deals Closing Soon' description='Returns open opportunities the running user owns that close within the given number of days')
  global static List<Result> run(List<Request> requests) {
    Integer maxDays = 0;
    for (Request req : requests) {
      maxDays = Math.max(maxDays, req.daysAhead);
    }
    Date cutoff = Date.today().addDays(maxDays);
    List<Opportunity> opps = [
      SELECT Name, CloseDate FROM Opportunity
      WHERE OwnerId = :UserInfo.getUserId() AND IsClosed = false AND CloseDate <= :cutoff
      WITH USER_MODE
      ORDER BY CloseDate
      LIMIT 200
    ];
    List<Result> results = new List<Result>();
    for (Request req : requests) {
      Date reqCutoff = Date.today().addDays(req.daysAhead);
      Result res = new Result();
      res.names = new List<String>();
      for (Opportunity opp : opps) {
        if (opp.CloseDate <= reqCutoff) {
          res.names.add(opp.Name);
        }
      }
      results.add(res);
    }
    return results;
  }
}

Two choices in it come from the Agentforce security review rules. The input is a number, not a record ID. And the query runs WITH USER_MODE, so object, field and sharing access follow the running user. The label and description matter as much as the code, because they are what the agent's reasoning reads when it decides whether to call the action.

How an agent template gets from your scratch org into a package

Salesforce's Develop and Package Agent Templates Using Scratch Orgs puts it plainly. "Agents are distributed by ISVs as agent templates." You build and test a real agent in a namespaced scratch org, then turn it into a template.

Check the blueprint before anything else. "You can't create packageable agent templates from agents that use Agent Script as their blueprint," per the same guide. Agent Script is the scripting language behind the newer Agentforce Builder. If you want to ship an agent template today, build that agent without Agent Script. Your actions, subagents and prompt templates package the same either way.

The scratch org needs Agentforce and Prompt Builder turned on. Salesforce's scratch org guide uses this definition, and the edition can be Partner Developer, Partner Enterprise, Developer or Enterprise.

{
  "orgName": "GenAI Scratch Org",
  "edition": "Partner Developer",
  "features": ["Einstein1AIPlatform"],
  "settings": {
    "einsteinGptSettings": {
      "enableEinsteinGptPlatform": true
    }
  }
}

The workflow then runs in five moves.

1. Build and test the agent in the scratch org. Agentforce-enabled scratch orgs include the Agentforce Testing Center.
2. Retrieve it with sf project retrieve start --metadata Agent:My_Agent --target-org MyNamespacedScratchOrg.
3. Generate the template with sf agent generate template --agent-file force-app/main/default/bots/My_Agent/My_Agent.bot-meta.xml --agent-version 1 --source-org MyNamespacedScratchOrg.
4. Deploy the template back to the scratch org and create a new agent from it to confirm it works.
5. Remove the original Bot, BotVersion and the GenAiPlannerBundle without "Template" in its name, then create the package version.

Step 3 does more than copy files. The command writes a BotTemplate and a new GenAiPlannerBundle that "replaces references to the local version of assets (which can't be packaged) with references to their global equivalents," per the agent template guide. Step 5 matters because "agents aren't packageable," and leaving Bot and BotVersion in the package directory causes packaging errors. Two more setup items catch teams late. Packaging BotTemplate needs Einstein Chatbot enabled in your Dev Hub org. Packaging prompt templates needs the prompt template manager permission set declared in sfdx-project.json, which the prompt template packaging considerations show as this entry.

"packageMetadataAccess": {
  "permissionSets": ["EinsteinGPTPromptTemplateManager"]
}

What your customer can change after install

This is where agent components differ most from the rest of your package, and it should shape how you design them. Your upgrades push changes to actions, subagents and prompt templates, and the customer can't delete those components. They also can't edit a packaged subagent's action list. "Subscribers can't edit which actions are associated with a managed-installed topic," and they "must manually create a copy of the topic" instead, per Components Available in 2GP.

That copy is the hidden cost. Once a customer copies your subagent to add one of their own actions, your next upgrade improves the original and not their copy. So ship subagents small enough that customers rarely need to change them, and give them separate actions they can add to their own subagents instead.

Prompt templates have their own rules. "Customers can't edit packaged templates directly," but they can always clone one into an independent custom template, per the packaging considerations. You can mark a template overridable, which lets subscribers create local versions. "If a subscriber activates an override version, that version takes precedence over the publisher's active version." Decide per template. A template that formats your product's data probably shouldn't be overridable. A template that sets the tone of a customer email probably should.

The agent template is the one piece the customer fully owns. After install, they "use the Agentforce UI to create an agent from your template," per the agent template guide. From there the agent is theirs to edit. Treat the template as a well-configured starting point rather than a product surface you control.

Security review rules that apply only to agent components

Agent actions go through the same AgentExchange security review as the rest of your package, and the ISVforce Guide adds rules for them. The Secure Your Agentforce Custom Actions page asks you to "classify all custom actions" in your package documentation as employee-facing or service-agent, and as public or private. It also requires "CRUD, field-level security (FLS), and record-level (with sharing) access checks."

One rule changes how you design inputs. A custom action can't take a record ID or a generic record reference as user-controlled input. The same goes for object names and field names, and the page says such actions "aren't allowed." An action that lists a user's deals should take a filter such as a number of days and query records the running user can see, not accept an ID the user typed. Service agents add another layer. "If a service agent invokes the action, the identity of the agent is used to execute the action," and private service-agent actions must require a verified customer identity and scope data with VerifiedCustomerId, per the same page. An action that reads UserInfo.getUserId() to find "my" records belongs in the employee-facing class, because a service agent runs it as the agent user.

Prompts have their own checklist. "Prompts in your managed package must not ask users for authentication tokens," and they must "guard against prompt-injection attacks," per Secure Your Agentforce Prompts. Store prompts in prompt templates, protected custom settings or protected custom metadata, never in plain Apex strings.

Timing follows the normal review. Salesforce's How the AgentExchange Security Review Works estimates 1 to 2 weeks for the readiness check and 3 to 4 weeks for the first security test. Each resubmission adds 2 to 3 weeks, and Salesforce notes "the time frames are estimates." Paid solutions pay a review fee on every attempt, and "if you plan to distribute your solution for free, you don't pay the fee." Our Salesforce security review checklist covers the packaged Apex checks that apply to action code.

Mistakes that break an Agentforce package at install or review

Most of these come straight from Salesforce's packaging considerations, and each one shows up only after you create a package version or install it in a test org.

• Packaging a prompt template with no published version. "Any installation or upgrade fails because of an empty template." Drafts can go in the package but aren't installed in customer orgs.
• Changing prompt template inputs between versions. Without the right setting, installation fails with "This app can't be upgraded," per the prompt template considerations.
• Installing into an org without generative AI. "Einstein Generative AI must be activated for installation of packages with Prompt templates otherwise installation fails." Put that in your listing's requirements.
• Expecting retrievers to ship. Data Search and Data Graph retrievers "aren't included in packages" and go in a Data 360 data kit instead.
• Building the agent in Agent Script. It works in your org, and then sf agent generate template can't produce a packageable template from it.
• Leaving actions out of the Asset Library. Packaged actions and subagents must be there first.
• Overloading one subagent. Salesforce recommends "no more than 10 actions to a subagent, and 10 subagents to an agent" for best performance, per Agentforce considerations. Split by what the customer asks for, not by how your code is organized.
• Non-global Apex. An action class that is public works in your scratch org and fails as a packaged action.

Frequently Asked Questions

Can you package Agentforce components in a 1GP managed package?

Yes. Salesforce lists agent actions, topics, prompt templates and agent templates as available in managed 2GP and managed 1GP. 1GP needs a Partner Support case to provision Agentforce Extensibility for ISVs in an Environment Hub org, and the 1GP access page doesn't list agent templates, so confirm those in the case.

Can an ISV package a whole Agentforce agent?

No. Agents (Bot and BotVersion) aren't packageable. You package an agent template generated with sf agent generate template, and the customer creates an agent from it after install.

Can customers edit my packaged prompt templates?

Not directly. They can clone any packaged template, and they can create an override version only if you marked the template overridable.

How many actions should one subagent have?

Salesforce recommends no more than 10 actions per subagent and 10 subagents per agent for best performance. Fewer, clearly described actions make the agent's choice easier.

Can Appnigma build our Agentforce components and managed package?

Appnigma's marketplace apps team builds "a Salesforce managed package or HubSpot app built around your product and customer workflows," including "listing preparation" and "Salesforce security review preparation and responses." The agent components ship inside that package.

About the author

Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.

Related Articles

• What Changed When AppExchange Became AgentExchange
• How ISVs Can Embed Agentforce 360 in Their Products
• Selling Through the AgentExchange Go-to-Market App
• 1GP to 2GP Managed Package Migration
• Salesforce Security Review Checklist
• Salesforce MCP Server, the Three Options Compared

Sources

1. Salesforce Developers, Package Agentforce Metadata Components
2. Salesforce Developers, Develop and Package Agent Templates Using Scratch Orgs
3. Salesforce Developers, Components Available in Second-Generation Managed Packages
4. Salesforce Developers, Get Access to Agentforce in Your 1GP Packaging Org
5. Salesforce Developers, Get Access to Scratch Orgs That Have Agentforce
6. Salesforce Developers, Get Started with Agent Script
7. Salesforce Developers, Build and Enhance Agentforce Actions
8. Salesforce Help, Create a Custom Agent Action
9. Salesforce Help, Packaging Considerations for Prompt Templates
10. Salesforce Help, Considerations for Agents
11. Salesforce Developers, Secure Your Agentforce Custom Actions
12. Salesforce Developers, Secure Your Agentforce Prompts
13. Salesforce Developers, How the AgentExchange Security Review Works
14. Salesforce Developers, MCP for Agentforce Metadata in Managed Packages
15. Salesforce Developers, Find PreBuilt Agentforce Assets on AgentExchange