---
sourceDocument: Australia Governance, Risk, and Compliance
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/governance-risk-compliance

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Governance, Risk, and Compliance

ft:clusterId :

    - grc

bundleId :

    - grc

workflow :

    - Technology


---

# Add recovery tasks

# Add recovery tasks {#ariaid-title1}

* Release version: Australia
* 
* Updated April 29, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 9 minutes to read

Add a recovery task as part of the planned recovery strategy. You can add one or more recovery tasks for a loss scenario and those recovery tasks are displayed in the loss scenario itself. Automate the recovery tasks in a
plan for a faster recovery.

## Before you begin

Role required: sn_bcm.admin, sn_bcm.program_manager, or sn_bcm.planner

## About this task

Beginning with the Xanadu release, cyclic dependencies in recovery tasks can be avoided to prevent repeated invocation of the same plan from other plans.

For example, in the Recovery task of Cyclic plan example 1 invokes Cyclic plan example 2 and Cyclic plan example 2 invokes Cyclic plan example 3. Cyclic plan example 3 invokes Cyclic plan example 1. If you attempt to
add a link between Cyclic plan example 2 and Cyclic plan example 3, it isn't allowed. An error message, similar to the one shown in the example, prompts you to choose a different related plan. It helps prevent such issues
from occurring in an event.

Similarly, if plans are activated beyond 10 levels or hierarchical links exceed 10 plan levels, an error message displays, suggesting plan removal before saving the record.

Starting from version 6.1.x of the Business Continuity Management application, the integration of recovery task automation into the business continuity planning process is introduced. This automation aims to enhance
efficiency, save time, and minimize the risk of human errors. Users who have the necessary access to the recovery task can classify it as either manual or automated. These tasks are organized in a sequential manner with
dependencies.

To automate a recovery task, administrators or application developers create an automation flow and associate it with the task. When the task moves to the Open state (when the plan
is activated as part of an exercise or an actual event), the automated flow is triggered. However, there may be instances where the automated flow fails due to system errors. In such cases, the user with access to the
recovery task can activate the manual task as a backup and assign it to a designated backup assignee. The backup assignee receives a system-generated email to complete the task flow. Plan users have the opportunity to
practice business continuity plan exercises and make improvements based on the results obtained.

Tasks can also be added in bulk by applying a task template group using the Add groups toolbar control on the Recovery tasks tab. Select Add groups, choose one or more groups from the Select task template groups dialog, and select Add. Each task template in the group becomes a recovery task on the
parent record. Use the parallel Add tasks control to add individual task templates without a group context.  
The Select task template groups dialog is filtered by context:

