Most CSM implementations I’ve come across handle task creation in one of two ways: manually, or through a flow that creates tasks. Both of them work, but neither scales well when you have repeatable, structured work happening across dozens or hundreds of cases.
Task Plan Templates exist specifically for this problem. They don’t get much attention in most projects, as they are a fairly new feature introduced in the Zurich release.
What Are Task Plan Templates?
A Task Plan Template in ServiceNow is a predefined structure of records, like cases, case tasks, and child cases that you define once and apply to records when the conditions are right. Each template item can have its own conditions controlling whether it gets created and task dependencies let you link tasks, so they start in the right order, reducing confusion for agents.
Here’s how the data model looks:
- The template lives in
sn_task_plan_template - Template items in
sn_task_plan_template_item - Item-level conditions in
sn_task_plan_template_item_condition
When you apply a template, the API creates the tasks and arranges them in the right order.
Templates can be shared with specific users, groups, or service org members, or marked as global to make them visible to anyone with read access. This matters in larger implementations where you don’t want every team seeing every template.
Who Are Task Plan Templates Built For?
This feature is directly aimed at the FSO vertical under CSM (banking, insurance, and wealth and asset management). These are industries where every stage of a case comes with a specific set of tasks, assigned to specific people, under regulatory pressure to be completed correctly and in order.
For example, in banking, when you are onboarding a commercial account, tasks like creating a legal package, identifying beneficial owners, and verifying business entity information all need to happen at the right stage. In insurance, it can be used in a personal auto claim at FNOL, requesting a police report, collecting accident scene photos, gathering witness statements, multiple personas, working in parallel, all tracked against the same case.
These are not generic use cases – they reflect the kind of structured, compliance-driven work that breaks down quickly when tasks are created manually or buried in a flow that only a developer can change.
That brings up the other point worth highlighting: this feature is explicitly designed to be configured by process owners, not only developers. The template UI sits inside the financial services workspace, and the intent is that business users can update task sequences directly when regulations change or processes shift without raising a change request or touching Flow Designer (assuming the logic for triggering is already in place, see below). That is a meaningful shift from how most task automation works on the platform today.
How Does Invocation Actually Work?
You have two options: manual or automated.
Manual means an agent picks the template from the workspace and applies it themselves. Choose manual when a human should decide which template fits the situation.
Automated means you apply the template using a business rule, for example. (As of the Q1 2026 Store release, Task Plan Templates are not automatically triggered when conditions are met, and they must be manually invoked from the target record.)
The sn_task_plan.TaskPlanExecutionService() API exposes two methods that do the heavy lifting: findMatchingTaskPlanTemplate(current) identifies which templates match the current record, and applyTaskTemplate(sys_id, current) creates the tasks.
A business rule running after insert or update is a clean way to trigger this without any agent involvement. Here’s an example business rule:
- When: after
- Insert: True
- Update: True
- Filter Conditions: Your conditions
(function executeRule(current, previous /null when async/ ) {
var array = new sntaskplan.TaskPlanExecutionService().findMatchingTaskPlanTemplate(current);
var latestRecord = null;
var latestDate = null;
for (var i = 0; i < array.length; i++) {
var currentRecord = array[i];
var currentDate = new GlideDateTime(currentRecord.sysupdatedon);
if (latestDate === null || currentDate.getNumericValue() > latestDate.getNumericValue()) {
latestDate = currentDate;
latestRecord = currentRecord;
}
}
new sntaskplan.TaskPlanExecutionService().applyTaskTemplate(latestRecord.sys_id, current);
})(current, previous);
One thing worth noting: findMatchingTaskPlanTemplate returns an array. If multiple templates match, you need to decide which one to apply. My experience shows it picks the most recently updated one, which is a reasonable default but might not be the right logic for every case. Think about your template naming and conditions carefully, so you don’t end up with ambiguous matches.
Before you automate the trigger, there are a few design questions worth thinking through. What prevents the same template from being applied twice? What happens if your condition is met, something else happens, and then it’s met again?
These are things a business rule alone won’t protect you from, so you need to account for them explicitly, whether that’s a check on existing tasks, a flag on the record, or a condition in the rule itself.
When Does It Make Sense to Use Task Plan Templates?
This feature makes sense when the work is both repeatable and structured. Think insurance claims moving into a new stage, or onboarding cases that always require the same set of subtasks.
It also handles a scenario that flows struggle with cleanly: creating child cases, not just tasks. If the template includes child cases, the API uses the multi-case creation engine to handle those, which means you can model complex hierarchical work without building custom logic.
ServiceNow’s Australia release added two more useful things: task dependencies with controlled sequencing, and the ability to attach document references to template items, which are automatically carried over to the created tasks when the template is applied.
When to Avoid Task Plan Templates
Task Plan Templates are not the right tool when the work is unpredictable. If what needs to happen depends heavily on what an agent discovers during the case, a rigid template creates overhead rather than removing it. Agents end up closing tasks they didn’t actually complete just to move things forward, which affects your reporting.
They’re also not a substitute for a flow when you need conditional branching based on runtime data, integration calls, or dynamic field population. The templates handle structure well, but complex logic still belongs in Flow Designer.
And if cases vary too much, maintaining many templates may cost more time than they save, which leads me to my final point.
Final Thoughts: What to Consider Before You Build
The biggest risk with this feature is having too many templates. It’s easy to end up with twenty templates that are 80% identical because someone created a new one every time there was a slight variation. Before you start building, spend time on your conditions. The item-level conditions let you decide which tasks get created, helping you keep templates simple without losing accuracy.
I would not use this everywhere. But if you’re working in CSM/FSO and your case work is structured and repeatable, this feature solves a real problem with surprisingly little effort.