Users & permissions

This page is for administrators. It covers accounts, the role model, groups and fine-grained permissions, all under the Admin area.

Users

Manage accounts under Admin → Users. The list searches by name or email, filters by role, and shows how many accounts you have against your limit if one is set.

Creating a user asks for an email, a name and a password — you can generate one — or you can skip setting a password and have TaskFlow email the person a link to set their own. That's usually the better option: nobody has to send a password over chat.

For an existing account you can:

• Edit the display name and global role.
• Disable sign-in — the account and its history stay, the person can't get in.
• Set a password directly, or send a reset link by email.
• End all sessions — sign the account out everywhere, immediately. This is the right response to a suspected compromise.
• Issue an API token — useful for a dedicated bot account (see AI & API access).

Account limits

If your instance has a licensed user limit, the user list shows the count against it. A seat is an active non-customer account: disabling an account frees its seat, and Service Desk customers don't consume seats at all.

Global roles

Every user has one global role setting their baseline capabilities:

Role	Can
Admin	Everything — manage users, roles, all projects and system settings.
Manager	See all projects, manage members, grant project-level access.
Member	Create projects and work in the ones they belong to (the default).
Viewer	Read-only; cannot create projects.
Customer	Use the Service Desk portal only; submit and track their own requests.

Customers are a separate world

A Service Desk customer is not a TaskFlow user with fewer rights — they sign in to a separate portal, never see the internal interface, and don't take up a licensed seat. See Customer portal.

Global permissions

Admin → Global permissions is a matrix of role against capability: creating, editing and deleting projects and issues, transitioning issues, managing sprints and boards, managing users, managing roles. This is where you decide what a role means in your organisation rather than accepting the defaults.

System roles are marked as such — treat changes to them with care, since they apply to everyone holding that role.

Project roles

Inside a project, each member also has a project role, independent of their global role. Out of the box: Administrators, Maintainers, Members and Viewers, and you can add your own under Admin → Project roles.

Add people to a project — individually or as a group — from the project's own Roles tab.

Permission schemes

Admin → Permission schemes is where project-level access is actually defined: a named set of grants covering viewing, editing, administering a project, creating/editing/deleting issues, transitioning, commenting, and viewing or managing boards and sprints. Apply a scheme to projects instead of configuring each one by hand.

Grants can target more than named roles. You can also grant to the issue's author, its assignee, any reporter or any assignee — so a rule like "the reporter may always comment on their own issue" needs no per-user administration at all.

Groups

Admin → Groups organises users into groups. Grant access to a group rather than to a dozen people individually — when someone joins or leaves, you change the group, not every project.

Advanced permissions

If the advanced permissions feature is enabled, you get object-level control on top of the scheme model, with three tabs:

• Grants — give a specific person or group access to a specific object.
• Denies — an explicit block that overrides any grant.
• Check — ask what a given user is allowed on a given object, and get an answer rather than a guess.

Use it when role-based access isn't precise enough — a sensitive project, a single issue that needs sharing outside its usual audience.

Registration and sign-in control

Two switches under Admin → Settings control how people get in. Both apply on the running system within seconds:

• Closed registration — the self-service registration form is hidden and refused; administrators create accounts.
• Password sign-in disabled — the sign-in fields, the button and the password-reset link are hidden and refused.

Don't lock yourself out

Switching off password sign-in with no other way in means nobody — including you — can sign in through the interface. Only turn it on when another route exists. Whoever operates the installation has a break-glass credential for exactly this situation; see Configuration → The owner token.

Service Desk customers have their own pair of switches, separate from these — see Agent guide.

API tokens across the instance

Admin → API tokens lists every personal token issued by every user, with its owner and status, and lets you revoke any of them. Personal tokens are created by users themselves in their profile — this page is your overview and your off-switch.

Good practice

• Give people the least role that lets them do their job.
• Prefer groups and schemes over per-user grants for anything beyond a handful of people.
• Use a dedicated bot account for integrations, so access survives staff changes.
• End all sessions and revoke tokens when someone leaves, rather than only changing their password.

Where to go next

• Project configuration — issue types, priorities, workflows.
• Features & settings — enable features and set global options.