Appnigma

Building Agentforce Components for AgentExchange (Actions, Topics, Prompt Templates, Agent Templates)

agentforce

Jun 10, 2026

9 min read

Building Agentforce Components for AgentExchange (Actions, Topics, Prompt Templates, Agent Templates)

Updated June 11, 2026 by Sunny Chauhan, Salesforce Platform Developer II.

Agentforce introduced four new component types ISVs can package and ship on AgentExchange: Actions, Topics, Prompt Templates, and Agent Templates. Each one does a specific job in the agent stack. Most blog coverage treats them as one blob. They're not. If you build an Action when you needed a Topic, your customer's agent invokes nothing.

Pro Tip

TL;DR - Action: a callable unit of logic the agent invokes (Apex method, Flow, REST callout). - Topic: a named capability area that groups Actions and routes user intent ("close the deal," "summarize the meeting"). - Prompt Template: a structured prompt the agent uses to call Actions with grounding instructions and variable substitution. - Agent Template: a shippable agent that bundles Topics, Actions, Prompt Templates, and a personality definition. - All four are packageable inside 2GP Managed Packages; legacy 1GP doesn't support them.

The four components, plainly

Each one solves a different problem. Build them in this order.

Action: the verb

An Action is a single unit of executable logic the agent can invoke. Three backing types are supported.

Apex Actions: invocable Apex methods (annotated @InvocableMethod) — best for complex logic → Flow Actions: autolaunched flows or screen flows — best for declarative logic → External Actions: REST callouts to external systems — best for cross-system orchestration

Examples for a sales product: summarizeMeeting, getDealRiskScore, draftFollowUpEmail. Each is one Action with one job.

Pro Tip

When I see ISVs struggle with Agentforce, it's almost always at the Action layer: too many tiny Actions that confuse the agent's routing, or one giant Action that the agent can't reason about.

Topic: the noun

A Topic is a named capability area that groups one or more Actions and helps the agent route user intent. Topics are what the agent matches against when a customer asks a question.

A meeting-intelligence ISV might define Topics like MeetingPreparation, MeetingFollowUp, CallScoring. Each Topic owns a set of Actions and a description that the agent uses to decide whether the Topic applies to the current user query.

The agent's routing logic is: classify intent → match to Topic → call relevant Actions under that Topic.

Prompt Template: the structured ask

A Prompt Template is a reusable prompt structure with variables, grounding instructions, and a defined output shape. Templates make agent behavior consistent and packageable.

Example template for a "summarize meeting" capability:

  • Variables: {!meetingId}, {!userRole}, {!summaryLength}

  • Grounding: pull meeting transcript from MeetingTranscript__c for the given meetingId

  • Instructions: summarize from the perspective of {!userRole}, target length {!summaryLength}

  • Expected output: structured response with key points, action items, sentiment

Prompt Templates ship as metadata in your package. Customers can override them in their org if they want a custom prompt, but the default ships with the package.

Agent Template: the assembled product

An Agent Template is the top-level shippable agent. It bundles Topics, Actions, Prompt Templates, and an agent personality definition into a single installable unit. When a customer installs your AgentExchange listing, they get the Agent Template plus the Topics and Actions under it.

Think of it as: a 2GP Managed Package ships your data model and Apex; the Agent Template ships the agent personality, the Topics it owns, and the Prompt Templates it uses. Together they form one product.

The build order that actually works

I've watched ISVs try every order. This is the one that doesn't generate rework.

1/ List your product's existing capabilities as verbs. "Score a deal." "Summarize a meeting." "Draft a follow-up." These become candidate Actions. 2/ Map each verb to its backing implementation. Apex method, Flow, REST callout. Note which already exist in your codebase. 3/ Group verbs into customer-meaningful Topics. Don't group by implementation; group by what the customer would naturally ask for. "Meeting Preparation" makes sense to a customer; "Apex Method Group 3" does not. 4/ Implement Actions for each verb, wrapping your existing logic in the appropriate Action type. 5/ Write Prompt Templates for the Topics, including grounding instructions and expected output shape. 6/ Assemble the Agent Template: Topics + Actions + Prompt Templates + agent personality (tone, default behaviors, escalation rules). 7/ Add everything to `sfdx-project.json` and your 2GP package. 8/ Test in a scratch org with Agentforce enabled before submitting for Security Review.

Real-world scenario: revenue intelligence Agent Template

A revenue intelligence ISV (analogous to Avoma or Gong) wants to ship an Agent Template that lets customer reps interact with meeting data through their Agentforce agent.

Actions (4):

  • summarizeMeeting(meetingId, summaryLength) — Apex, calls existing summary engine

  • extractActionItems(meetingId) — Apex, calls existing extraction logic

  • scoreCall(meetingId) — Apex, calls existing scoring model

  • draftFollowUp(meetingId, tone) — Apex, calls existing drafting service

Topics (2):

  • MeetingIntelligence — owns summarizeMeeting, extractActionItems, scoreCall

  • MeetingFollowUp — owns draftFollowUp

Prompt Templates (4):

  • One per Action, with appropriate grounding and output shape

