Domain management
Domain management lets a team maintain its own entities without being admins. It’s optional: if admins configure everything, no homes or roles appear and the studio looks unchanged.
How it works
An entity can be homed in a domain. Whoever manages that domain can edit the entities homed there — and nothing else.
Managing a domain takes two things: edit access to the domain record, and the Domain Manager permission set. A permission set alone manages nothing, and a share alone promotes nobody. Grant it from the domain’s Managers button, or with any sharing rule you already use.
| Role | Permission set | Can do |
|---|---|---|
| Admin | ContextWorks Admin | Everything: create domains, grant access, set homes |
| Domain manager | ContextWorks Domain Manager | Edit, activate, and delete entities homed in their domains; edit those domains’ rosters |
A manager can browse the whole studio. Outside their own domains the edit controls are disabled and the page says why.
Roster and home
What a domain carries and where an entity is homed are different relationships:
| Means | How many | |
|---|---|---|
| Roster | This domain carries this entity | Many-to-many |
| Home | This domain’s managers maintain this entity | At most one home per entity |
An entity can be in five domains and homed in none. Rehoming never changes what any agent receives. Homeless entities and object defaults are admin-owned: a default answers for the whole org, so it never belongs to one team.
Guards
- Rehoming needs both ends. Moving an entity between domains requires managing the domain it leaves and the one it joins.
- Deleting checks domains. An entity still carried by a domain you don’t manage needs an admin to delete — removing it would break that domain.
- A manager’s new entity must be homed in one of their domains. Creating an entity (+) or copying one prompts managers for a home; admins aren’t asked.
- Access granted elsewhere still counts. Any sharing rule giving someone edit access makes them a manager. The Managers dialog removes only the grants it made; it cannot revoke a sharing rule.
Where a manager’s scope ends
Anything shared across entities stays admin-only:
| A manager can | A manager cannot |
|---|---|
| Add any library element to their entities | Edit an element other entities already use |
| Create a new metric, formula, or enrichment | Create or delete domains |
| Edit their domains’ rosters | Grant access, including to their own domain |
| Activate, deactivate, and roll back their entities | Turn debug logging on or off |
| — | Allow unattended writes on a domain |
Creating elements is fine; editing a shared one needs an admin, because one team changing a metric’s filter would change every other entity using it.
The studio’s disabled buttons and the API’s refusals come from the same check, so calling the Apex directly gets the same answer as the page. Reads are never restricted.
Turning it off
Domain management is on by default. To turn it off, set entity_delegation_enabled to false.
While it is off, the manager permission set grants nothing, homes and manager assignment do not appear, and new domains cannot be created. Existing domains keep working. Nothing is destroyed: homes and assignments are kept and resume if you turn it back on.
Limitations
- Not data security. Managers change what agents see about records users can already access; every payload is still assembled as the calling user. See Security.
- Doesn’t restrict reading configuration. Managers can see every entity in the catalog.
- Auditing lives in versions — every activation records a comment and who published it.
What’s next
- Security
- Building domains — assigning managers and setting homes.