What user roles exist and how do they differ?

In Worksection, roles and permissions determine who can see data, who manages people, and who only executes tasks. Properly configured roles help avoid unnecessary access and simplify work for teams, clients, and contractors.

Quick role selection

If you need:

• full control over the account — Owner;
• to manage the system at the company-wide level — Account Administrator;
• to manage people within a team — Team Administrator;
• to manage people within a department — Department Administrator;
• day-to-day work in tasks and projects — User;
• limited access for an external contractor — Guest;
• view-only access without making changes — Reader;
• to keep a person's contact without system access — Contact.

Quick role comparison

What to know about each role

• Account Owner — has maximum permissions, access to the administrative API token, and can delete the account.
• Account Administrator — manages settings, members, projects, data, and billing; can see hidden items with the "Allow admin to read private tasks and comments" permission. Unlike the Owner, has no access to account deletion or the administrative API token.
• Team Administrator — manages members of their team and their access; may have permissions to create projects, edit data, and manage expenses/timers within the team.
• Department Administrator — similar to the Team Administrator, but the scope of permissions is limited to the department.
• User — the basic working role: works in projects they have been added to. Can typically create tasks, leave comments, and add files. The ability to comment on others' tasks is a separate toggle: if disabled, the member can only comment on tasks where they are the author or assignee.
• Guest — works only within the permitted context (their own or explicitly shared tasks); cannot see other users' contacts or financial data. Task creation can be enabled for guests if needed. Important note: if a guest is invited to a nested subtask, they automatically gain visibility of the entire task hierarchy above it (the parent task and subtasks at higher levels).
• Reader — view only, no creating, editing, or commenting. The role is not billed; the number of readers in an account can be up to 2× the number of paid core members.
• Contact — has no system login; stored as a person's card for reference purposes. A contact can be created manually or converted from the account of a deleted employee to preserve their data.

Administrative permissions: how flexibility works

The same administrator role can have a different scope of access, as permissions are enabled via individual toggles. Below are the permission names as they appear in the settings.

Account Administrator permissions:

• Access to account settings — opens the administration sections: security, labels, import, workflows, etc.;
• Access to account payment — allows changing the plan and making payments;
• Allow admin to create other administrators — permission to assign and remove administrative roles for other members;
• Allow admin to read private tasks and comments — access to hidden tasks, comments, and files outside standard visibility restrictions;
• Can see all projects in the account — sees all projects, even without personal participation in them;
• Allow admin to manage projects — creating, editing, archiving, and deleting any projects;
• Allow admin to manage people — inviting employees, editing profiles and contacts, managing project access;
• Allow admin to edit everything — editing and deleting any tasks, subtasks, comments, and files;
• Allow admin full access to time and finances — managing expenses and timers, access to rates.

Team and Department Administrator permissions are similar in name and meaning, but apply only within their respective team or department.

Functional roles in projects and tasks

In addition to the base access role, a member can simultaneously hold functional roles:

• Project Lead — can edit the project, tasks, subtasks, and comments within that project, add employees, and manage the member roster (this option is enabled in account settings). Technically any member can be a Project Lead, but assigning a guest as a lead is not recommended.
• Project Assignee — automatically filled in as the "Assignee" when new tasks are created in this project.
• Project Member — can see the project and all of its tasks, files, and comments.
• Task Author — the person who created the task.
• Task Assignee — the person responsible for completing the task.
• Task Subscriber — receives notifications about activity in the task.

Key distinction:

• the base role defines the overall access boundaries within the account;
• the functional role defines what role a person performs in a specific project or task.

Common mistakes when configuring roles

• Assigning "Account Administrator" where "Team Administrator" would suffice.
• Confusing "Guest" and "Reader" (a guest can participate in tasks; a reader cannot).
• Forgetting to check individual permission toggles after assigning a role.
• Granting excessive permissions "just in case" instead of following the principle of least privilege.

Recommended approach

1. Assign the base role based on the scope of responsibility (account / team / department / executor).
2. Enable only the permissions needed for the current work.
3. Add functional roles in projects and tasks (lead, assignee, subscriber).
4. Periodically review access permissions, especially for external members.