Agent Template (1):

  • "Revenue Intelligence Agent" — personality: concise, sales-focused; defaults to summarizeMeeting when the user mentions a recent meeting

This bundles into one 2GP package and ships on AgentExchange. The customer installs once, configures their agent, and the agent now has revenue-intelligence capability invocable from any conversation.

Packaging the components in 2GP

Agentforce components live alongside your other metadata in the force-app directory of your SFDX project. The Salesforce CLI handles them automatically when you run sf package version create.

``bash # After adding Agentforce components to your force-app directory: sf package version create --package "MyAgentProduct" --installation-key-bypass --wait 30 ``

The CLI bundles Topics, Actions, Prompt Templates, and the Agent Template into the package version. Inspect the resulting package version to confirm Agentforce metadata is included:

``bash sf package version report --package "MyAgentProduct@1.0.0-1" ``

Then promote and submit for review the standard way.

Pre-flight checklist before shipping agent components

  • [ ] All Actions tested independently end-to-end → Yes / No

  • [ ] Topic descriptions clearly map to customer intent → Yes / No

  • [ ] Prompt Templates tested for output consistency → Yes / No

  • [ ] Agent Template assembled and tested in scratch org → Yes / No

  • [ ] CRUD/FLS enforced on all Action-backing Apex → Yes / No

  • [ ] Sharing rules respected (with sharing) on Apex Actions → Yes / No

  • [ ] Sensitive data not logged by default in Action implementations → Yes / No

  • [ ] Agent personality and escalation rules defined → Yes / No

Common mistakes

I've seen these enough times to call them patterns.

Too many Actions. Twenty tiny Actions confuse the agent. Aim for 5 to 10 well-scoped Actions per Topic. → Topics named like code. A Topic named "DataExtractionService" tells the agent nothing about user intent. Name Topics like a customer would describe the capability. → Prompt Templates without grounding. A template that doesn't specify where to pull data from will hallucinate. Always specify the source object and filter. → One giant Agent Template. If your product has distinct capability areas, ship multiple Agent Templates (one for sales, one for support) rather than one bloated agent. → Skipping CRUD/FLS on Action-backing Apex. The Security Review catches this; it's the top failure cause across all package types.

Frequently Asked Questions

What are the four Agentforce component types ISVs can package?

Actions (callable units of logic), Topics (named capability areas grouping Actions), Prompt Templates (structured prompts with grounding), and Agent Templates (shippable agents bundling Topics, Actions, and Prompt Templates) (Salesforce Newsroom, June 2026).

Do I need to use all four component types?

No. The minimum viable agent ships at least one Action (the verb the agent invokes) and at least one Topic (the capability area). Prompt Templates and Agent Templates become important as your product matures and you want consistent agent behavior across customers.

Can I ship Agentforce components in a 1GP Managed Package?

No. Agentforce metadata types require 2GP. Migrate existing 1GP packages before adding Agentforce capabilities.

How do customers customize my shipped Agent Template?

Customers can override Prompt Templates, add their own Actions to your Topics, or build their own agents that invoke your Actions individually. Your Agent Template ships as a default; customer customization happens on top.

Does the Security Review treat Agentforce components differently?

The review process is the same ($999 per submission for paid apps, 4 to 5 weeks officially). The reviewer checks Action-backing Apex for CRUD/FLS, sharing, and injection safety the same way they check any packaged Apex. Prompt Templates and Topic descriptions are reviewed for content but don't add a separate review step.

What's the difference between an Action and a Flow Action?

"Action" is the general term for a callable unit of agent logic. Flow Action is one of the three backing implementations (alongside Apex Actions and External Actions). Use Flow Actions when the logic is declarative and would benefit from being built in Flow Builder; use Apex Actions for complex logic; use External Actions for cross-system orchestration.

About the author

Sunny Chauhan is the founder and CEO of Appnigma AI, a no-code platform that generates Salesforce AppExchange-ready Managed Packages and Agentforce components from natural-language prompts. He holds Salesforce certifications in Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate. Since launching Appnigma in 2024, his team has helped B2B SaaS companies including Warmly, Hyperbound, Pylon, Seam AI, and Avoma ship native Managed Packages.

Originally published June 11, 2026. Last reviewed June 11, 2026. Component definitions verified against the Salesforce June 2026 Agentforce 360 for builders announcement, the Salesforce 2GP Developer Guide v66.0 (Spring '26), and AgentExchange Partner Community guidance current as of the published date.

Sources

1/ Salesforce Newsroom, Opening Agentforce 360 to Builders, June 2026 2/ Salesforce 2GP Developer Guide v66.0 (Spring '26) 3/ Salesforce Developers, Top 20 Vulnerabilities in the AppExchange Security Review, 2023 4/ Cyntexa, AgentExchange Trends 2026

What's the smallest scoped Action you'd want to ship as your agent's first capability?

Ready to transform your Salesforce experience?

Start exploring the Salesforce Exchange today and discover apps that can take your CRM efficiency to the next level.

decorative section tag

Blog and News

Our Recent Updates