Roles and permissions
Permission models usually ship as three roles and a shrug. Here there are 64 discrete permissions, five roles to start from, and a written floor underneath all of them.
Five roles come with the product: Administrator, Employee, Manager, HR Manager and Accountant. The first two are system roles. Custom roles can be created alongside them.
Each role shows how many of the 64 permissions it holds and how many people are in it, so a role is readable at a glance.
Permissions are grouped by area. Attendance and shifts, device sync, leave, daily recap, projects and boards, capacity planning, project health, clients, meetings, benefits, devices, checklists, policies, skills, awards and feedback each get their own set.
Underneath sits an EVERYONE CAN floor. Marking your own attendance, asking for leave, logging your own recap for the last five working days, editing your own profile, seeing your own device, seeing your own projects, commenting on tasks you can see, and reading the team list.
The product calls that floor not permissions, and says it cannot be removed. So no role setup can leave somebody unable to ask for a day off.
That is a better idea than it sounds. Most permission bugs are somebody locked out of their own record, and a written floor makes that case impossible rather than merely unlikely.
Changes take effect at next sign-in rather than mid-session.
Sign-in itself has no password to leak. People enter a one-time code sent to their work email, and the role they hold decides what opens next.
What it does
- 64 permissions, 5 roles
- Each role reports how many of the 64 it holds, and how many people sit in it.
- Grouped by domain
- Separate sets for attendance, leave, projects, clients, meetings, devices, checklists, policies and more.
- A baseline nobody loses
- The EVERYONE CAN floor covers your own attendance, leave request, recap, profile, device, projects and the directory.
- Custom roles
- Build a role beside the five, starting from one that already exists rather than from nothing.
What it needs before it works
- Decide what a manager is in your company before you build the role. The grid will hold whatever you choose, which is the problem.
- Departments and reporting lines matter, since much of what a manager should see follows from them.
- Start from a system role and adjust. Building a custom role from nothing across 64 switches invites a gap.
- Tell people changes land at next sign-in, so nobody reports a bug that is a session.
- Write down why each role exists. A grid of 64 switches with no note beside it is unreadable six months later, even to whoever set it up.
Questions people ask
Can a role be stripped back so someone cannot request leave?
No. Requesting leave sits in the baseline the product describes as not permissions and not removable, alongside marking your own attendance and reading the directory.
Where are access rules enforced?
In the database as well as on screen. Row-level security sits under the data, and each customer's data lives in its own database.
When does a permission change take effect?
At the person's next sign-in. A change made while somebody is working does not alter their current session.