Hierarchy and Delegations
These features support organizations that need formal reporting structures and the ability to temporarily share permissions between users.
Organizational Hierarchy
A hierarchy models your organization’s reporting structure as a tree. Each node represents a position, department, or team — and users are assigned to nodes to reflect where they sit in the organization.
Example Structure
CEO
├── VP Operations
│ ├── Warehouse Manager — Algiers
│ ├── Warehouse Manager — Oran
│ └── Logistics Coordinator
├── VP Finance
│ ├── Head of Accounting
│ └── Financial Controller
└── VP Sales
├── Regional Manager — East
└── Regional Manager — West
Why Use a Hierarchy
The hierarchy serves several purposes within Beelocity’s access control:
| Purpose | How it works |
|---|---|
| Scope-based access | A manager can be granted access to all records created by anyone in their subtree — everyone who reports to them, directly or indirectly. A VP Operations would see records from all three people under them. |
| Organizational visibility | Hierarchy nodes can be referenced in policies and row access rules for dynamic, structure-aware access control. |
| Approval routing | Purchase orders or adjustments can be routed to the user’s direct manager for approval, following the tree upward. |
| Reporting structure | The hierarchy gives everyone a clear picture of who reports to whom, useful for both access control and day-to-day communication. |
Setting Up the Hierarchy
-
Go to Access Control > Hierarchy Nodes to create the tree structure.
- Create top-level nodes first (e.g., “CEO”, “VP Operations”).
- Add child nodes under each parent to build out the tree.
- Each node has a name, an optional type (department, division, team, position), and a parent node.
-
Go to Access Control > User Hierarchy Assignments to place users in the tree.
- Assign each user to one or more nodes.
- Optionally mark a user as the manager of a node — this is the person who holds that position or leads that team.
A user can be assigned to multiple nodes (e.g., someone who manages two teams). Nodes without users are valid — they represent unfilled positions or organizational placeholders.
Delegations
A delegation is a time-bound grant where one user shares some or all of their permissions with another user. Think of it as a formal “out of office” handover — the delegating user’s permissions are temporarily extended to someone else, with a clear start and end date.
When to Use Delegations
| Scenario | How delegation helps |
|---|---|
| Vacation coverage | A procurement manager going on leave delegates their approval authority to a colleague for two weeks. |
| Project empowerment | A director temporarily gives a team lead elevated permissions to manage a specific initiative without permanently changing their role. |
| Organizational transitions | During a reorganization, permissions can be temporarily shared to ensure continuity while roles are being redefined. |
| Training and shadowing | A senior staff member delegates permissions to a trainee so they can practice with real data under supervision. |
Creating a Delegation
- Go to Access Control > Delegation Grants.
- Select the user to delegate to — the person who will receive the permissions.
- Choose which permissions to share — you can delegate all of your permissions or select a specific subset.
- Optionally scope the delegation to a specific hierarchy node — this limits the delegation to records within that part of the organization tree.
- Set a start date and end date — the delegation is only active during this period.
- Optionally add a reason — document why the delegation exists (e.g., “Covering Fatima’s parental leave, March 1-31”).
How Delegations Work
- The delegated user gains the selected permissions for the specified period in addition to their own permissions. Their existing access is not affected.
- When the end date passes, the delegated permissions are automatically revoked — no manual cleanup needed.
- Delegations are logged for audit purposes — you can always see who delegated what to whom and when.
Tips
- Keep the hierarchy simple — model your actual reporting structure, not an aspirational org chart. 3-5 levels deep is typical. Excessively deep trees are hard to maintain and reason about.
- Update assignments when people move — the hierarchy is only useful if it reflects reality. When someone changes teams or gets promoted, update their node assignment.
- Always set end dates on delegations — open-ended delegations defeat the purpose. Even if the end date is far in the future, having one ensures the delegation does not linger indefinitely.
- Use the reason field — six months from now, “Covering Ahmed’s paternity leave” is much more useful than an unexplained delegation grant.