---
sourceDocument: Australia Governance, Risk, and Compliance
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/governance-risk-compliance

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Governance, Risk, and Compliance

ft:clusterId :

    - grc

bundleId :

    - grc

workflow :

    - Technology


---

# Using nested plans

# Using nested plans {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 7 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Using nested plans

Starting with the Yokohama release, ServiceNow introduces enhanced nested plan capabilities within events to streamline plan management and improve system performance.
This feature allows automatic creation of multi-level plan hierarchies within an event, reducing manual effort and enabling better control of plan dependencies and recovery tasks.
Show full answer Show less  
A system property controls the depth of plan activation levels, supporting up to 10 levels, which enhances planning flexibility and visibility into complex recovery scenarios.

## Key Features

* **Activated Plan Levels Control:** The `snrecovery.maxactivatedplanlevels` system property defines how many levels of related plans are automatically activated within an event, from only manually added plans (level 1) up to 10 nested levels.
* **Plan Associations:** Plans added manually to an event are called primary activated plans. Plans associated with recovery tasks become child plans, automatically nested under the primary plan. Plans without task associations are related plans but not child plans.
* **Event Task Views and Navigation:** Event tasks can be viewed in list, hierarchical, or full-page views, facilitating easy navigation and understanding of plan dependencies and task hierarchies. The list view allows editing, while the hierarchical view is read-only for visualizing dependencies.
* **Cross-Plan Dependencies:** You can configure dependencies between first-level activated plans and their tasks, ensuring proper execution order. Child plan tasks inherit dependencies automatically from their parent plan's recovery tasks and cannot be manually configured.
* **Task Order Refresh:** The `snrecovery.synctaskordercalculationlimit` property controls asynchronous recalculation of event task order when dependencies change, improving performance when dealing with large numbers of tasks.
* **Automatic Nested Plan Creation Process:** Upon adding a primary plan to an event, related plans and their hierarchies are automatically created as related or child plans based on task associations, with associated event assets and tasks generated accordingly.

## Practical Benefits for ServiceNow Customers

* Automates complex multi-level plan creation within events, reducing manual configuration and potential errors.
* Improves visibility into plan hierarchies and dependencies through flexible viewing options, enabling better management of recovery efforts.
* Supports configuration of cross-plan task dependencies to enforce correct execution sequences across related plans.
* Enhances performance by controlling plan activation depth and asynchronous task order recalculations for large-scale events.
* Facilitates effective recovery management by clearly identifying child plans associated with recovery tasks and their triggers.  
Configure a system property to control activated plan levels in an event. The system automatically creates nested plans within an event, reducing the manual effort of adding plans and improving system performance. You can also
add dependencies between multiple activated plans by updating the Dependencies field in the event tasks.

## Changes in the plans and events {#creating-nested-plan-in-event__section_dz4_qq1_zdc}

Beginning with the Yokohama release, new changes in the plans and events focus on the planning phase and the creation of related plans.  

Associating related plans with recovery tasks

:   You can now associate related plans with recovery tasks, helping you identify and manage plan triggers during recovery.

    A new field, Is associated to task, has been added to the Related Plans table.
    If a related plan is associated with a recovery task, the field is set to True. If it is not associated, the field is set to False.  
    Note:  
    When a related plan listed in the Related plans tab is associated with a recovery task, it is created as a child plan in the event. If not associated with any task, it is created as a related plan but not as a child plan.

## Adding a plan to the event {#creating-nested-plan-in-event__section_epc_xfd_12c}

When a plan is added to an event, its related plans and their entire hierarchy are included. Plans manually added to an event are called primary activated plans.
Plans without task associations are called related plans. Plans associated with recovery tasks are called child plans.

## Using a hierarchy of the plans {#creating-nested-plan-in-event__section_g4r_5q1_zdc}

Previously, only the primary plan and its directly related plans were included in an event. With the Yokohama release, you can set the sn_recovery.max_activated_plan_levels property to control the depth of activated plans in events, up to 10 levels.  

