Domain separation
How domain separation isolates data and process for multiple business units or customers, and when it is the wrong answer.
How domain separation isolates data and process for multiple business units or customers, and when it is the wrong answer.
- Domain separation is a platform level decision, not a per table setting
- Process separation costs maintenance, use it sparingly
- Users inherit domain from their user record, groups can override it
- Reversing domain separation is a project, not a configuration change
What it does
Domain separation partitions data and configuration by domain so a user in one business unit sees only their records, while a support group at the top of the tree can see everything below it. It is used by managed service providers and by groups that cannot legally share data.
Data versus process separation
Data separation splits records. Process separation goes further and lets each domain have its own business rules, workflows, catalog items and SLAs. Process separation multiplies the amount of configuration you maintain, so turn it on only where a domain genuinely needs different behaviour.
Before you enable it
It changes every query on the instance and cannot be reversed cleanly.
- Model the domain tree first, including the global domain at the top
- Decide which tables stay global, for example the CMDB is often shared
- Plan how users get their domain, usually from the company or department on sys_user
- Test reporting early, cross domain reports need a visibility domain