Roles bundle permissions. Allocadia ships standard roles and lets admins grant per-hierarchy access to control what each user can see and do.
Role vs per-hierarchy permission
A user's access in Allocadia is governed by two things:
- Role — the user's assigned role (Admin, Owner, Viewer, etc.) determines what they can do.
- Per-hierarchy permission — on which specific Folders/Budgets they're granted access. A user can be an Owner on Budget A but have no access to Budget B.
The combination determines effective access.
Standard roles
Role names and exact permissions vary by account configuration, but the common pattern:
- Admin — full system access, including user management, Master Settings, and all hierarchies.
- Owner — full control over hierarchies they're granted (edit Line Items, approve PRs, delete, etc.).
- Collaborator / Contributor — can edit within granted hierarchies but has limited admin actions.
- Viewer — read-only access to granted hierarchies.
Some accounts also have custom roles tailored to specific workflows (Finance Approver, PR Submitter, etc.).
Granting permission on a hierarchy
Admins grant hierarchy access from the Home page's Manage Users column, or from inside the hierarchy via its User Management action:
- Click Manage Users → invite or edit.
- Add the user and set their effective role for this hierarchy.
- Save.
The user sees the hierarchy on their Home page immediately after being granted access.
Removing access
Remove a user from a hierarchy via the same Manage Users interface. Removal doesn't delete the user's account — only their access to that hierarchy.
Impact of role changes on existing ownership
Changing a user's role doesn't automatically transfer their owned objects (Line Items they created, PRs they submitted). Those remain tied to the user. If a user is leaving the organization, consider reassigning ownership before deactivation to keep records cleanly attributable.
Comments
Please sign in to leave a comment.