Resetting the property for activated plan levels
:   You can customize the sn_recovery.max_activated_plan_levels property as shown in the examples to control the levels of activated plans that are created in an event.

    * Set the property to 1 to create only the plans added manually.
    * Set the property to 2 to create only the primary plan and its first-level related plans.
    {#creating-nested-plan-in-event__ul_bth_n2b_b2c}

## Sample use case for a multi-level plan {#creating-nested-plan-in-event__section_mvk_wrt_12c}

You can add a multi-level hierarchical plan to an event. Consider the use case where the system property is configured and a few related plans have
recovery tasks associated with them. An event is created where the related plans are added to the event.

The primary plan, Plan 1, has Plan 2 and Plan 3 as related plans. Plan 1 includes three recovery tasks: Task 1, Task 2,
and Task 3. Task 2 has Plan 2 as a related plan.

Similarly, Plan 2 has three recovery tasks: Task 1, Task 2, Task 3. Plan 1 triggers Plan 2, and Plan 2 triggers Plan 4 as shown in the example.

Previously, when a primary plan (Plan 1) was included in an event, only first-level related plans (Plan 2, Plan 3) were added. Deeper levels, like Plan 4, were not included. With the nested plan functionality, plans up to
10 levels deep, including Plan 4, can be added to the hierarchy.

When you create an event and add Plan 1, its related plans, assets, and tasks are automatically included. Selecting the View progress
button opens the Progress tracker window. It shows the progress and status of adding plans, assets, tasks, and related plans, and the steps and status of the background process.

Once all processes are completed, a message prompts you to refresh the page to see the latest updates. You can close the message and then view the created plans and event tasks.

As shown in the example, Plan 1 is the
primary plan. Plan 3 is marked as a related plan of Plan 1 because it is not associated with any recovery task. Plan 2 and Plan 4 are child plans because they are associated with recovery tasks.

Event tasks: Event tasks are shown in the list view by default. Switch to the hierarchical view to display the hierarchy, with primary and related plans at the top level.

The example illustrates the hierarchy of event tasks and plans, with the primary plan (ACP0010118) and related plan (ACP0010119) at the top level.

* Plan 1 (ACP0010118) has three event tasks. The second event task (EVNTSK0010321) triggers Plan 2 (ACP0010120), and another event task (EVNTSK0010324) triggers Plan 4.
* Plan 3 (ACP0010119) has no related activated plan.
* Two child plans (ACP0010120 and ACP0010121) are shown at child levels.

{#creating-nested-plan-in-event__ul_dxx_4fn_b2c}

## Navigating between the list view, hierarchical view, and full page view {#creating-nested-plan-in-event__section_fch_j3d_12c}

While working on event tasks, you can navigate between the list view, hierarchical view, and full page view.

List view
:   Arranges event tasks in a list format, making it easy to read and quickly understand the hierarchy. It helps you to scan and find specific information without sifting through lengthy text.

Hierarchical view
:   Visualizes plan dependencies and the order of event tasks. By default, the system shows only primary and related plans in the list view. Switch to the hierarchical view to see the full plan hierarchy.  
    Note:  
    You can edit event task and plan information in the list view, but the hierarchical view is read-only. The Work-breakdown structure (WBS) arranges tasks based on their dependencies. For an activated plan, the WBS order is calculated
    considering both event task and plan dependencies.

Full page view
:   Allows you to see more tasks at once, providing a comprehensive overview of the plan hierarchy and tasks. You can switch between the list, hierarchical, or full-page views.

To return to the original record, select the Back to record button.

## Records per level {#creating-nested-plan-in-event__section_sbt_xq1_zdc}

UI navigation
:   By default, only 10 plans are shown at the first level. If there are more, select the Show more button to display additional records. For example, if there are 100 plans, only 10 are shown initially, and
    selecting Show more loads the next set.

## Configuring cross-plan dependencies {#creating-nested-plan-in-event__section_b4h_bjd_12c}

You can configure cross-plan dependencies by updating the Dependencies field as shown in the example.  
Note:  
You can only add dependencies between first-level activated plans.

The example shows an activated plan (ACP0010119) that depends on another activated plan (ACP0010118). Similarly, an event task (EVNTSK0010326) can start only after its dependent task (EVNTSK0010322) is completed.  
Note:  
An event task from a primary or related plan can be associated as a dependency with an event task from the same or another primary or related plan. An event task from a child plan can only be associated as a dependency within the same child plan.

Dependencies for a child plan's event tasks aren't configured manually. During the nested plan process, the child plan inherits matching dependencies from the direct parent plan's recovery tasks.
These dependencies are carried forward automatically into the child plan's event tasks.

Whenever any event task is updated, as shown in the example, a message indicates that the event tasks have
been updated. Selecting Refresh loads the updated data.

You
can add task dependencies in primary and related plans, but not in child plans. For an event task in a child plan, dependencies can only be selected from the same child plan. For example, in Plan 4, task 3 (EVNTSK0010331) depends on
tasks (EVNTSK0010329 and EVNTSK0010330) within the same child plan.

When adding task dependencies in primary and related plans, only tasks from other primary or related plans are available for selection in the Dependencies field.

## Configuring the property to refresh the event task order {#creating-nested-plan-in-event__section_tyk_151_zdc}

Whenever task dependencies are updated, the event task order is updated. If more than 500 event tasks are affected, the order is calculated asynchronously. The sn_recovery.sync_task_order_calculation_limit
property sets the limit for asynchronous calculation to 500 tasks by default. When the task count exceeds this limit and dependencies are updated, the task order calculation becomes asynchronous. A Refresh tasks order button appears in the event, event task, and activated plan. Selecting this button manually refreshes the event task order.

## Process of creating a nested plan {#creating-nested-plan-in-event__section_wby_nzd_12c}

Previously, related plans were created only for primary activated plans. Starting with the Yokohama release, related activated plans can be created from an event task for all activated plan types. An example of creating a nested plan is shown in the diagram.

Follow these steps to create a nested plan:

1. Create an event.
2. Add a plan to the event. An activated plan is created with the plan type set as primary.
3. An event is triggered to create related plans. If the plan has related plans without task associations and the plan level is below the default property value, an activated plan is created as a related plan.
4. An event is created to generate one or more event assets.
5. After the assets are created, an event is triggered to create event tasks.
6. If the event task has a related plan and its level is below the property-defined level, an activated plan is created as a child plan.
7. After the child plan's event tasks are created, the system checks the direct parent plan's recovery task dependencies. Any matching dependencies are carried forward into the corresponding event tasks of the child plan.
{#creating-nested-plan-in-event__ol_uj5_d4b_b2c}