Domain separation hierarchies
Create a hierarchy when defining a domain architecture to track your processes and workflows.
Sample domain separation hierarchies
- In the following example, TOP is a process domain. It should never contain users. Rather, TOP should contain the new processes that instance owners develop and the overrides to these processes from the global domain.
- Only the service provider (SP) has access to the default domain. This domain never
contains active users. It contains only the "lost" data that you need to reassign to the
correct domain. 注:When data is not assigned to a specific domain, it moves to the default domain. It is temporarily "lost" and needs to be assigned to its correct domain.
- Tasks and users without a domain are placed in the default domain automatically when
you create or update domains. You can override that action by either clearing the
Default option on this record or selecting the
Default option on another domain record. If you have not set a
default domain yet, tasks and users with no domain move to the global domain.
- Don't move data between domains while you are using the instance.
- If any data ends up in the default domain, that means you have a configuration or procedural problem to address.
You don't see the word "Global" in this diagram because there is no global domain. Remember that "global" is the absence of a domain on a record.
For example, a table that has no domain field means that the table contains all global records. A table that has a domain field means that any record without a domain is a global domain.
The word "global" is in the domain field. It is placed there automatically when the record has no domain.
- Use the default domain to make sure that records do not end up in the global domain on tables that should never have global records.
- Instance owners must then triage the records in the default domain and move them to the correct domain.
Domain hierarchies
- Parent/child: Process and data affected
- Design that is based on a process flow.
- Remember that the parent domains can access all data in the child domains.
- "Contains" domain: Only data is affected. For example, making SP in the diagram
contain TOP does not make processes in SP run in the TOP domain and downward.
- Grants data access rights to individuals in groups that require dedicated access to certain domains.
- Contains causes or conditions to be added to database queries that can cause performance issues with large domain and data sets.
- Visibility: Hierarchy that is always visible to users once you provide access. Only
the data is affected, not the processes.
- Grants data access of a domain to another domain that did not have that access when the parent-and-child hierarchy was built.
- Enables users to see all the data in the domains that they have visibility access
for, all the time, regardless of the record they are working on. 注:Use sparingly, as Visibility can allow complete access that you may not intend.
Basic principles of defining a domain hierarchy
Unrestricted and restricted use cases for domain separation.
Many SPs have customers who implicitly state that access to their domains must be tightly regulated, which constrains the use of the “contains” function at the TOP domain. The following diagram explains how to mitigate that regulation by dividing domains into Restricted and Unrestricted domains.
Customers exist in a specific "vertical" of the domain separation hierarchy. This means they only consume processes defined in their domain and all parent domains above theirs in the hierarchy. Any processes defined in domains that are not in their linear parent-child hierarchy do not apply.
注:Customers or "tenants" are entities that are segregated from each other completely, not like departments or business units that share resources with each other.- Super verticals (restricted, manager services, and so on) are allowed as long as the customers only ever belong to one of them.
- Services, products, or offerings that need to be horizontally available to all customers are not defined within separate domain hierarchies.
- Under TOP, you might create two domains, Unrestricted and Restricted.
- Place customers and their domains that don't have SP visibility restraints under Unrestricted.
- Place customers and their domains that do have that requirement under Restricted.
- System admins can then use “contains” and “visibility” functions in an efficient, targeted manner.
- Apply "contains" to Unrestricted, so a single “contains” can grant visibility to most customers.
- Apply domain visibility using ”domain visibility groups” to specific domains as needed.
The following diagram delineates how to choose which hierarchy model is right for you. You can choose separate hierarchies, hybrid, or shared hierarchies depending on which processes and functionality you want in your domain structures.
To learn more about hierarchy architecture, see Service provider reference architecture.