Everyone in one list, with the access you actually granted
Add people, put them in departments, and give them a role. Access comes from the permission list stored on that role — a base role of Admin, Manager or Employee is a starting template and grants nothing on its own.
Unlimited roles and unlimited departments on every plan term.
The problem
Access usually ends up broader than anyone intended
Most systems treat a job title as a permission set. That is convenient on day one and wrong by month six, when the person who needed one extra screen was made an administrator to get it.
- Somebody needed to view reports, so they were made a manager — and can now reassign anyone’s work.
- A narrowed role quietly gets its full access back the next time the product adds a permission key.
- A manager who can edit roles can add permissions to their own role and sign back in with more access than they were given.
- Nobody can answer "who can see the audit log" without opening five profiles.
- Onboarding twenty people means creating twenty accounts by hand, one form at a time.
How TaskIt handles it
Permissions come from one place and only one place
A person’s access is the permission array stored on their role, resolved against the known key set. Nothing is implied by their base role, and nothing is granted because of who they are.
- Admin, Manager and Employee base roles as seeding templates, plus unlimited custom roles built from individual permission keys.
- A narrowed role stays narrowed — a short permission list on an Admin role genuinely means less access, permanently.
- You cannot grant a permission you do not hold yourself, modify a role that holds permissions you lack, or change your own role.
- You cannot modify an account more privileged than your own — on update, delete, or spreadsheet import.
- Permission changes reach signed-in users on their next token refresh, so a correction takes effect without asking anyone to sign out.
What you get
Least privilege that survives an upgrade
Because a base role grants nothing at runtime, a role that was deliberately narrowed does not silently reacquire every newly added permission key. That class of privilege creep is closed by design.
Departments that drive real behaviour
A department is not a label. It decides who is eligible for that department’s task queue, whose work rolls into department reports, and which teams a manager may assign to.
Onboarding a team in one pass
Smart Import reads a spreadsheet of people and creates their accounts, with the same authorisation rules applied to every row as if you had created them one at a time.
Leavers are handled, not deleted
Deactivating a person removes their access and stops them being billed as an active member, while everything they did stays attached to the tasks they did it on.
How it works
In the order a person using it meets them.
- 1
Create the departments first
Departments decide task eligibility and reporting, so setting them up before people means nobody has to be reassigned a week later.
- 2
Build the roles you actually need
Start from a base role as a template, then add or remove individual permission keys. A role that only needs to view reports should hold only that.
- 3
Add people, or import them
Add individuals from the team page, or run Smart Import against a spreadsheet. Each person gets a role and a department, and their credentials can be delivered over WhatsApp.
- 4
Adjust as the team changes
Move someone between departments and their task queue changes immediately. Deactivate someone who leaves; reactivate them if they come back.
Setting up a 24-person business
What the first hour of a workspace usually looks like.
- 1
Four departments
Operations, Accounts, Design and Field. These become the task queues and the reporting lines.
- 2
Three roles, not three job titles
Administrator (everything), Supervisor (assign within their department, view reports, no audit log), Staff (their own work plus their department’s queue).
- 3
One spreadsheet
Twenty-four rows of name, email, phone, role and department, imported in one pass. Credentials go out over WhatsApp.
- 4
One correction on day three
A supervisor needs the audit log. Rather than making them an administrator, the audit permission is added to a copy of the supervisor role.
- 5
One transfer in month two
A field technician moves to Operations. Their old department queue disappears and the new one appears the moment the change is saved.
The result
Nobody holds a permission because of their title, and the person who needed one extra screen got one extra permission.
Roles and permission keys
A role is a name plus a list of permission keys. Unknown or internal keys are refused rather than stored, so a hand-edited row cannot inject a permission the product does not recognise. Roles are unlimited on every plan term.
- Task permissions — create, assign, view all, review
- Report permissions, which also gate the performance figures
- Audit-log viewing, which is an explicit permission rather than an admin assumption
- Media Library permissions — view, upload, download and delete, each separate
Escalation guards
Holding the role or user permission used to be equivalent to holding every permission, by two different routes: editing your own role, or assigning yourself a more powerful one. Both are closed, and the rules are pure functions with their own unit tests rather than checks scattered through controllers.
- You cannot edit or delete the role you are currently assigned
- You cannot grant a permission you do not yourself hold
- You cannot assign a role with permissions beyond your own — including through spreadsheet import
- You cannot deactivate or delete yourself
Smart Import for spreadsheets
Import an existing staff list rather than retyping it. The import applies exactly the same authorisation rules as creating each user by hand, so it cannot be used as a side door to create an account more privileged than the importer’s own.
Headcount and billing are the same number
Billing is per active team member, derived live from the team page. Adding, deactivating or removing someone is reflected on the next invoice without anyone adjusting a setting, and the subscription page shows the current headcount and what the next invoice comes to.
Frequently asked questions
No. The base role is a template used when a role is first seeded, and a display hint for the interface. At runtime, access comes from the permission list stored on the role — so an Admin role whose list has been shortened genuinely has less access.
No. You cannot edit the role you are currently assigned, you cannot grant a permission you do not already hold, you cannot modify a role that holds permissions you lack, and you cannot change your own role or assign yourself one that exceeds your access.
On the user’s next token refresh, not only on a fresh sign-in — so a newly granted permission becomes usable without asking the person to sign out and back in.
Nothing is deleted. Deactivating a person removes their access and stops them counting toward billing, while every task they raised, accepted, handed over or completed keeps their name on it in the history and audit trail.
Where to go next
The capabilities either side of this one, and the problems it is bought to solve.
Set up your team in one sitting
Departments, roles and an imported staff list are usually an hour’s work — and the trial gives you thirty days to change your mind.