Administration
Roles and permissions from one catalogue
How access works
A permission grid, not a tier list
Roles are built by ticking named permissions, grouped exactly as the product's own navigation is grouped, so the grid reads like the app.
Roles you create
Every company starts with Admin, Manager and Guest, and can add as many of its own as it needs.
The same keys everywhere
One permission name controls the menu item, the route guard and the API check. Revoking it removes the link and closes the route and refuses the request.
Per-project access on top
Project Access is separate from role permissions, so someone with full project rights still only sees the projects they have been added to.
Locked users
Administrators can see which accounts are locked and unlock them, without going near the database.
Company settings kept apart
Company Settings and Billing are restricted to the Admin role specifically, not to any role that happens to have been given a lot of permissions.
Field-level change auditing
User record changes are recorded as who changed which field, from what value to what value, and when — scoped to your company.
The failure mode this design avoids
The usual way access control rots is that the menu, the front-end route and the back-end endpoint each get their own idea of who is allowed in. The menu item disappears, the route still resolves if you type the URL, and the API answers anyone who asks.
Matrix uses one catalogue of named permissions for all three. The sidebar hides what you cannot use, the route refuses to render it, and the endpoint checks again on its own — three layers reading one source, with the last one being the one that actually matters.
Granular by default, because the product is broad
A workspace that covers delivery, HR, CRM and assets needs real granularity: a scrum master should not see leave deductions, and a recruiter should not see project hours. Permissions are named per screen and per report rather than bundled into coarse tiers.
The grid is grouped by the same headings as the navigation — Personal, Project, Portfolio, Enterprise, Business, Talent, Asset, Reports, Admin, Settings — so building a role is a matter of recognising screens rather than decoding permission strings.
Administration: common questions
Can we create our own roles?
Does hiding a menu item actually prevent access?
Related
Security at Matrix
Data isolation, secure sessions, access control and auditing
Reports and analytics
Each report has its own permission
Designing a role and permission model
How to structure roles before you start ticking boxes
Or go back to all features.
Try it against your own work
A workspace takes a couple of minutes to create. Put one real project in it and see whether this shape matches how your team already works.