Data Separation / Visibility

The core rule: data rises up, processes flow down

• Members of a domain see data in their own domain and its child domains, plus global records. Users have no access to data in parent domains, peer domains, or other branches.
• A parent domain therefore sees all of its children's data by default, and a child never sees its parent's (non-global) data.
• Global is the absence of a domain on a record. Global records are available to every user unless security restricts them, so shared data lives there.

Domain assignment

Each record has one domain, stored in sys_domain. The value comes from, in practice: the user's company, a business rule, a module argument (sysparm_domain=sys_id), a form template, the parent record, or the domain on the user record. If none applies, the record takes the domain of the user who creates it.

• Users, groups, locations, departments, and CIs take their company's domain. Changing a company's domain cascades to its locations, departments, groups, and users, except records with Managed domain selected.
• Related records inherit the parent's domain (a change task from its change, attachments and emails from their record, task SLAs from their task).
• Deactivating a domain deactivates its companies, and their users cannot log in.

sys_domain and sys_domain_path

• Creating a Domain ID field named sys_domain automatically creates sys_domain_path. The domain paths query method (the default) uses it and is faster than older methods.
• The path is recalculated when the hierarchy changes and is not captured in update sets, so validate the hierarchy after importing update sets. Use sys_domain in scripts, never the path.

Visibility domains vs. Contains domains

• Visibility domains are a user-to-domain grant, added on User or Group records; group members inherit the group's visibility domains. They are always in effect regardless of the domain picker. Grant through groups, and use them sparingly.
• Contains is a many-to-many, domain-to-domain relationship: when domain A contains B and C, users in A see data from all three. It is controlled by the domain picker and affects data only, never processes. Many Contains relationships create slow OR queries, so treat them as exceptions.
• The parent-child hierarchy itself comes from each domain's Parent field, not from Contains.

Domain scope

• Every session has a session scope (the user's domain, changeable with the domain picker) and a record scope (the record's domain, used when a form is open). By default the record scope wins.
• Users with domain_expand_scope can use Toggle Domain Scope to expand to session scope or collapse to record scope.
• By default, reference picker and related list data on a form are limited to the record's domain (glide.sys.domain.use_record_domain_for_data).

Global, Default, and TOP

• Global: the absence of a domain; available to all users.
• TOP: the conventional primary process domain. It holds processes and overrides and should never contain users.
• Default domain: tasks and users with no domain are placed here automatically (Domain - Default - Task and Domain - Default - User). Only admins see it by default. Records in Default signal a configuration problem to triage. If no Default domain is set, those records go to global.
• User placement: user records belong in customer domains (occasionally data domains), never in global or process domains. Only admin accounts belong in global.

Domain-separating a custom table

Add a field named sys_domain of type Domain ID (the name is reserved, so no u_ prefix is added and sys_domain_path is created too). Add business rules like Domain - Set Domain - Task and Domain - Default - Task so new records get the right domain. Do not domain-separate base system tables, and never sys_ tables such as sys_dictionary. The platform blocks separation of ACLs, script includes, system properties, and dictionary tables.