[object Object]

The MSP onboards its tenth tenant and discovers that every customization, every dashboard, every workflow is a per-tenant artifact requiring per-tenant maintenance. The Domain Separation feature is doing what it advertises — isolating data — but the operational model assumed shared everything and got nothing. Designing for domain separation from day one is a different exercise than retrofitting it.

Decide what is shared vs tenant-specific

Three layers exist: the global domain (platform-wide), shared services domain (configurations all tenants inherit), and per-tenant domains. Decide which artifacts live where: workflows, business rules, UI policies, knowledge bases, catalog items, dashboards. Defaults of shared maximize maintainability; defaults of tenant-specific maximize flexibility. Pick the bias and document exceptions.

Global: platform tables, core ACLs, system properties
Shared: standard ITIL workflows, branded portal templates, audit reports
Tenant: tenant logo, custom catalog items, tenant-specific PA dashboards

Domain hierarchy with override semantics

The domain hierarchy supports inheritance with override. A workflow defined at “Shared” applies to all tenant domains unless overridden. Use this aggressively for the 80% case and let tenants override the 20%. A tenant that requires a custom workflow gets a domain-scoped override; the shared workflow remains the default for the rest.

Reference data is the trap

Choice lists, assignment groups, locations — reference data accessed across tenants. If tenant A’s “Hardware” category choice value is the same record as tenant B’s, an edit by tenant A admin affects tenant B. Either segregate reference data per tenant (more isolation, more maintenance) or lock reference data to global-domain-only edits (less isolation, less drift). Mixing produces silent cross-tenant interference.

Visibility ACLs are not the same as data ACLs

Domain Separation isolates data via the sys_domain field on every record. Visibility ACLs (read access) honor domain by default. Write ACLs may or may not, depending on configuration. Test write paths explicitly per role per domain. The most common leak is a script include that runs in elevated context and writes to the wrong domain because the executing user’s domain context was assumed but not set.

// Always set domain context explicitly in privileged scripts
gs.getSession().setDomain(targetDomainSysId);
try {
  doPrivilegedWork();
} finally {
  gs.getSession().setDomain(originalDomainSysId);
}

Tenant onboarding as a workflow

Onboarding a tenant should be a documented automated flow — create domain, provision admin users, copy template configurations, attach to shared services, run smoke tests. Every manual onboarding is a place for inconsistency. Build the workflow once, version it, and run new tenants through it without exception. The tenth tenant onboarded by checklist looks nothing like the first.

Reporting and analytics across tenants

The MSP’s own operations team needs cross-tenant views (overall volume, top tenants by ticket count) without exposing per-tenant data inappropriately. Build aggregation reports at the global domain that read from tenant domains via privileged service accounts. Publish only aggregated metrics; raw cross-tenant tables are a confidentiality risk if access slips.

Common failure modes

Background scripts run in global context that update tenant data — easy to write, leaks data if logic is wrong. Always run in the target tenant’s domain context. Knowledge base shared across tenants without per-tenant filtering — tenant A users see tenant B documents. Use the knowledge base’s can_read_user_criteria per tenant. Notification templates written in shared scope referring to tenant-specific fields that may or may not exist — split templates per tenant or guard field references defensively.

Implementation sequence

Stand up two tenants end-to-end before claiming Domain Separation works. Two reveals every shared-vs-tenant decision; one reveals nothing. Validate cross-tenant isolation with a deliberate negative test (tenant A admin attempting to read tenant B record should be denied at the API level, not just hidden in UI).

What changed in 2026

Workspace experiences in Next Experience honor domain context for sidebar configuration in addition to data. Older Service Portal sidebars often were configured globally, creating cross-tenant UX confusion. If you are upgrading, audit the sidebar configuration per tenant.

What to do this week: pick one privileged script include and trace whether it sets domain context explicitly; the ones that don’t are your audit list.

[object Object]
Share