Domain separation and Site Reliability Operations
Domain separation is supported for Site Reliability Operations. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.
Support level: Basic*
The support level is Basic but has some exceptions or special conditions.
- Business logic: Ensure that data goes into the proper domain for the application’s service provider (SP) use cases.
- The user interface, cache keys, reporting, rollups, and aggregations all use the domain at production run time.
- The owner of the instance must be able to set up the application to function across multiple tenants.
Sample use case: When an SP uses chat to respond to a tenant-customer’s message, the client must be able to see the SP's response.
For more information on support levels, see Application support for domain separation.
Site Reliability Operations overview
- Domain separation is present in all metadata tables in the application. Instance level tables also have domain separation explicitly. Other internal tables, such as the internal Team Request table, are domain-separated implicitly by referencing domain-separated records.
- System properties are not domain-separated, which has implications for Team Management features. The properties are shared by multiple domains and are set at the instance level. Domain-specific setup for these is not supported.
- Where another application is being leveraged (for example the Event Management Connectors) domain separation is determined by the domain-separation capabilities of that application.
How domain separation works in the Site Reliability Operations application
The specific conditions indicated by the Basic* support level rating above relate to team
management:
- New teams are created through a catalog item backed by an Integration Hub flow. The sro_admin must set up the flow and can initiate it from the Service Portal or through the Site Reliability Operations workspace. Instructions appear in the setup guide.
- Integration Hub subflows and actions control management of Site Reliability Operations teams.
- Only one catalog item and flow can be set up for each instance. The customer is responsible for setting up team properties to support domain separation as a customization of the existing flows.
- The requestor of a team catalog item is associated with the domain and is available as part of the request item. As a result, if needed, the requester can create the team in a specific domain or the catalog Item and extend it to capture the domain another way. In either case, the sro_admin must make changes to the Integration Hub flows and actions to support this.
Domain-separated tables
- Action (sn_sro_act)
- Condition (sn_sro_cnd)
- Integration (sn_sro_em_integration)
- Integration Action (sn_sro_em_int_act)
- Configuration (sn_sro_cfg)
- Configuration Variable (sn_sro_cfg_var)
- Service Metrics (sn_sro_service_metrics)
Learn more by seeing the Domain separation and On-Call Schedulingtopic.