Permissions
The module token that sets your ceiling, the per-entity tags that grant beneath it, and how the two resolve.
DFC access is granted by role, like every other module, but it has a second layer that most modules do not: you can grant on individual entities rather than on DFC as a whole.
Two layers
The module token is the ceiling. A role holds one of five, and it caps everything that role can ever do in DFC:
| Token | What it allows |
|---|---|
| Admin | Everything, including the Permissions tab |
| Entity Editor | Change entities and their schemas |
| Item Creator | Create items |
| Item Editor | Change existing items |
| Item Viewer | Read only |
A role with no DFC token has no access at all, whatever else is configured for it.
Entity tags grant beneath that ceiling. A tag sits on one entity and carries a level, and it applies to that entity and everything under it. This is how you let the team that owns closures edit closures without handing them routing.
How the two resolve
For any entity, the nearest tag on itself or its ancestors wins, and the result is then capped by the module token. So a tag cannot promote someone above their ceiling: an Item Viewer tagged as an editor on one entity is still a viewer.
Because tags inherit downwards, one grant on a parent covers its children, which is the permissions half of Hierarchy and inheritance.
A tag can be set to deny, meaning no access here or below here. It is deliberately not part of the level scale, so it is never compared against one: a deny nearer the entity cuts off access granted higher up, rather than being outranked by it.
Two flags that sit outside the scale
- Approver is set per entity, and marks a role as able to approve changes to it. That is what connects permissions to Change management and audit.
- Bulk is a separate capability for bulk editing, independent of level.
Moving permissions between instances
Permission sets export and import like configuration does. Grants travel keyed by entity path rather than entity id, because ids differ between instances while paths do not. A grant whose path does not exist in the target is reported as skipped rather than applied somewhere wrong.
That is a missing module token rather than a missing tag, and it is also why the whole DFC section disappears from the navigation rather than appearing empty. On the demo instance, raise a case to have it granted.
This is the short version. Designing a permission model properly, and the approval flows that go with it, is its own workshop.