Initial Domain Setup and Architecture

Enabling domain separation

• Request the Domain Support - Domain Extensions Installer plugin (com.glide.domain.msp_extensions.installer), usually called the Domain Separation plugin, before activating com.snc.pa.domain_support. Activate it at the start of an implementation, ideally before other plugins. Enabling it late puts every existing record in global.
• Domain separation can be disabled but cannot be removed from an instance. For a live instance, the Post-Production Domain Separation Activation Utility (com.glide.domain.activation_utility) gives a guided setup.
• The plugin adds the domain_admin role (create, edit, delete domains), sys_domain on tables such as groups, group members, companies, locations, departments, role assignments, emails, attachments, and reports, the task_for field on Task, and the Domain business rules.

Creating the hierarchy

• Domains are created under All > Domain Admin > Domains. The form has Name, Type (Vendor, Customer, MSP by default), Primary, Default, Parent, Active, and Description, with Companies, Contains Domains, and Contained By related lists.
• Only one domain can be Primary (the top of the domain map, with no parent and at least one child) and only one can be Default.
• The Domain Map (Domain Admin > Domain Map) is a read-only picture of active domains with a Parent (only the primary domain may have no parent).
• Deactivate domains you no longer need; do not delete them. The Delete by domain cleanup queue removes inactive leaf domains in a controlled way.
• Change the hierarchy rarely and in small batches; each change triggers cascade updates (Domain Work Requests). The Domain Job Manager can pause and queue these jobs.

Domain picker and properties

• The domain picker sets the session domain. The domain reference picker (glide.ui.domain_reference_picker.enabled) suits long domain lists. glide.ui.polaris.domain_picker.role controls who sees the picker in Next Experience (itil and admin by default).
• The number of domains does not hurt performance as much as what they contain; avoid loading many domains (over 30) by import without testing.

Architecture guidance

• Use domain separation when tenants need data segregation, provider-managed per-tenant processes, and some global processes and reporting on one instance. Use separate instances when tenants need total separation of system properties or physical database isolation.
• Typical hierarchy: global, then TOP (process domain), then customer domains, with a Default domain for lost records. Restricted and Unrestricted branches under TOP let one Contains grant reach most customers.