Where do Catalog Tasks come from? (Execution Plans)

When you request an item in the Service Catalog, a Catalog Task (SCTASK) for work is created under the Requested Item (RITM). The Execution Plan determines 'where the work comes from and in what order'. Looking at the Parcel Delivery Plan in the PDI (Zurich / OOTB), three task templates—Prepare parcel, Post parcel, and Confirm receipt—were lined up with orders 100, 200, and 300. After a request is submitted, sc_task records are created based on these templates.

This article is intended for administrators and developers who know the three-tier structure of Request / RITM / Catalog Task but want to verify in the tables 'who creates the Catalog Task and when'. We will examine the three components—the Execution Plan itself (sc_cat_item_delivery_plan), the task templates in the plan (sc_cat_item_delivery_task), and the generated actual records (sc_task)—in order, using PDI measurements.

What you will learn in this article

• That the Execution Plan assigned to an item is the sc_cat_item_delivery_plan table

• That task templates in a plan (sc_cat_item_delivery_task) have an order, duration, and fulfillment group

• That the template (configuration table) and the generated sc_task (work table) have different inheritance sources

• That an Execution Plan can generate records other than sc_task (such as change_task)

• The three active plans in PDI Zurich OOTB and their contents

• List URLs to open when verifying on an actual machine

What is an Execution Plan?

An Execution Plan is a template for procedures that pre-determines 'what work to perform, in what order, and to which group to assign it' when an item is requested. In the ServiceNow interface, it is called an Execution Plan, the table name is sc_cat_item_delivery_plan, and it is also referred to internally as a delivery plan.

On the Catalog Item side, there is a reference field called delivery_plan, labeled 'Execution Plan'. By assigning one Execution Plan to an item, work tasks are generated according to the plan when that item is requested. In PDI Zurich OOTB, there are 196 sc_cat_item records, 64 of which have a delivery_plan set. The remaining 132 have an empty delivery_plan, suggesting that work is generated through means other than Execution Plans, such as Flow Designer (speculation). You can distinguish which method is used for each item by checking whether this delivery_plan field is empty.

The official Service catalog execution plans (Zurich) documentation explains how Execution Plans define the delivery and fulfillment of items.

Execution Plans are templates; Catalog Tasks are actual records

The Execution Plan environment consists of three tables. Since their roles can be confusing, let's first distinguish their positions.

• Execution Plan (sc_cat_item_delivery_plan) ... The core of the Execution Plan. It holds the total duration and the target table for generation.

• Plan Task (sc_cat_item_delivery_task) ... A task template within a plan. Multiple tasks can be attached to a single plan, and they hold an execution order (order), duration (delivery_time), and fulfillment group (group).

• Catalog Task (sc_task) ... The actual work record created after a request is submitted. The number starts with SCTASK, and it is the unit processed by the assignee.

The roles are summarized in the table below.

What is confusing about these three is that Plan Task (template) and Catalog Task (actual record) are separate tables. The template used for configuration is sc_cat_item_delivery_task, while the actual record created for each request is sc_task.

The official Execution plan tasks (Zurich) documentation explains how to define task templates (execution order, duration, group, conditions) linked to a plan.

Templates and actual records have different inheritance sources

Checking the inheritance sources of the three tables reveals a clear distinction between templates and actual records. In the PDI (Zurich / OOTB) checked this time, Execution Plan and Plan Task inherit from Application File, while only sc_task inherits from Task.

The reason for this separation is that execution plans and plan tasks are "configurations (metadata)." Application File tables are configurations transported via update sets, allowing plans created in a development environment to be moved to production. On the other hand, sc_task is operational data that increases with each request, so it inherits from Task, which includes fields like number, State, priority, and assigned to.

The number of unique fields is 12 for Execution Plan, 14 for Plan Task, and 6 for sc_task (sc_task also includes the 70 fields inherited from Task).

Table definitions can be checked at the following URLs (replace <YourInstance> at the beginning with your own instance).

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sc_cat_item_delivery_task^elementISNOTEMPTY

Contents of the Execution Plan form (Parcel Delivery Plan)

When you open the Execution Plan form, you can see the settings for the plan itself and the list of Plan Tasks hanging below it. Let's take the Parcel Delivery Plan from the PDI Zurich OOTB as an example.

The plan itself has "4 Days" for Total delivery time and "Catalog Task [sc_task]" for the Task table. The Task table specifies the destination table for generation; if this is set to sc_task, a Catalog Task will be created after the request is submitted.

The underlying Execution Plan Tasks include Prepare parcel (order 100), Post parcel (order 200), and Confirm receipt (order 300), each with a Delivery time (4 Hours / 1 Day / 3 Days). The order represents the execution sequence, processed from the smallest number.

