Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionaryAAction Plan
AutomationIntermediate

Action Plan

An Action Plan is a Salesforce object that bundles a set of related Tasks under a single parent record (an Account, Opportunity, Lead, Case, or one of the Industries-specific objects like Financial Account, Insurance Policy, or Visit) so the work can be tracked and reported as one engagement.

§ 01

Definition

An Action Plan is a Salesforce object that bundles a set of related Tasks under a single parent record (an Account, Opportunity, Lead, Case, or one of the Industries-specific objects like Financial Account, Insurance Policy, or Visit) so the work can be tracked and reported as one engagement. Each Task in the Action Plan carries a due date offset from a starting point, an owner, a priority, and a status. The pattern is born from the realisation that any meaningful interaction with a customer is not a single Task but a sequence: send the welcome packet, schedule the kickoff call, confirm the verification documents, deliver the first review. Wiring those steps together as separate Tasks loses the connection between them. The Action Plan keeps the sequence visible, owned, and reportable.

Action Plans are produced from Action Plan Templates. The template defines the standard set of Tasks and their offsets. Applying the template instantiates a real Action Plan with real Task records assigned to real people. The feature originates in Financial Services Cloud and spread to Public Sector Solutions, Health Cloud, and broader Sales Cloud via Action Plans for Sales. The mechanics are largely the same across editions, with differences mainly in which standard objects are supported as the Action Plan target.

§ 02

Why Action Plans exist and how they differ from a loose Task list

Tasks under an Action Plan share a parent and a context

A regular Task in Salesforce can live anywhere. The WhatId points at one parent record. The Action Plan adds a layer above the Task: every step in a plan belongs to the same Action Plan, which itself belongs to a single business engagement. That extra parent is what lets a sales manager ask which steps in the onboarding plan for ACME are overdue, rather than digging through a flat list of Tasks per owner.

Template-driven plans versus ad hoc Tasks

Action Plans are almost always produced from Action Plan Templates. The template captures the canonical sequence and gets refined by the team over time. Applying it instantiates fresh Task records with offsets computed from a start date. Creating an Action Plan without a template is supported but rare. Most of the operational value comes from the template, since the template is the documented playbook.

Where Action Plans show up across clouds

Action Plans launched in Financial Services Cloud as a way to model client onboarding and review processes. They appear in Health Cloud for care plans, in Public Sector Solutions for case workflows, in Salesforce Industries broadly, and in Sales Cloud as Action Plans for Sales. The object names and feature surface vary, but the core idea is the same: a parent record, a set of Tasks, a template that generated them.

Standard fields and lifecycle

An Action Plan typically carries Name, Target Record, Action Plan Template, Start Date, Status, and Owner. The Tasks under it carry the standard Task fields plus a reference back to the plan. Plans usually flow through Not Started, In Progress, Completed, and Cancelled. Completing every Task does not automatically mark the plan complete; that status is updated either manually or by a Flow that watches Task completion.

Reporting on engagement progress

The reporting story is the main reason Action Plans matter. A custom report type that joins Action Plan to Task gives leadership a clean view of which onboardings are on track and which are stuck. Dashboards typically show plans by status, overdue steps, and median time to completion by template. Without the Action Plan parent, those reports would have to filter Tasks heuristically by subject pattern.

Permissions and licence implications

Action Plans require the right managed package or feature licence depending on the cloud. Financial Services Cloud, Health Cloud, Public Sector Solutions, and Salesforce Industries each ship the feature with their own permission set licences and permission sets. Sales Cloud Action Plans for Sales is a separate add-on. Assign the relevant permission set to every user who should create or work the plans before turning the feature on.

Automating Action Plan creation

The most common automation is Flow-triggered creation: when an Opportunity moves to a specific stage, create an Action Plan from a named template against that Opportunity, with the template start date set to the stage-entry date. The Apex action Create Action Plan, or the Industries Flow Action, is the usual call. Triggers can also assign the plan owner based on the parent record's owner or a region-specific routing rule.

Common pitfalls

The biggest pitfall is creating Action Plans without a template when the team has a stable process. Without a template the data is inconsistent across users and reporting falls apart. The second pitfall is forgetting that Tasks under a plan still respect Task sharing and ownership rules, so reassigning the plan does not automatically reassign the Tasks unless the automation does so explicitly.

§ 03

How to apply an Action Plan to a record

Once the Action Plan Template exists and the feature is enabled for the right users, applying a plan is a few clicks from the parent record. Most of the design effort sits in the template, not the Action Plan itself.

  1. Open the parent record

    Navigate to the Account, Opportunity, Case, or other supported record where the plan should run.

  2. Click New Action Plan

    Use the New Action Plan quick action or related list button on the parent record. The button appears only if the user has the right permission set assigned.

  3. Pick the Action Plan Template

    Select the template that matches the engagement, for example Client Onboarding or Renewal Review. The template determines which Tasks will be created and their relative due dates.

  4. Set the start date and owners

    Choose a start date. Salesforce computes every Task's due date by adding the template offset to this date. Optionally reassign individual Tasks to people other than the defaults defined in the template.

  5. Save and monitor

    Save the plan. Salesforce creates the Tasks and links them to the new Action Plan record. Status updates on Tasks roll up to plan-level dashboards.

Mandatory fields
Target Recordrequired

The parent record (Account, Opportunity, Case, etc.) the plan is attached to.

Action Plan Templaterequired

The template that defines the sequence of Tasks.

Start Daterequired

The anchor date from which every Task offset is calculated.

Ownerrequired

The user responsible for the plan as a whole, separate from individual Task owners.

Namerequired

A human-readable plan name; usually defaults from the template but can be overridden.

Gotchas
  • Completing every Task does not automatically mark the Action Plan as Completed. Build a Flow that watches Task status if the plan-level status should roll up.
  • Reassigning the plan owner does not reassign the individual Task owners. Decide up front whether ownership cascades or stays where the template put it.
  • Action Plans require feature-specific permission sets. Users who do not have the right permission set assigned will not see the New Action Plan button on the parent record.
  • Each cloud (FSC, Health Cloud, Industries, Sales Cloud) has its own Action Plan flavour. Confirm which one is licensed before promising a particular feature behaviour to stakeholders.
§

Trust & references

Sources

Cross-checked against the following references.

Official documentation

Straight from the source - Salesforce's reference material on Action Plan.

Keep learning

Hands-on resources to go deeper on Action Plan.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.

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 in your Salesforce org?

Q2. What type of Salesforce feature is Action Plan?

Q3. Which Salesforce tool has Salesforce recommended as the future of automation?

§

Discussion

Loading…

Loading discussion…