The business continuity plan (BCP) is created in the Draft state and it is displayed in the List view. The state and details of the business continuity plan are displayed in the following tabs.

• Overview: You can view the current state and overall state progression of the BCP.
• Details: You can add the details of the plan such as its name, template, type, plan owner, and so on.
• Scope:

  You can add an asset to the scope of the plan and view the primary elements that are defined in the plan template. Beginning with the Xanadu release, the Asset dependencies tab now displays detailed information about the assets, replacing the Primary scope and Related asset toggles previously found in the Scope tab of the plan record.

  Additionally, the Type column in the Scope tab of the plan records has been renamed to Types column, allowing an asset to be categorized both as a primary scope and a related asset. The primary scope and related assets are now displayed in the same list. The Source column that used to indicate the source of the asset has been moved to the Asset dependencies tab.

  The BIA column in the Scope tab has been updated from a document ID type to a reference type, enabling administrators to select and access the BIA record, update its information, and dot-walk to the plan record. It simplifies the process and saves time and effort. When two business impact analyses have identical asset dependencies, the most recent BIA is acknowledged as the source for these relationships.

  When creating a business continuity plan, you can enter details such as the Recovery Time Objective (RTO), Recovery Point Objective (RPO), Recovery Tier, and BIA link based on the primary asset in the plan record. Updating the dependencies refreshes the asset details in these columns with information from the latest unarchived BIA record. If the asset originates from a downstream BIA, the columns for Recovery Timeframe and Required Data Backup are revised to display the latest data for that asset.

  Add primary scope and Add related asset UI actions: You can mark an asset as a primary scope, assign it as a related asset, or link it as a related asset to a primary scope within the plan. This approach simplifies the classification of asset types and enables you to view the relationships directly on the plan record page. It shows which assets are impacted when the primary scope is operationally down, thereby saving time and effort. You can monitor the gaps in the primary and related items.

  The following example shows that the IAD datacenter is added as both a related asset of a primary scope and as a primary scope itself.

  

  The Add related asset action allows you to add a related asset and then relate it to a primary asset. For example, Abel Tuter, employed at the IAD datacenter, is added as a related asset.

  
• Asset dependencies:

  The Asset dependency tab provides a Hierarchical view illustrating the relationships between parent assets and their child assets. In this example, it is shown that Abel Tuter is a related asset to the IAD data center.

  

  Since the user, Abel Tuter, was added manually, the Primary source column indicates it as a manual source.

  You can track dependencies in the Hierarchical view and List view. You have the option to switch from the Hierarchical view to the List view, where all assets are presented in a list format. The List view displays up to 20 child assets. If a plan includes more than 20 assets, you can select an asset to view its associated assets.

  

  For example, the Business Application: Acrobat is considered a primary asset, while the Company: Adobe systems is identified as its related asset. The source of the asset is displayed in the Primary source column.

  

  You can add details from the dependent items in the plan as shown in the example.

  
• Documentation: You can record the recovery capabilities of the plan in the documentation sections.
• Related plans:

  You can add a related plan to the plan record, which can be invoked during a recovery task. When the current parent plan is added to an event, you can invoke its related plan from that specific task. The following example shows that Plan 2 is linked as a related plan to Plan 1.

  

  Previously, adding a plan as a related plan automatically linked it back to the original plan. For example, if Plan 1 and Plan 2 existed, and Plan 2 was linked as a related plan to Plan 1, Plan 1 would automatically be linked to Plan 2. However, with the introduction of the Xanadu release, this process has been modified to a one-directional relationship. The related plan record does not create a link to the original plan record. For example, Plan 2 does not create a link to the original plan record, Plan 1.

  

  To insert the link manually, navigate to the Related Plans tab and add the link there. This update allows you to specify the plan relationship as either a parent-child or a sibling relationship.

• Recovery teams: You can create the recovery teams for the business continuity plan.
• Loss scenarios: You can add the loss scenarios that are applicable to the business continuity plan.
• Parent plans: You can review the parent plan from where the current plan is being invoked. For example, Plan 2 can be invoked in any one of the tasks which are present in the Plan 1.
• 

  In the Plan record, it is not possible to add a parent plan, but you can view the parent plan linked to a related plan. The Parent plans tab is used for viewing purposes only.

• Recovery tasks:

  You can create a recovery task within the business continuity plan.

  

  A cyclic dependency occurs when two or more recovery tasks rely on each other, either directly or indirectly. Beginning with the Xanadu release, it is possible to prevent cyclic dependencies in recovery tasks, ensuring that the same plan is not triggered multiple times.

  

  For example, if the recovery task in Plan 1 triggers Plan 2, Plan 2 then triggers Plan 3, and Plan 3 subsequently triggers Plan 1, this sequence creates a cyclic dependency. An error message, similar to the provided example, is displayed to inform users that triggering the plan has resulted in a cyclic dependency and suggests selecting an alternative related plan. Choosing a different related plan in such cases helps avoid these issues during an event.

  

  If plans are activated beyond 10 levels or hierarchical links involving more than 10 levels of plans are established, an error message is displayed, advising the removal of the plan before the record can be saved.

  
  Beginning with the Xanadu release, the recovery tasks are organized based on their dependencies. You have the flexibility to assign dependencies to the tasks, and the application then determines a sequence for these tasks based on the assigned dependencies. If there are tasks without any dependencies linking them, they can be handled simultaneously.

  Note:

  You can edit the sn_bcp.sync_order_calculation_task_limit property to change the count for the recovery task order so that it is calculated synchronously.
  
  The sequence of tasks depicted in the illustration is clarified with the following example:

  1. Task 1 and Task 3 are independent of each other, allowing them to be executed at the same time, and they are both assigned a planned order of 1.
  2. Task 5 depends on both Task 1 and Task 3 and therefore, it is assigned a planned order of 2.
  3. Task 6 depends on Task 4, which has a planned order of 3. The planned order for Task 6 is then set at 4.

  Tasks can be performed simultaneously, allowing several users to collaborate on the same plan at once. When a dependency is updated for a task and the task is saved, the planned order for the tasks is recalculated based on the removed dependency.

  If you have over 500 recovery tasks and the dependencies are updated, the planned order of these recovery tasks is not updated instantly. Rather, an informational message is displayed, suggesting that the planned order of the recovery tasks be updated using the Refresh tasks order UI action.

  

  The option to refresh the task order is also accessible from the menu in the plan record, as illustrated in the example.

  

  When you need to reorder recovery tasks within a plan, users are informed through a message that the reordering process may take some time. They can use the Refresh tasks order UI action to update the order.