--- 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 --- # Fetching dependencies from the CMDB and BIA # Fetching dependencies from the CMDB and BIA {#ariaid-title1} * Release version: Australia * * Updated March 12, 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 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 Fetching dependencies from the CMDB and BIA In the Australia release, ServiceNow's Operational Resilience application integrates with the Configuration Management Database (CMDB) and Business Impact Analysis (BIA) to automatically fetch and update service dependencies. This ensures that the operational resilience data reflects accurate and current service relationships, crucial for impact and risk assessments. Show full answer Show less ## Fetching Dependencies from CMDB The Operational Resilience application leverages the Data Relationships Framework (installed by default) to retrieve dependencies from the CMDB via API calls. Administrators must activate the main node configuration labeled "Service (CMDB)" within the Data Relationships Framework for this process to function. When dependencies are fetched: * The application first checks if a matching entity exists in Operational Resilience. If none exists, the dependency is skipped (entities are not automatically created). * If the entity exists and belongs to a recognized Operational Resilience entity type, it is linked as a downstream dependency. * If the entity exists but does not belong to any Operational Resilience entity type (e.g., Facilities, People, Suppliers, Technology), it must be manually assigned to the appropriate entity type within Operational Resilience. An example scenario involves a business service "Windows mobile" with dependencies such as email servers linked downstream to their respective parent entities. ## Fetching Dependencies from BIA When Business Continuity Management (BCM) applications are installed, Operational Resilience also fetches dependency updates from approved BIAs under these conditions: * The BIA must be in the Approved state and not Expired. * The dependency group within the BIA must be completed. * The "Applies to" field in the BIA must match a business process entity type used in Operational Resilience. Dependencies fetched from BIA follow the same validation rules as CMDB dependencies regarding entity existence, status, and type before being added downstream. ## Dependency Validation Rules * Dependencies without existing entities in Operational Resilience are skipped; new entities are not created automatically. * Inactive dependency entities are ignored. * Active entities without an assigned pillar or without belonging to any Operational Resilience entity type are ignored. ## Manual Dependency Management Administrators and managers retain the ability to manually add or update dependencies, especially for entities that do not fall into predefined entity types. This manual step ensures that all relevant dependencies are properly classified and linked for accurate resilience modeling. ## Additional Information For detailed configuration of main node settings and understanding the Data Relationships Framework, customers should refer to the respective documentation on creating main node configuration records. You can fetch the dependencies for the services or business services from CMDB in Operational Resilience. Similarly, when the BCM applications are installed, the Operational Resilience scheduled job also monitors for the changes in the business impact analysis (BIA) dependencies and fetches the dependency updates. ## Fetching the dependencies from CMDB for the services {#add-dependencies-automatically__section_om1_qgf_11c} Beginning with the Australia release, the Data Relationships Framework supports the Operational Resilience application with the underlying framework to fetch the dependencies from CMDB. The Data Relationships Framework (app-grc-relationship-config) is installed with the Operational Resilience application by default. The CMDB dependencies are retrieved by calling an API from the Data Relationships Framework.​ To get the CMDB dependencies, the Operational Resilience administrator must activate the main node configuration, labeled as Service (CMDB) in the Data Relationships Framework first.​ For each retrieved dependency, the Operational Resilience application searches for an existing entity first. If there is no existing entity, the dependency is skipped. If there is an existing entity and the entity belongs to any entity type in Operational Resilience, it is added to the downstream of its parent's entity. If the entity does not belong to any entity type, such as Facilities/People/Suppliers/Technology, you must add it manually to the corresponding entity type in Operational Resilience.​ The following example shows a sample CMDB relationship setup for a business service. When the service Windows mobile updates its dependencies, the entity of OWA-SD-01 gets added to the downstream of its entity, IronMail-SD-01 and IronMail-SD-02 gets added to the downstream of the Email child service entity. {#add-dependencies-automatically__table_j4p_rzb_f1c__entry__3} | Business service | Associated dependency, business process, and business service: Email | Process and dependencies associated with business service: Email | |-|-|-| | Windows mobile | * Dependency: OWA-SD-01 * Business process: Inbound payment validation * Business service: Email {#add-dependencies-automatically__ul_kyq_k1c_f1c} | * Process: Fraud_escalation * Dependency 1: IronMail-SD-01 (The table is cmdb_ci_email_server.) * Dependency 2: IronMail-SD-02 (The table is cmdb_ci_email_server.) {#add-dependencies-automatically__ul_yjq_n1c_f1c} | [Table 1. Sample relationship setup for a business service] {#add-dependencies-automatically__table_j4p_rzb_f1c} ## Fetching the dependencies from the business impact analysis (BIA) {#add-dependencies-automatically__section_np2_vjf_11c} When the BCM applications are installed, Operational Resilience fetches the BIA's dependency update if the BIA's Applies to field is a business process used in Operational Resilience. The following conditions must be met for pulling the BIA dependencies in Operational Resilience: * The BIA has to be in the Approved state. * The BIA should not be in the Expired state. * The dependency group has to be completed. {#add-dependencies-automatically__ul_idh_hkf_11c} Note: Only when the Applies to field of the BIA record matches with any business process within the Business Processes Entity Type, its dependencies are fetched by the scheduled job. For each fetched dependency, the Operational Resilience application looks for an existing valid entity first. If the dependency has an existing valid entity and the entity belongs to any entity type in Operational Resilience, it is added to the downstream of its parent's entity. To fetch the CMDB dependency updates or BIA dependency updates, the following conditions are followed. * If there is no entity for the dependency, it is skipped. Operational Resilience does not create an entity for the dependency. * If a dependency entity is inactive, it is ignored. * If a dependency entity is active, but it has no pillar, it is ignored. * If an active dependency entity has a pillar, but it does not belong to any Operational Resilience entity type, it is ignored. {#add-dependencies-automatically__ul_pl2_314_d1c} ## Adding the dependencies manually {#add-dependencies-automatically__section_qtd_phf_11c} If the entity does not belong to an entity type, manually add it to the corresponding entity type. Operational Resilience administrators and managers can manually update dependencies instead of using the scheduled job. ## Support for main node configuration in Data Relationships Framework {#add-dependencies-automatically__section_kwx_35c_qzb} For information, see [Data Relationships Framework](https://servicenow-prod.fluidtopics.net/XY8p9NXpWII1Lr6oTtFWjQ "The Data Relationships Framework application (sn_grc_rel_config) supports the BCM application with the underlying framework to fetch the dependencies in the BIAs, plans, and events from different sources such as CMDB, BIA, and BCP. Beginning with the Australia release, the Data Relationships Framework (sn_grc_rel_config) application is installed with the BCM application by default.") and [Create a main node configuration record](https://servicenow-prod.fluidtopics.net/Km2jUTQ_5E~YkgvyX72Lyw "Create a main node configuration record to configure the source for fetching the dependencies. You can configure the details of the main node such as its name, source, table name, filter conditions, and so on.").