Landing page and dashboard views

  • Release version: Australia
  • Updated March 12, 2026
  • 5 minutes to read

    • The landing page in the Operational Resilience Workspace provides a single-pane overview of the services, business services, and pillars in your organization. The dashboard displays resilience metrics, including operational status, completed activities, red flags, and suggestions for improvement.

    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, including red flags by type, such as failed controls, incidents, and outages, and business service metrics such as number of flags, importance, and impact tolerance, is updated in the dashboard through changes to the flexible data model.

    Dashboard data.

    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 change it service offerings, business processes, or application services by configuring the sn_oper_res.top_class_name property. You can then change the top class to another object and the system shows data with respect to that specific top class.

    Calculation and roll up of red flags

    The dashboard shown in the earlier example displays a range of 1-30 red flags. Upon selecting, it shows a detailed breakdown, showing a total of 20 red flags, with 3 specifically attributed to the "cards and payments" level. This illustrates the roll-up functionality, which aggregates red flags beneath the selected "Cards and Payments" business service, providing a hierarchical view of the data.

    red flags.

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

    The Calculate red flags for CSDM and dependencies scheduled job does not create new records in the [sn_oper_res_profile] table. Instead, it recomputes the impacted objects for the existing sn_oper_res_profile records using data from the [sn_grc_m2m_profile_profile] table.

    The Calculate red flags for CSDM and dependencies scheduled job fetches the red flags for the profiles in the [sn_oper_res_profile] table only when the following conditions are met:
    • The sn_oper_res_profile.pillar is not empty.
    • The sn_oper_res_profile.applies_to field is not empty.

    The red flags fetching mechanism can use either the sn_oper_res_profile.profile condition, the sn_oper_res_profile.applies_to condition, or a combination of both.

    The red flags also inherit the impacted objects and impacted object classes from the [sn_oper_res_profile] record. For example if an application service's Operational Resilience profile lists Business service, Offering, and Business process as impacted objects (shown in the Impacted objects column), these objects are copied to all associated red flags for the application service and its related entities.

    Note:
    Beginning with Operational Resilience release 22.x.x, the Calculate red flags for CSDM and dependencies and Update CSDM and other dependencies scheduled jobs are deactivated by default for new installations. For existing installations, these jobs retain their current state (active or inactive).

    Conditions for calculating the red flags

    This section uses the sn_oper_res_profile.profile and sn_oper_res_profile.applies_to conditions for reference. The criteria for calculating red flags and the relevant tables are detailed in the Red flags calculation table.

    Table 1. Red flags calculation
    Red flags Table Conditions Notes
    High risks - Advanced risk [sn_risk_advanced_risk_assessment_instance] Conditions:
    • entity_1=profile
    • status=30
    • summary_residual_risk_score should be greater than the max criteria defined in risk_assessment_methodology
    • Should not have any open assessments linked to sn_risk_advanced_risk_assessment_instance
    		 For all these risks, staging records are created in the [sn_oper_res_risk] table.
    Failed controls: Step 1 (Optional) [sn_compliance_m2m_control_entity] (sn_compliance_control ← → sn_grc_profile) Conditions:
    • entity=profile
    • control.status=non_compliant
    • control.exempt=false
    • control.state=monitor
    • control.active=true
    		 A list of controls is extracted and are valid red flags.
    Failed controls: Step 2 [sn_compliance_control] Conditions:
    • entity=profile or sys_id in the list of controls
    • control.status=non_compliant
    • control.exempt=false
    • control.state=monitor
    • control.active=true
    		 For all these controls, staging records are created in the [sn_oper_res_failed_control] table.
    Issues: Step 1 (Optional) [sn_grc_m2m_issue_to_entity] (sn_grc_issue ←→ sn_grc_profile) Conditions:
    • entity=profile
    • sn_grc_issue.active=true
    		 A list of issues is extracted and are valid red flags.
    Issues: Step 2 (Optional)
    If one of the following pillars is used, then this step is considered:
    • Service
    • Business service
    • Offering
    • [sn_oper_res_m2m_scenario_event_issue] (scenario_event ←→ sn_grc_issue)
    • [sn_oper_res_m2m_scenario_event_service] (scenario_event ←→ service)
    		 A joint query is performed using the two tables and [sn_grc_issue] is fetched for the service, business service, and offering. These are appended in the list of issues from step 1.
    Issues: Step 3 [sn_grc_issue] Conditions:
    • entity=profile or sys_id in the list of controls
    • active=true
    • In addition, the issues should not have any exception policy.
    • Exception policy can be checked in the [sn_compliance_policy_exception] table with two conditions:
      • validity>now
      • state=8
    		 For all these issues, staging records are created in the [sn_oper_res_issue] table.
    Incident: Step 1 incident Conditions:
    • cmdb_ci=profile.applies_to
    • state IN [1,2]
    		 For all these incidents, staging records are created in the [sn_oper_res_incident] table.
    Incident: Step 2 (Optional) [task_ci] Conditions:
    • ci_item=profile.applies_to
    • task.sys_class_name=incident
    • task.state IN [1,2]
    Incident: Step 3 [task_cmdb_ci_service] Conditions:
    • cmdb_ci_service=profile.applies_to
    • task.sys_class_name=incident
    • task.state IN [1,2]
    Change request: Step 1 [change_request] Conditions:
    • cmdb_ci=profile.applies_to
    • active=true
    		 For all these change requests, staging records are created in the [sn_oper_res_change_request] table.
    Change request: Step 2 (Optional) [task_ci] Conditions:
    • ci_item=profile.applies_to
    • task.sys_class_name=change_request
    • task.active=true
    Change request: Step 3 [task_cmdb_ci_service] Conditions:
    • cmdb_ci_service=profile.applies_to
    • task.sys_class_name=change_request
    • task.state IN [1,2]
    Outage
    • [cmdb_outage_ci_mtom] (cmdb_ci ←→ cmdb_ci_outage)
    • [cmdb_ci_outage] (cmdb_ci)

    For each record in [cmdb_ci_outage], one record is created in the [cmdb_ci_outage_ci_mtom] table. In [cmdb_ci_outage], for each affected CIs, a record is inserted in the [cmdb_ci_outage_ci_mtom] table.

    		 Conditions:
    • ci_item=profile.applies_to
    • outage.type IN [degradation, outage]
    • outage.end IS empty OR outage.end > now
    		 For all these outages, staging records are created in the [sn_oper_res_outage] table.
    Task [task] Conditions:
    • cmdb_ci=profile.applies_to
    • active=true
    • sys_class_name IN <list of classes fetched from property sn_oper_res.allowed_task_tables
    • As part of base system, it considers only problem records.
    		 For all these tasks, staging records are created in the [sn_oper_res_task] table.
    Operational vulnerabilities: Step 1 (optional) [sn_grc_case_mgmt_related_area] Conditions:
    • related_area=profile OR related_area=profile.applies_to
    • core_case.sys_class_name=sn_oper_res_vulnerability
    • core_case.active=true
    		 For all these vulnerabilities, staging records are created in the [sn_oper_res_vulnerability_profile] table.
    Operational vulnerabilities: Step 2 (optional) [sn_grc_case_mgmt_impacted_area] Conditions:
    • impacted_area=profile OR impacted_area=profile.applies_to
    • core_case.sys_class_name=sn_oper_res_vulnerability
    • core_case.active=true
    Third party risk assessments [sn_vdr_risk_asmt_assessment] Conditions:
    • applies_to IN [core_company, sn_vdr_risk_asmt_vendor_engagement]
    • state IN [5, 8, 9]
    • risk_rating_valid_to > now
    • risk_rating = highestRiskRating
    • vendor = profile.applies_to (Note: This condition is different than the applies_to field in the [sn_vdr_risk_asmt_assessment] table.)
    • engagement = profile.applies_to (Note: This condition is different than the applies_to field in the [sn_vdr_risk_asmt_assessment] table.)
    		 For all these assessments, staging records are created in the [sn_oper_res_tprm] table.