* From a plan, the dialog lists every group whose Active is true.
* From a loss scenario, the dialog applies an additional filter so that only groups whose Applicable to element definitions is All element definitions, or whose Element definitions contains the element definition of the loss scenario, are listed.
* From a recovery strategy, the same loss-scenario filter applies because a recovery strategy inherits its element definition from its parent loss scenario.
{#add-a-recovery-task__ul_add_groups_filter_rules}

When you open Add groups or Add tasks from a list that is itself filtered (for example, Phase = Recovery validation), the active list filters are applied as default field values on the new tasks. A field that is already set on the source task template takes precedence over the list filter for that field.

## Procedure

1. Navigate to WorkspacesBusiness Continuity Workspace.
2. In the List view, open the plan record and navigate to the Recovery tasks tab.  
   When no recovery tasks exist, the tab shows an empty list with an Insert button.
3. Navigate to the Recovery tasks tab and select New.  
   The recovery tasks that are added at the business continuity plan level are displayed on the Recovery tasks tab. You can add a recovery task to the business continuity plan as shown in the
   example.

   You can use the order of the tasks calculated by the system based on their dependencies. A task that doesn't have a dependency can be started first and it has the higher assigned order. Whenever you update or save the
   order of the tasks, the system recalculates and displays the order of all the tasks.

   If a plan has more than 500 tasks, the system doesn't update the order of the tasks automatically. A manual intervention is required to set the order of the tasks. An informational message is displayed informing the
   users to select the Update dependencies UI action that is available in the plan and recovery task records.  
   In a plan, while it's possible to tag multiple assets, you can concentrate on particular assets for certain scenarios. Beginning with the Xanadu release, you can tag specific assets to a recovery task and calculate the time taken to recover each asset accurately during an event or exercise. The actual duration and total effort of the assets in the events are determined based on the tagging of the assets. You have these options in the Tag assets field for assigning assets to a recovery task:
   * None
   * Specific
   * All

   {#add-a-recovery-task__ul_ec5_kk3_ccc}For example, when you select Specific assets in the Tag assets field, the Asset scope field is set to visible, enabling you to specify which assets can be tagged with the selected recovery task.

   The assets tagged in the recovery task are then included in the impacted assets for the event task. Properly tagging assets with recovery tasks verifies precise calculations of the recovery times for each asset. Note
   that only assets associated with newly created event tasks are copied over.

   Beginning with the Xanadu and later releases, a new field called Planned duration has been added to the recovery task form. The Planned duration field replaces the
   Completion deadline field, which was a reference field used for time frames. The Completion deadline field is removed from the plan task records.

   The Planned duration field enables you to enter the anticipated time needed to complete the task. After the event and exercise have been carried out, you can revisit and modify the data in this
   field. It offers a detailed view of the task's progress and the time needed for its completion.  
   The Create New Recovery task form is displayed.

4. On the form, fill in the fields.  
   For more information on the fields in the form, see [Create Recovery task form](https://servicenow-prod.fluidtopics.net/7cHdIH34XPrUN~ZtCq21mQ "Use the Create Recovery task form in the BCM Configurable Workspace to input the necessary details regarding the recovery task.").
5. Assign a phase to the recovery task.  
   The Phase column is available in both the list and form views of a recovery task.

   BCM administrators and managers can update recovery task phases using inline editing. BCM planners can also update phases, but only if they are the plan
   owners.

   Only active phases are available for selection in the Phase column as shown in the example.

   The phases of a recovery task can also be updated by modifying the Phase field in the form itself.
6. To exclude specific tasks from time calculation, select the Do not include in time calculation option.  
   When creating a recovery task, you can select this check box to exclude it from calculations.

   This feature also applies at the asset level, enabling for accurate tracking of time and effort for relevant assets. By providing this flexibility, the feature enhances the accuracy of time and effort
   calculations.
7. Verify the achieved recovery level of the impacted assets of a task in the Asset recovery level field.  
   In events, the Asset recovery level field indicates the achieved recovery level of impacted assets once all tasks with that recovery level (for example, Partially recovered) are
   completed.

   Previously, assets were marked as Recovered only when all event tasks were completed, even if assets were in later phases like Return to normal or Post-incident review. This approach delayed
   visibility into operational readiness. For example, even if an asset was functionally available during the Recovery phase, the system did not reflect the status until all tasks were completed.

   Starting with BCM release 9.x.x and later, the asset recovery status has been enhanced to provide granular tracking. Completing specific tasks now automatically updates the
   corresponding event asset state, progressing from Not Recovered → Partially Recovered → Recovered.

   Completing specific tasks now
   automatically updates the corresponding event asset state. Assets are marked as Partially Recovered when they're operational enough to support dependent assets, and
   Recovered when they're fully functional. This change improves visibility into operational readiness and enables recovery coordinators to identify when dependent assets can safely start
   their recovery process.

   In plans, the Asset recovery level column features color coding, offering visual cues for various recovery progress levels. Specifically, "partially recovered" is denoted by an info
   color, while "recovered" is indicated by a success color, making it easier to track recovery status at a glance.  
   Note:  
   The current demo data has an issue where both Include task in and Tag asset fields are empty. To resolve this, you have to add tasks to Include task in manually and select assets for the Tag asset field. Without these, event tasks won't be created and assets won't be marked as impacted.

   If you haven't selected Include task in, your event task won't be created. If you don't select Tag asset, your asset won't be marked as an impacted asset.

   This issue doesn't apply to newly created plans or old plans; it is applicable only for the current demo data.
8. **Optional:** Select a Plan loss scenario to scope the task to a specific disruption context, such as Loss of Datacenters.  
   Scoping a task to a loss scenario ensures that only tasks relevant to the active scenario are surfaced when the plan is exercised under that scenario type. The Plan loss scenario and
   Task group columns are visible on the Recovery tasks tab of the loss scenario record.

9. In the Assignment details section, verify or update the All assets from plan field to specify the asset scope for this task.  
   The field defaults to all assets defined in the plan. Narrow the scope when the task applies only to a subset of the plan's assets.

10. Enter the estimated completion time in the Planned duration fields: Hours, Minutes, and Seconds.  
    Planned duration values are used in Gantt chart rendering and scheduling calculations. Enter 0 in all fields if the duration is not yet known.
11. Select Save.  
    The updated recovery tasks are now displayed in the UI.

## Result

From the Recovery tasks tab toolbar, select one or more rows and use the Save as group split button to make the selected tasks reusable:

* Save as group creates a new task template group from the selected tasks. Open the Create task template group modal, enter a Group name, and select Create. Group names are unique; if you enter a name that is already in use the modal displays an inline error and prevents creation.
* Save as groupAdd to group appends the selected tasks to an existing task template group. Dependencies between the selected tasks are preserved.
* Save as groupSave tasks (single row selected) saves the individual task as a task template, without any group context and without inter-task dependencies.
{#add-a-recovery-task__ul_save_as_group_options}

* **[Create Recovery task form](https://servicenow-prod.fluidtopics.net/7cHdIH34XPrUN~ZtCq21mQ)**   
  Use the Create Recovery task form in the BCM Configurable Workspace to input the necessary details regarding the recovery task.

*[\>]: and then