--- 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 --- # Data flow, planning, and execution in an event # Data flow, planning, and execution in an event {#ariaid-title1} * Release version: Australia * * Updated March 12, 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 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 Data flow, planning, and execution in an event This content explains how configuration item (CI) data flows automatically through ServiceNow AI Platform's CMDB, Business Impact Analysis (BIA), plans, and event exercises to streamline disaster recovery and business continuity planning. It outlines how dependencies are assessed, plans are created and sequenced, and how execution occurs during an event, enabling efficient and coordinated recovery efforts. Show full answer Show less ## Key Features * **Automatic Data Flow:** Configuration items created in CMDB are automatically available as assets in BIA for dependency assessment. These dependencies then flow into planning and event execution stages, reducing manual effort. * **Dependency Assessment in BIA:** CIs from CMDB and their relationships are used to identify critical dependencies impacting business functions. Users can also add dependencies manually for comprehensive analysis. * **Integrated Planning:** Plans for assets identified in BIA are automatically available for association in the planning phase. New plans and assets can also be added manually. Plans can reference related plans to manage dependencies across teams or departments. * **Task Sequencing and Plan Branching:** Recovery tasks execute sequentially by Task ID. Plans can branch to related or referred plans during execution, ensuring dependent recoveries occur in the correct order. * **Event Execution and Tracking:** During an event, impacted assets and associated plans are automatically populated in the exercise. Planners can add assets or plans manually. Execution progress is tracked via the Event Tasks tab, with tasks triggering in sequence and branching where applicable. * **Controlled Execution Hierarchy:** When a main plan refers to sub-plans, execution flows through the sub-plan's tasks and then returns to complete the main plan. However, execution of sub-sub-plans (nested beyond one level) is not supported, limiting the execution hierarchy to one level of sub-plans. ## What This Enables ServiceNow Customers to Do * Reuse existing CMDB data to build accurate BIAs, ensuring dependencies are consistently accounted for throughout recovery planning and execution. * Create comprehensive recovery plans that automatically incorporate dependencies and related assets to improve readiness and response coordination. * Sequence recovery tasks and coordinate cross-team recoveries by branching plans, ensuring assets are recovered in the proper order to minimize downtime. * Track recovery task execution in real-time during an event, gaining visibility into progress and dependencies to manage recovery efficiently. * Manually augment automated data with additional dependencies, plans, or assets to tailor recovery exercises to specific organizational needs. ## Practical Considerations To maximize the benefits of this data flow and execution model, customers should maintain accurate CI relationships in CMDB and ensure BIA assessments are regularly updated. When creating plans, leveraging the ability to refer to related plans helps coordinate recovery activities across teams. Understanding the execution hierarchy limitation (only one level of sub-plans) helps in designing manageable and clear recovery workflows. When the configuration item data is available on the ServiceNow AI Platform the same items can be used to assess dependencies in business impact analysis (BIA). The dependencies from the BIA can then be used in the planning and events. The configuration items (CIs) can be added manually to the plans and events as well. You can also add new plans with assets to be recovered in a sequence. The advantages of automatic data flow are: * You can reuse the configuration item (CI) data that is created in CMDB in BIA, and from the BIA the dependencies are used in the plans and events. * You can branch to a related plan within a main plan task before executing remaining tasks, especially when other departments or teams manage the related plans. * The flow of execution is sequenced as per the Task ID and no event task is skipped in between. {#planning-execution-event-bcm__ul_lvw_5ck_gvb} ## Automatic data flow from CMDB to BIA and BIA to plans {#planning-execution-event-bcm__section_urf_kt3_gvb} When a record is created in ServiceNow AI Platform as a configuration item in CMDB, the record and its related items are available as assets to assess dependencies in BIA. CMDB : Data is created as a CI and the record is stored in CMDB. In CMDB, this CI is related to other items by a relationship either that depends on or used by the other related items. For example, if it's a Data Center NYC, then it can depend on SAP on-premise application and other web servers, business processes, locations, and others. BIA : When you assess a BIA based on CMDB dependencies, the CMDB CI and its related items are automatically available as items for assessment in BIA. You can add these dependencies and the source of these items are tracked as CMDB. Therefore, the data created in CMDB is available as dependencies in BIA. In addition, you can also manually create other dependencies in BIA. For example, the Data Center NYC and its dependent SAP on-premise application are available in BIA to be added as dependencies. In addition, you can also add dependencies manually such as a Facility: New York. Plan : When you are in the planning stage, if you have scoped the BIA-dependent item and added it as the scope, then the dependencies of the scoped item are available as Related Assets. Also, the plans existing for these assets are available as Related Plans. In addition, you can add new plans also. For example, a plan is created for Data Center: NYC, along with which the related plans of the related assets such as SAP on-premise application and Facility: New York (created in BIA) also move in to the planning phase automatically. In addition to the items that came from the BIA, you can also add new assets manually to the plan.In the Recovery Tasks tab of a plan, you can also [refer to a different plan](https://servicenow-prod.fluidtopics.net/KUN7pmjHvW1dA8g2YlI2~Q#bcp-recovery-tasks-grid__refer-related-plan-bcp) and select the plan from the list of related plans. Exercise : In the event, the impacted assets and the activated plans are pulled into the Impacts tab automatically based on the dependencies in the BIA. Along with the primary scope of exercise and related impacts, you can also add assets and plans manually, which are all pulled into the exercise for recovery. ## Planning phase {#planning-execution-event-bcm__section_bk4_bp3_gvb} In this planning phase, as a planner you can identify the related assets, add the related plans, and set a sequence and dependencies for execution of recovery. Figure 1. Recovery tasks to activate related plans If you must recover assets in Data center A before recovering assets in Data center B, refer to a different plan for recovery process of Data Center A. In this case, use the Refer a different plan option in the Recovery Tasks tab of the main plan. Select the relevant plan from the related plans to recover Data center A. The referred plan has its own set of tasks that the application executes when it comes to this particular task. You can also set a sequence for the execution of the referred plan within the event tasks of the main plan. ## Tracking and execution phase {#planning-execution-event-bcm__section_frn_jr3_gvb} In the tracking and execution phase, you can activate relevant plans during an event recovery. When you add an impacted asset in the Impacts tab of an exercise, then all the related assets and related plans are pulled in. Similarly, if you add a plan, then all its sub-plans are also added. Navigate to the Event Tasks tab to track the execution of the event tasks of the selected main plan. When you click the Start Event button for an event, the tasks are triggered for execution. When you select the main activated plan in the Plans section of the left pane, you can view all the event tasks of the selected plan. In the Plans section on the left, below the main plan are the Related plans. The event tasks of the main plan are executed in the order of Task ID sequentially. When a particular task in the sequence has a referred or a related plan, then the application branches off to that plan. It executes all the tasks listed in that plan thereof. It completes the sequence before coming back to the original main plan. Therefore, there's a main list of recovery tasks under a main plan, within which there are sub-plans with their own set of recovery sub-tasks. The application executes all the tasks sequentially within the referred plan before it continues to execute the rest of the recovery tasks sequentially in the main plan. Note: For a primary main plan, if there are related referred plans within, then the application executes only the referred sub-plan. It does not execute any other related plan that the sub-plan might have. The hierarchy of execution stops with the first level only if there are sub-plans.