Team and roles
Two levels of permission — workspace and project — and which one actually decides what someone sees.
Krrim has permissions at two levels, and confusing them is the source of most "why can't they see this" questions.
Workspace roles
Set in Settings → Members. This decides what someone can do to the workspace.
| Role | Can |
|---|---|
| Owner | Everything, including billing and deleting the workspace |
| Admin | Manage members, create projects, change workspace settings |
| Member | Work in projects they belong to; create projects if allowed |
| Guest | Only what guest access permits |
There is exactly one owner path — ownership is transferred, not shared.
Project roles
Set per project in Project → Members. This decides what someone can do inside one project.
| Role | Can |
|---|---|
| Lead | Manage the project's settings, members, statuses and workflow |
| Contributor | Create and edit tasks, comment, log time |
| Reporter | Create tasks and comment; cannot change others' work |
| Viewer | Read only |
Which one decides visibility
Project membership decides what someone sees. A workspace Member who is not in a project cannot see its tasks — they do not appear in search, in reports or at a guessed URL.
A workspace Admin can add themselves to any project, which is a different thing from seeing it by default. The difference shows up in the audit log, where it belongs.
A task in a project you cannot see returns "not found", not "no permission". Confirming that a task exists but is out of reach is itself a disclosure — and on a workspace with clients in it, that disclosure matters.
Changing roles
Both levels can be changed at any time and take effect immediately. Demoting someone does not remove their history: their tasks, comments and time entries stay attributed to them.
Removing someone
Removing a person from a project revokes their access to it at once. Removing them from the workspace revokes everything.
Their work stays. Tasks they created keep their name on them, comments remain, and time entries stay in reports — deleting the record because the person left would silently change history.
Reassign anything currently assigned to them before you remove them, or it lands in the unassigned queue.
Service accounts
An API token authenticates a service account — a workspace member that is not a person. It holds a role you choose, appears in audit rows by name, and cannot sign in.
This is why offboarding someone never breaks a production integration: the integration was never running as them.