https://<YourInstance>/sc_cat_item_delivery_plan_list.do?sysparm_query=active=true^ORDERBYname

Fields held by Plan Task

Plan Task contains fields to pre-determine the contents of the generated sc_task. These primarily focus on execution order, duration, and fulfillment group.

There are 53 Plan Tasks in PDI Zurich OOTB, of which 44 have a group (fulfillment group) set, and 0 have an assigned_to (individual) set. OOTB is designed to distribute work to groups rather than individuals. The reason it is group-centric is that at the time a request is received, it is not yet decided who is available, so it is better suited for an operation where the task is placed in a group queue and then picked up by an assignee.

Fields inherited by the sc_task after generation

Plan Tasks also have fields such as instructions, work_notes, and short_description that are copied directly to the generated sc_task. They also have a reference field called sla, which is designed to allow SLA contracts to be assigned in advance at the planning task stage. It is clear that the design is to consolidate information that can be determined before the request is made on the Plan Task side.

The progression of the order is illustrated in the following diagram using the Parcel Delivery Plan.

There are also Plan Tasks that have a condition / condition_script (2 in OOTB), which allows for control to create tasks only when the conditions are met. However, the internal logic at the time of generation is outside the scope of verification.

Generated Catalog Tasks are linked to RITM

An execution plan is just a template. When a request is submitted, sc_tasks are created according to the plan and linked to the requested item (RITM). PDI Zurich OOTB has one Catalog Task (TASK0000001), and opening it revealed the parent RITM.

In this form, the Request item was RITM0000001, the State was Open, and the Short description was "Order from vendor or move from in-stock inventory". There are 6 unique fields for sc_task, 4 of which are references: request_item (→sc_req_item), request (→sc_request), cat_item (→sc_cat_item), and sc_catalog. You can trace which request and which item the generated work belongs to using these references.

In other words, the flow is Execution Plan (template) → Plan Task (each task in the plan) → sc_task (actual work, linked to RITM), through which a request is broken down into concrete tasks.

https://<YourInstance>/sc_task_list.do

Entry point from item to execution plan

An execution plan is only used when assigned to an item. The delivery_plan field (labeled "Execution Plan") of the item (sc_cat_item) is that entry point.

When checking the "Packaging and Shipping" item in PDI Zurich OOTB via REST, the Parcel Delivery Plan was set in the delivery_plan (Execution Plan). In the item form, the specification of the fulfillment method is on the Process Engine tab. When this item is requested, work is generated based on the 3 Plan Tasks of the Parcel Delivery Plan.

Execution plans do not necessarily only generate sc_tasks. Of the 3 active plans checked this time, the Task table for Office Move was change_task. In other words, execution plans can also issue tasks to work tables other than Catalog Task. The breakdown of the 3 items is: DEFAULT (total 2 days, destination sc_task, 2 Plan Tasks), Office Move (total 3 days, destination change_task, 5 Plan Tasks), and Parcel Delivery Plan (total 4 days, destination sc_task, 3 Plan Tasks). It is thought that Office Move chooses change_task because physical work like an office move is already incorporated into the Change management process (speculation).

The official Catalog Task (Zurich, Workflow Activity) explains the settings for creating a Catalog Task from the workflow side. Execution plans and workflows (Flow) both coexist as means of generating work tasks.

Peripheral settings around execution plans

The movement of an Execution Plan does not end with just the fields in the plan and task templates. Business Rules and Notifications are attached to the generated sc_task side.

In terms of scope, the plan/template side (configuration tables) has almost no Business Rules or Notifications, while Business Rules (13), Notifications (4), and UI Actions (4) were concentrated on the sc_task side after generation.

設定の種類（物理テーブル）              紐づくテーブル             件数        ざっくりの役割
---------------------------------------------------------------------------------------------
Business Rules（sys_script）            sc_cat_item_delivery_plan  0           計画本体の保存時処理
Business Rules（sys_script）            sc_cat_item_delivery_task  1           計画タスクの保存時処理
Business Rules（sys_script）            sc_task                    13          生成後の作業の保存時処理
Notifications（sysevent_email_action）  sc_task                    4           作業に関するメール通知
UI Actions（sys_ui_action）             sc_task                    4           作業フォームのボタン
Access Controls（sys_security_acl）     3テーブル合計              12＋16＋22  各テーブルの権限

