Banks run on repeating processes. Opening a new account triggers a KYC checklist. A high-risk client triggers enhanced due diligence. A wealth client triggers a periodic suitability review. A mortgage application triggers a document-collection sequence. Each process has the same shape every time: a list of steps, in a sequence, with deadlines, owners, and dependencies.
Action Plans is the Financial Services Cloud (FSC) feature for templating these processes. The configuration is straightforward. The hard part is library governance: keeping the templates clean as the business adds new workflows year after year.
What Action Plans give you
An Action Plan Template defines:
- A list of tasks. Each task is 1 step in the workflow, with a description, an assigned role, a duration, and an optional dependency on previous tasks.
- A target object. The object the plan attaches to. Person Account for client-level workflows. Financial Account for account-level workflows. Lead, Opportunity, or Case for sales and service workflows.
- Skip rules. Conditions that skip certain tasks based on the target record's attributes. A standard KYC plan might skip the enhanced-due-diligence tasks for low-risk clients.
- Work-day calendar. A calendar that defines which days count toward task deadlines. Public holidays and weekends do not count, so a 5-business-day task does not expire over a holiday weekend.
When a plan template gets applied to a target record, FSC instantiates the tasks. Each task appears in the assigned role's queue. As tasks get completed, dependent tasks unlock. The plan progresses until all tasks are done.
The work-day calendar is the FSC-specific differentiator. Vanilla Salesforce tasks count every day. FSC's calendar-aware deadlines reflect how banks actually work: a 5-day task is 5 business days, not 5 calendar days.
The KYC use case
The single most common Action Plan use case across FSC engagements: KYC.
A standard new-client KYC plan looks something like this:
- Capture identity documents (1 business day, client-facing role).
- Run sanctions screening (4 business hours, compliance role).
- Run PEP screening (4 business hours, compliance role).
- Verify documents (1 business day, operations role).
- Assign risk rating (1 business day, compliance role).
- Conditional: enhanced due diligence if risk is high (5 business days, compliance senior role).
- Approve customer for onboarding (1 business day, manager role).
- Open initial account (2 business days, operations role).
- Trigger welcome workflow (immediate, automated).
Each task is owned, deadlined, and visible to compliance dashboards. The plan instance shows the bank exactly which customers are stuck where. Compliance officers see their queue across all in-flight plans. Audit teams pull plan-completion reports as part of regulatory submissions.
Periodic review and life-event plans
Two other Action Plan use cases that scale well on FSC:
Periodic suitability review. Wealth clients get an annual review of their portfolio against their stated goals and risk tolerance. The plan template covers the data preparation, the advisor-meeting scheduling, the review documentation, and any portfolio rebalancing the meeting generates. The plan auto-triggers on the annual anniversary of the client's onboarding.
Life-event follow-up. When a Life Event of a certain type gets logged, the matching Action Plan template instantiates. A Birth-of-Child event triggers an education-planning conversation plan. A Retirement event triggers an income-planning plan. A Home Purchase event triggers a mortgage-and-insurance-review plan. The plans turn Life Events from data into action.
Both patterns rely on the plan templates being maintained. The maintenance discipline is what separates Action Plans as a strategic surface from Action Plans as a graveyard of stale workflows.
Library governance
The library-of-templates problem hits every FSC implementation in year two. The first year ships with a dozen Action Plan templates. By year two, the library has fifty. By year three, nobody knows which templates are current.
Three patterns that prevent the sprawl:
Naming convention. Every template carries a structured name: line-of-business, workflow type, version. WEALTH-KYC-V3 is a wealth-line KYC template at version 3. RETAIL-ONBOARD-V2 is a retail-line onboarding template at version 2. The convention surfaces stale templates and supports clean filtering.
Ownership. Every template has a named owner (a business-process role, not an individual). The owner is responsible for keeping the template current with regulation, product changes, and business updates. Templates without an active owner get archived.
Annual review. The library gets reviewed annually. Templates that have not been instantiated in 12 months get archived. Templates with active in-flight plans get audited for whether the template still matches current practice.
Without these patterns, the library grows monotonically. Each grown library template is a half-broken business process that someone has to clean up later.
The condition-and-branch design
Action Plan templates support skip rules but not full branching. A skip rule says "skip this task if this condition is true". It does not say "if condition is true, run path A; otherwise run path B".
The branching limitation forces design decisions. Two patterns to handle it:
Conservative skip rules. Most workflow variation is binary: enhanced due diligence either applies or does not. A skip rule on the EDD tasks handles this cleanly.
Separate templates for fundamentally different paths. When the workflow truly diverges (a corporate-banking onboarding plan versus a retail-banking onboarding plan), two separate templates work better than one template with extensive skip rules.
The boundary between "skippable variation" and "fundamentally different path" is judgment. A useful heuristic: if more than 30% of the tasks differ between two scenarios, they should be separate templates.
Reporting and KPI surfaces
Action Plans produce three KPI surfaces banks use to manage compliance and operations performance:
Plan-completion time. The elapsed time from plan start to plan complete. Compared against the template's defined duration. Plans that consistently exceed the defined duration signal a process problem, a staffing problem, or an unrealistic template.
Plan-completion rate. The percentage of started plans that reach Complete versus those that stall. Stalled plans accumulate when a task owner leaves the bank, when a customer goes unresponsive, or when a downstream dependency breaks. The metric flags operational health.
Task-level bottleneck identification. Which task type sits in the queue longest. Often the bottleneck is one role (a compliance senior reviewer with too small a team) or 1 step (a document verification that depends on a third party). The task-level view targets the fix.
These KPIs roll up to operations dashboards. They drive staffing decisions, process redesign, and vendor management.
The advisor-experience question
Action Plans expose to clients indirectly. The advisor sees the plan in their queue. The client sees the outcomes: documents arriving, accounts opening, reviews scheduled.
The advisor experience question: how does the plan show up in the advisor's day? Two patterns work:
Embedded in the Wealth Console. The plan tasks appear as a panel inside the Wealth Console's contextual-actions area when the client's record is open. The advisor sees plan progress without leaving the client view.
Centralised task queue. All in-flight plan tasks across the advisor's book appear in one queue, sorted by due date and priority. The advisor processes the queue first thing each morning, then jumps to specific clients as needed.
Most FSC implementations end up offering both views. The choice between them is a workflow preference, not a technical constraint.
Designing the Action Plan library for an FSC implementation? Sapota's Salesforce team, certified on Financial Services Cloud Accredited Professional (AP-208), runs Action Plan architecture, library governance, and KPI reporting on every FSC engagement. Get in touch ->
See our Salesforce service page for the team and credentials.
