Permission Model
Enforcement layers
| Layer | What it protects | Examples |
|---|---|---|
| authentication | who is signed in | authenticated docs and APIs |
| role guard | broad capability | AdminRoute, SuperAdminRoute, backend admin permissions |
| company isolation | which company data is reachable | active company, superadmin global vs company mode |
| tag visibility | which tenant or flow subset is visible | VisibilityMode.ALL, VisibilityMode.TAGGED |
| focused scope | narrower UI path for limited users | /focused/* routes |
| restricted resources | sensitive content inside visible objects | payloads, custom_headers |
Visibility mode matrix
| Visibility mode | Meaning | Typical result |
|---|---|---|
all | user may see the whole allowed company scope | broad tenant visibility |
tagged | user sees only tagged subset | narrower tenant, flow, and message visibility |
Restricted resource matrix
| Resource | User can still see object? | Sensitive content hidden? |
|---|---|---|
payloads | often yes | payload content and download can be blocked |
custom_headers | often yes | header values can be replaced with *** |
Company isolation
Company isolation is not only a UI concept. It is reinforced through:
- active company selection
- scoped querysets
- dedicated admin vs superadmin endpoints
- per-company user tag policy and assignments
Superadmin difference
Superadmin can operate in two effective modes:
- global mode
- company mode
That distinction matters because a superadmin identity does not always imply a global current data scope in the UI.
Cross-links
- Product-facing role summary: Product Docs Admin Reference
- Resource masking in operations: Message Popups Permissions