The reason settings are concentrated on the sc_task side is that notifications to users and operations by assignees occur on the 'actual work record.' Since the templates, i.e., the plan and Plan Task, are static as configurations, they require fewer save-time logics or notifications. On the other hand, Access Controls were set to a certain extent in all three tables: 12 for plans, 16 for plan tasks, and 22 for sc_tasks. While read/update permissions are properly applied to the template tables, we can see a contrast where only dynamic processes like Business Rules and Notifications are concentrated on the sc_task side after generation.

Key points of Execution Plans and Catalog Tasks

• The main body of an Execution Plan assigned to an item is the Execution Plan (sc_cat_item_delivery_plan) which holds the total required time and the destination table (task_table).

• The task template on the plan is the Plan Task (sc_cat_item_delivery_task) which holds the execution order, delivery_time, and group. OOTB is centered on group assignment, and individual assignment was not set.

• The templates (Execution Plan / Plan Task) are Application File inheritance settings, while the generated Catalog Task (sc_task) is a Task inheritance operation, meaning their inheritance sources are different.

• Execution Plans can also set destinations other than sc_task (such as change_task). Of the 3 active items this time, Office Move was a change_task.

• The generated sc_task is linked to the RITM via request_item, allowing you to trace from the request to the work via references.

When investigating an Execution Plan, you can connect 'how a request becomes work' by opening the plan from the item's delivery_plan, and looking at the Execution Plan Tasks (templates) under the plan form and the actually generated sc_task (under RITM) as a set.

Things I noticed while looking at the actual machine

• A total of 15 Execution Plans were registered, but only 3 were active. At first, I thought all registered Execution Plans were in use, but the remaining 12 were disabled definitions, and only a small portion appeared in actual requests. If you feel that an Execution Plan is not working well, it is a good idea to first suspect whether it is active.

• Plan Tasks have not only a condition / condition_script to narrow down work, but also a field called generation_script that allows you to customize the generation logic itself. I checked thinking it must be used somewhere in OOTB, but out of 53 Plan Tasks, none used generation_script. It seems the standard functionality is designed to be completed with just conditions. I understood it as a field prepared as an escape route for expansion, to be used only when the need for customization arises.

If you want to read next

An Execution Plan is one of the fulfillment methods for an item. Flow Designer workflows can also play the same role, and the design of using Flows for new items is increasing. There are three things I want to check next: whether an Execution Plan or a workflow is selected on the item side (specification of the Catalog Item's process engine); how the Plan Task's condition / generation_script works at the time of generation; and how a plan that generates a change_task works. These are beyond the delivery_plan and task_table mentioned in the 'Entrance from Item to Execution Plan' section of this article, and I plan to cover them in a separate article.

Terminology

• PDI: Personal Developer Instance (free instance for verification)

• OOTB: Out of the Box (as initially configured)

• Execution Plan: sc_cat_item_delivery_plan. A template for item work procedures

• Plan Task: sc_cat_item_delivery_task. A template for each task on a plan

• Catalog Task (SCTASK): sc_task. The actual work record generated after a request.

• task_table: The table where the fulfillment plan generates work (e.g., sc_task, change_task).

URL for checking in your own environment

You can open the same screen by adding your instance name to the beginning.

履行計画(active)   : sc_cat_item_delivery_plan_list.do?sysparm_query=active=true^ORDERBYname
計画タスク一覧     : sc_cat_item_delivery_task_list.do?sysparm_query=ORDERBYdelivery_plan^ORDERBYorder
計画タスク定義     : sys_dictionary_list.do?sysparm_query=name=sc_cat_item_delivery_task^elementISNOTEMPTY
Catalog Task一覧   : sc_task_list.do
品目(計画設定あり) : sc_cat_item_list.do?sysparm_query=delivery_planISNOTEMPTY

Related Articles

• ServiceNow Service Catalog Complete Guide: From Request Form to Fulfillment Task — Click here for the full picture from request form to fulfillment task. You can see where Execution Plan and Plan Task fit into that flow.

Verification Scope and Disclaimer

• Scope verified: Inheritance source of 3 tables, number and type of unique fields, Execution Plan configuration (task_table / total_delivery_time / order / delivery_time / group), 3 active plans and their Plan Tasks, sc_cat_item.delivery_plan reference, linkage between generated sc_task and RITM, and the number of peripheral settings for each table. All were obtained from OOTB on a PDI (Zurich / confirmed 2026-06-22).

• Scope not verified (not definitive): Internal runtime logic for how sc_task is generated from a request (which trigger creates how many), behavior of condition / condition_script / generation_script, detailed operation of plans that generate change_task, specific values for sc_task State transitions, and the distinction between using fulfillment plans and Flow Designer workflows (item process engine specification). These will be covered in a separate article.