---
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


---

# Using the flexible data model

# Using the flexible data model {#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 the flexible data model

The flexible data model, introduced with Operational Resilience in Release 21.0.x, significantly enhances the management and visualization of operational resilience metrics within ServiceNow.
It replaces the previous monolithic data approach with a more efficient, node-based hierarchical structure, improving data retrieval, maintenance, and dashboard insights.
This model supports multiple dashboards that provide detailed views into red flags, business service importance, and impact tolerance, helping organizations better monitor and manage service dependencies and risks.
Show full answer Show less  

## Key Features

* **Enhanced Data Visualization:** The model introduces a vertical layout in modules such as Services, Business Services, Offerings, Business Processes, and Application Services, replacing horizontal tabs for easier navigation. Users can view comprehensive resilience metrics and drill down into dependency records, controls, and control objectives.
* **Streamlined Navigation:** Direct access to related lists and key metrics---including service offerings, dependencies, and incidents---is available from the vertical layout, simplifying data exploration within the Operational Resilience Workspace.
* **Hierarchical Data Storage:** Each node (business service, offering, process, etc.) is stored separately in the \[snoperresprofile\] table along with its class and parent nodes, enabling efficient data management and reducing complexity.
* **Configurable Top Class:** The `snoperres.topclassname` property allows customers to designate any class (e.g., business service, application service) as the top node in dashboards. This flexibility supports tailored views of downstream data and key metrics based on the selected top class.
* **Red Flags Calculation and Roll-Up:** Scheduled jobs calculate and roll up red flags across service dependencies, displaying aggregated counts on dashboards. This hierarchical aggregation provides a clear understanding of risk exposure at various levels.
* **Main Node Configurations:** These predefined configurations, sourced from the OpRes CMDB, define dependency roll-up chains linking business processes, services, offerings, and applications. They enable the system to map and display service flows and impacts effectively.
* **Scheduled Jobs Automation:** Two key scheduled jobs---Update CSDM and other dependencies, and Calculate red flags for CSDM and dependencies---run regularly to populate and update the \[snoperresprofile\] table and red flag data, ensuring dashboards reflect current operational status.

## Practical Benefits for ServiceNow Customers

* **Improved Operational Resilience Monitoring:** Customers can gain a comprehensive and real-time view of service dependencies and associated risks through intuitive dashboards, facilitating proactive risk management.
* **Efficient Data Handling:** By storing hierarchical nodes individually and eliminating complex recursive queries, the model improves performance and scalability for large service environments.
* **Customizable Insights:** The ability to configure the top class enables organizations to tailor dashboard views to their specific operational focus areas, such as prioritizing business services or application services.
* **Simplified Maintenance:** The enhanced data model and automated scheduled jobs reduce manual effort to maintain accurate dependency and risk data, helping keep operational resilience metrics up to date.

## Next Steps

* Review and configure the `snoperres.topclassname` property to align dashboards with your organizational priorities.
* Familiarize yourself with Main node configurations to understand and customize dependency roll-up chains.
* Ensure scheduled jobs for updating dependencies and calculating red flags are enabled and running regularly to maintain data accuracy.
* Leverage the vertical layout in the Operational Resilience Workspace to explore and analyze resilience metrics across your services and dependencies.  
Starting with Operational Resilience, Release 21.0.x, the flexible data model enhances operational resilience metrics by improving data visualization and the flow of dependent services. It also supports multiple dashboards with insights
into red flags, business service importance, and impact tolerance.

