Action Plan Template
An Action Plan Template is a reusable Salesforce definition that lists the Tasks (or Item Templates) that should run together as one engagement, along with the relative due dates, default owners, and priorities for each step.
Definition
An Action Plan Template is a reusable Salesforce definition that lists the Tasks (or Item Templates) that should run together as one engagement, along with the relative due dates, default owners, and priorities for each step. Applying the template to a parent record (an Account, Opportunity, Case, Financial Account, Insurance Policy, or whichever object is supported by the relevant cloud) creates a fresh Action Plan with real Task records that respect the template's design. Without the template, every team member has to rebuild the same sequence of Tasks from memory on every engagement. With it, the playbook stays in Setup and the operational work stays consistent.
The template is where the real process design happens. Editors choose which Tasks belong, define each Task's offset from the plan start date, assign a default owner (or owner role, like Account Owner or Account Manager), and set per-Task priority and reminder flags. Templates can be cloned for variants, versioned, and shared across business units. They are the artifact that internal trainers, RevOps, and customer success leaders argue about; the resulting Action Plans are simply the realisation of that argument on a specific customer.
How Action Plan Templates capture a repeatable playbook
The fields that drive an Action Plan Template
A template carries Name, Target Object (Account, Opportunity, Lead, Case, etc.), Description, and a set of Item Templates. Each Item Template defines one step: Subject, Days Until Due (offset from plan start date), Priority, Owner Type, Owner, and Status. Some clouds add fields like Reminder, Dependent On (another item, to chain the sequence), and Required.
Owner Type and how assignment actually works
Owner Type is the most-misunderstood field. Options usually include User, Account Owner, Opportunity Owner, Queue, and similar. When the template is applied, Salesforce reads Owner Type and resolves it to a specific user. Picking Account Owner means every Task in the resulting plan goes to whichever user currently owns the parent Account. Picking User and naming a specific person means the Task always goes to that person regardless of who runs the engagement.
Day offsets and the start date arithmetic
Each Item Template stores Days Until Due as an integer offset from the plan's start date. A 0 means due on day one. A 7 means due a week after the plan starts. Negative offsets are usually disallowed; pre-work belongs in a separate plan. Templates that go beyond 90 days tend to misbehave because the plan often outlives the engagement state that triggered it, so the Tasks become stale.
Versioning by clone, not by edit
There is no first-class version field on the standard Action Plan Template object. Most teams handle versioning by cloning the template, suffixing the name with V2 or 2026 Q3, and switching automation to point at the new template. Old plans created from the previous version keep referencing their original template, which preserves audit history.
Templates per target object
Each template is scoped to a single Target Object. A template designed for Accounts cannot be applied to Opportunities, even if the Task list would technically work. To reuse the same playbook against multiple objects, clone the template per Target Object and keep them in sync manually. Some industries solutions support broader Target Object lists; the rest stay strict.
Sharing and permissions
Action Plan Templates respect standard object permissions plus feature-specific permission sets. A user without the relevant Action Plan permission set will not see the template in the picker even if it exists. Some clouds also gate template creation behind Public Sector Solutions, FSC, or Industries permission set licences. Roll out the templates with the permission sets, not after.
Cloning, exporting, and migrating templates
Templates are metadata-backed and can move between sandboxes via change sets or Salesforce DX. Cloning inside the same org is the usual editing path. Migrating to a new org needs the matching feature licences in the target. Treat templates as part of release-managed metadata, not as data, since dev and prod must stay aligned.
Common design pitfalls
Templates either get too generic or too specific. Too generic and every team customises after applying the plan, defeating the point. Too specific and one template multiplies into thirty for every variant. The healthy pattern is one core template per business process plus an explicit short list of variants, with regular pruning of templates nobody applies any more.
How to create an Action Plan Template
Designing a good template is half the work; entering it in Setup is the other half. The list of Tasks usually starts as a spreadsheet co-owned by RevOps and the team that runs the process.
- Open Action Plan Templates
App Launcher, search for Action Plan Templates, open the list view. The page may sit under a feature-specific app like FSC Admin or Industries Setup.
- Create a new template
Click New. Provide Name, Description, and Target Object. Choose the object the template will be applied to (Account, Opportunity, Case, Financial Account, and so on).
- Add Item Templates one by one
For each Task in the playbook, add an Item Template. Enter Subject, Days Until Due, Priority, Owner Type, and Owner. Order them logically; users will see them in the order entered.
- Set Owner Type to a role rather than a person where possible
Prefer Account Owner or Opportunity Owner over a specific user. Roles survive personnel changes; named users do not. Use named users only for steps that always go to a specialist.
- Activate the template and assign permissions
Mark the template Active. Assign the relevant permission set to every user who will create plans from it. Test by applying the template against a sandbox record before going live.
Human-readable template name. Appears in the picker when applying a plan.
The single object the template can be applied to.
Boolean. Only Active templates show in the picker.
The set of Task definitions that make up the plan.
Per-item offset from plan start date.
How each Task should be assigned when the plan is created.
- Templates are scoped to one Target Object. A template for Accounts cannot be applied to Opportunities. Clone per target instead of trying to share.
- There is no in-place versioning. Cloning is the supported pattern. Old plans keep their original template reference even after you stop using the old template for new plans.
- Owner Type User with a named person freezes the assignment, regardless of who runs the engagement. Use role-based options unless the step belongs to a specific specialist by design.
- Inactive templates disappear from pickers but old plans still display their template name. Archiving a template does not retroactively affect history.
Trust & references
Cross-checked against the following references.
- Action Plan TemplatesSalesforce Help
- Create an Action Plan Template in FSCSalesforce Help
Straight from the source - Salesforce's reference material on Action Plan Template.
- Set Up Action PlansSalesforce Help
Hands-on resources to go deeper on Action Plan Template.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. When should you consider using Action Plan Template in your Salesforce org?
Q2. What is the main advantage of using Action Plan Template over writing Apex code?
Q3. Which Salesforce tool has Salesforce recommended as the future of automation?
Discussion
Loading discussion…