Domain scope
Domain scope defines what users can and cannot access.
Every user has two domain scopes when establishing a session in a domain-separated instance.
- Session scope is set upon session establishment to the domain listed in the user's user record. Users can manually change their session domain scope from the domain picker.
- Record scope uses the domain of the record and is active when viewing the form of any record.
By default, the record scope takes precedence over the session scope so that users in higher level domains adhere to each record's data and process constraints. However, these users can choose to expand or collapse the domain scope to show or hide data from other domains. For example, a user in the Service Provider (SP) domain also has visibility into child domains such as the ACME domain. When looking at an incident record from the ACME domain, the user can choose to expand the domain scope to show values from the SP domain or collapse the domain scope to show only record values that match the record's ACME domain.
Users with the domain_expand_scope user role can select the domain scope from the Toggle Domain Scope UI action on the form. When record scope is in effect, click the UI action to expand to session scope and display all data available based to the user's domain and child domains. When session scope is in effect, click the UI action to collapse to record scope and display only data that matches the current record's domain.
Record value selection from other domains
Users who can see multiple domains have the option to select record values from a domain that is different than the record's domain.
For example, service desk agents working for a service provider might want to assign certain incidents to themselves to resolve issues on behalf of their customers. When they do this, the incident Assigned to field might contain a user from the SP domain, even though the incident record itself is associated with a child domain such as ACME.
Selecting a record value from another domain does not change the record's domain. The record retains its original domain. When a user views a record with values from multiple domains, the user's domain visibility determines what they see.
| When these conditions are met | The user has access to these UI elements |
|---|---|
| The user has access to the domain of the current record referenced in a field. | The user can:
|
| The user does not have access to the domain of the current record referenced in a field. | The user can:
|
Domains and associated companies
With domain separation you can cascade changes you make to a company record to the domain and other records associated to the company.
By default, the system automatically assigns users to the same domain as their company. For example, all users of the ACME company automatically become members of the TOP/ACME domain.
When you change a company's domain, the instance automatically changes the domain of the following associated records to match the company's new domain.
- Locations
- Departments
- Groups
- Users
Domain deactivation and associated companies
When you deactivate a domain, the instance also automatically completes the following actions.
- Deactivates all companies in the domain.
- Prevents all users assigned to the inactive company from logging in.
For example, if you deactivate the ACME domain from the sample data, the instance also deactivates the ACME company, and the three sample users are locked out.