Starting with Operational Resilience, Release 20.1.x, the Main node configurations, supported by the Data Relationships Framework, were introduced with Operational Resilience to define dependency roll-up chains. The Main node configurations, with the source being the OpRes CMDB, are shipped with base system. For information on the Main node configurations, creating a new
Main node configuration, or updating an existing Main node configuration, see [Main node configurations: A component of the Data Relationships Framework](https://servicenow-prod.fluidtopics.net/TMamt19dEmvG_VKWb3WGDA "Starting with Release 20.1.x, the Main node configurations, supported by the Data Relationships Framework, are available with Operational Resilience to define dependency roll-up chains. Operational Resilience administrators configure the entity types and pillars, generate the entities, and then establish relationships between different CSDM objects. After this setup is complete, data from the CMDB is fetched into Operational Resilience, displaying rolled-up dependencies in the Workspace view.").

In the previous data model, the CSDM objects \[sn_oper_res_profile\] table stored the entire dependency chain, including all possible combinations, making data retrieval cumbersome and maintenance challenging. This approach has been
deprecated in favor of a more efficient model.

## Key features of the flexible data model {#flexible-data-model-changes__section_w4g_nw4_zfc}

The flexible data model offers several key features that enhance operational resilience metrics.

* Enhanced data visualization: The Services, Business services, Offerings, Business processes, and Application services modules now feature a vertical layout, replacing traditional horizontal tabs and enhancing navigation within the Operational Resilience Workspace. You can view the entire resilience metrics for an object, such as a business process or business service, from the Overview tab in the vertical layout.

  You can then view the downstream data and various dashboards based on the selected top class. The following example shows the top controls to be strengthened for the business service.

  Selecting the graph shows detailed information on the dependency records, related controls, control objectives.
* Streamlined navigation: You can directly access related lists and metrics for a specific business service from the vertical layout. These include service offerings, business processes, application services, dependencies, and incidents.
{#flexible-data-model-changes__ul_br2_tw4_zfc}

## Technical implementation {#flexible-data-model-changes__section_ibr_qw4_zfc}

Starting with Operational Resilience, Release 21.0.x, the data model for operational resilience configurations has been optimized. Each node in a hierarchical chain, such as a business service to offering to processes, is stored separately in the \[sn_oper_res_profile\] CSDM objects table. The table stores each node along with its class and parent nodes. This means that only relevant objects (for example, 500 out of 1,000 entities) that are part of main node configurations are stored,
improving data management efficiency.
The flexible data model introduced with Operational Resilience, Release 21.0.x provides a foundation for the dashboards and tracks the flow of dependent services. The data is updated in the dashboard through changes to the flexible data model. This includes red flags by type, such as failed controls, incidents, and outages. It also includes business service metrics such as number of flags, importance, and impact tolerance.

The data shown in the example is for business services such as business service by number of red flags, business service by importance, business service by impact tolerance. You can configure the
sn_oper_res.top_class_name property to designate any class as the top class.

## Configuring the sn_oper_res.top_class_name property {#flexible-data-model-changes__section_wym_cqj_bgc}

You can configure the sn_oper_res.top_class_name property to designate any class as the top class in the dashboard view. Any node, such as business service, business process, or application service, can be the top node. You can then view the downstream data and various dashboards based on the selected top class. For example, you can view the number of application services that are under a business service. It enables you to switch between different views, such as business services, service offerings, business processes, or applications, on the dashboard and view relevant data accordingly.

For example, if the data is displayed for a business service, you can change the top class to service offerings, business processes, or application services. Configure the
sn_oper_res.top_class_name property to make this change. You can then change the top class to another object and the system shows data with respect to that specific top class. This property is applicable only for the dashboards and
not for the Workspace forms. For more information on the properties, see [Configure Operational Resilience properties](https://servicenow-prod.fluidtopics.net/CTbRjiJ~yNCAc33wtx1r~w "Configure main properties of the Operational Resilience so that you can set up and fetch data into the application for reporting purposes.").

The following example shows that the top class name is set to cmdb_ci_service_business.

You can modify the property value to represent a service offering or application, and the dashboard will populate with the corresponding data. The following example demonstrates how to update the top class name to "service
offering."

Based on the updated property name, data for service offering is displayed in the Operational Resilience dashboard as shown in the example.

## Calculation and roll-up of red flags {#flexible-data-model-changes__section_gdb_bx3_bgc}

When the Calculate red flags for CSDM and dependencies scheduled job is executed, the red flags data is populated in the dashboard. The
dashboard in the following example displays a range of 1-30 red flags in the "Business service by number of red flags" section.

Selecting the card shows a detailed breakdown for the business service. It shows a total of 24 red flags, with 3 specifically attributed to the "Cards and payments" service. The following illustration shows the roll-up functionality, which aggregates the red flags for the entities associated with the selected "Cards and Payments" business service. This provides a hierarchical view of the data.

The value "24" shown in the Total red flags count column is the roll-up value. It aggregates red flags for all entities under the "Cards and Payments" business service.

## CSDM objects table {#flexible-data-model-changes__section_rmn_my3_bgc}

In the CSDM objects \[sn_oper_res_profile.list\] table, the following columns are displayed:

* The Impacted objects column displays the parent objects.
* The Impacted objects classes column shows the classes.
* The Red flags count column indicates the number of the red flags that are directly assigned to a node.
* The Total red flags count column displays the total count of the red flags directly assigned to a node and its children as shown in the table.
{#flexible-data-model-changes__ul_d2l_v4y_zfc}

The object classes displayed in the Object class column in the example provide a clear representation of various entities, including business applications and processes. This data is then fed into the system using fix scripts,
ensuring that the information is accurately populated and up-to-date. By using these scripts, the system can effectively display and manage the complex relationships between different object classes.

You can group the objects with
respect to their object classes. Then you can the object classes for service offerings, core company, business processes, and so on.

The upstream impacted objects for a specific object class are added to the Impacted objects column. For example, the Java Application Server FLX has upstream impacted objects such as digital banking process and inbound payment. These objects are added and shown in the Impacted objects column.

This process starts with the lowest level object and includes the level above it, populating the impacted objects. The data is then directly integrated into the main node configurations.

## Main node configurations {#flexible-data-model-changes__section_wqc_mjj_bgc}

The Main node configurations provide the data flow of what you want to see. The following Main node configurations, with the source being the OpRes CMDB, are shipped out-of-the-box:

* Business process to dependencies
* Business service to dependencies
* Opres with CSDM header
* Service (CMDB)
* Service offering to dependencies
{#flexible-data-model-changes__ul_zrr_43j_bgc}

The entire flow from a business service to business process to service offering to an application is created in the Main node configurations. The configurations are then mapped to the impacted objects.

For information on setting up the Main node configurations, see [Configure the Main node configurations](https://servicenow-prod.fluidtopics.net/d_BOjuVVe~oU~uYRvnAf4A "Create the Main node configuration record to fetch data into Operational Resilience for reporting. Main node configurations are available with the base system. You can use the existing Main node configurations or create new Main node configurations for your business needs.").

## Running the scheduled jobs {#flexible-data-model-changes__section_rbf_tvp_zfc}

Two scheduled jobs, Update CSDM and other dependencies and Calculate red flags for CSDM and dependencies run at regular
intervals populate data in the CSDM objects \[sn_oper_res_profile.list\] table and the red flags. For more information, see [Execute the scheduled jobs](https://servicenow-prod.fluidtopics.net/UBM4zC8ABBq7a15owSoCMQ "Execute the scheduled jobs required for the main node relationships. After the scheduled jobs are executed, CSDM objects with their configured relationships are imported into Operational Resilience for reporting.").

All the Main node configurations are handled in parallel. A separate event is triggered for each Main node configuration, enabling parallel processing. The enhanced configuration eliminates the need
for sequential processing, significantly improving efficiency.

After running the Update CSDM and other dependencies scheduled job, the data is fetched into the CSDM Objects table. Dependencies are updated for the objects and are shown in the modules.
Figure 1. Service form

Previously, traversing many-to-many tables to find related records was time-consuming. Now, by storing impacted objects in the table itself, you can directly retrieve related records from a single column. This eliminates the need for recursive hierarchy creation and improves efficiency significantly.

Dependencies are fetched from the Entity \[sn_grc_profile\] (many-to-many) table first. When you run the Calculate red flags for CSDM and other dependencies scheduled job, the red flags data is fetched and rolled up according to the configured settings.

After the scheduled job is completed, the Main node configurations are no longer required. The dashboard uses the top class property to traverse the red flags staging table. It retrieves downstream red flags that match the specified record type, such as business service or service offering.

The following example shows that Incident SO1 - VM is rolled up from SO1.

Failed controls from business processes and service offerings are rolled up and shown in the modules.