Domain management
Domain management lets a team maintain its own entities without making anyone an admin. 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 edits the entities homed there, and nothing else.
Managing a domain takes two grants: edit access to the domain record, and the ContextWorks Domain Manager permission set. The permission set alone manages nothing; edit access alone promotes nobody. Grant edit access from the domain’s Managers button, or with any sharing rule your org already uses.
| Role | Permission set | Can do |
|---|---|---|
| Admin | ContextWorks Admin | Everything: create domains, grant access, set homes |
| Domain manager | ContextWorks Domain Manager | Create domains; edit, activate and delete entities homed in theirs; set those domains’ rosters, identity, meaning, write access and who may discover them |
A manager can browse the whole studio. Outside their own domains, ContextWorks disables the edit controls 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.
Admins own homeless entities and object defaults. 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 new entity gets a home as you create it. Creating an entity (+) or copying one prompts a manager to pick one of their domains; 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 | Assign the Domain Manager permission set |
| Create domains, and name and describe theirs | Change which domain is the org’s Default |
| Set their domains’ roster, meaning and write access | Delete a domain |
| Allow unattended writes on their domains | Turn debug logging on or off |
| Say who may discover their domains, and add co-managers | Change the org-wide write switch or the per-call record cap |
| Activate, deactivate, and roll back their entities | — |
Creating an element needs no admin. Editing one that other entities already use does: change a metric’s filter for one team and every entity using it changes too.
A manager owns their own domains: what each one carries, what it means, its name, what it may write, and who may discover it. Admins keep the org-wide switches (the default domain, the write switch, the record cap, logging) and deleting domains.
Delegating access grants is safe. A grant decides what a user may discover, never what they receive: ContextWorks assembles every payload as the calling user, so two people holding the same domain still get different records. → Security
Every manager of a domain is equal. Two people assigned to Marketing can both add users to it, both add a third manager, and both change everything it carries. Neither is the junior one.
Admins keep the brake that matters. Only an admin assigns the ContextWorks Domain Manager permission set, so a manager can say which domains a colleague manages but can never make someone a manager in the first place.
The studio’s disabled buttons and the API’s refusals come from the same check, so calling the Apex directly gets the same answer the page gives. Neither one restricts reading.
The rules on removing a domain or an entity hold outside the app too. A trigger on each object enforces them, so a list view, Data Loader and the REST API all give the same answer the page does.
The permission set cannot carry that rule. Managers hold Modify All on both objects so that every manager of a domain can administer it, and Salesforce will not grant Modify All without the removal permission alongside it.
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 nobody can create a domain. Existing domains keep working.
Turning it off destroys nothing. ContextWorks keeps every home and manager assignment, and both take effect again when you turn it back on.
Limitations
- Not data security. Managers change what agents see about records users can already access, and ContextWorks still assembles every payload as the calling user. See Security.
- Configuration stays readable. 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 — how payloads stay permission-correct.
- Building domains — assigning managers and setting homes.