Project roles and who can change tasks

Everyone in a project has a role, and the role decides what they can do there. A project's admins give each person their role, and choose whether the project's members can change its tasks.

The four roles

• Admins run the project: its name, statuses, fields, forms, cycles, rates and invoices, templates, sharing with clients, who can change tasks, its people and their roles. Admins can always add, change and delete any task.
• Members do the work. They add tasks and sub-tasks, change them (the name, status, assignee, dates, priority, tags and fields, the card's place on the board, dependencies and repeats), and complete them. They delete only the tasks they made; an admin deletes the rest.
• Commenters read everything in the project and comment on its tasks. They can't add or change tasks.
• Viewers read everything in the project. They can't comment or change anything.

People who are added to a project join it as members. The person who made the project is always one of its admins.

Who can change tasks

Each project chooses how much of the work its members can change:

• Members: everyone who works in the project can add tasks and change any of them. This is the default.
• Members, on their own tasks: members change the tasks assigned to them, and can still add new ones. They can read and comment on everyone else's.
• Admins only: only the project's admins add, change and delete tasks. Members read and comment, and can still log their time, post project updates and add files.

Admins can always change tasks, whatever the project chooses. Commenters and viewers never can.

A project can also follow the workspace's choice instead of making its own. Workspace admins set that choice for every project that hasn't chosen its own.

If someone tries something their role doesn't allow, OneCamp tells them who can, for example "In this project you can change only the tasks assigned to you."

Give someone a role

1. Open the project.
2. Open Project actions (the ⋯ in the project's header) and choose Manage project members. On a phone, it's in the project's ⋯ menu.
3. Next to the person's name, open their role and choose Admin, Member, Commenter or Viewer. Each choice says what the person will be able to do.

The change applies straight away. You can add only people who are already in the project's team.

A project's admins can change roles. So can the admins of the project's team, even if they aren't in the project themselves: a team admin can manage a project's people and archive it, but doesn't see its work unless they are in it.

Every role change is recorded in the workspace's audit log (Settings → Audit log).

Choose who can change tasks

For one project (the project's admins):

1. Open Project actions (⋯) in the project's header and choose Who can change tasks.
2. Choose Members, Members, on their own tasks or Admins only. Or choose As the workspace has it, and the project follows the workspace's choice, including when a workspace admin changes it later.

For the whole workspace (workspace admins):

1. Go to Settings → Permissions.
2. Under Projects, set Who can change tasks to Members, Their own or Admins.

The workspace's choice applies to every project that hasn't chosen its own. Each change is saved as soon as you make it, and recorded in the audit log.

What other people see

Members see a project the way their role and the project's choice allow. Tasks they can change look and work as usual. A task they can't change opens read-only, and they can still comment on it.

Commenters and viewers see the whole project, its boards, lists, timeline and updates, and its tasks open read-only. Commenters can also comment on tasks; viewers can't.

Someone who isn't in the project but has one of its tasks assigned to them can open that task and log time on it. They don't see the rest of the project.

Guests, people from outside your organisation, can't join a project or have a role in one. To show a guest a project, share it with them as you would with a client.

Clients see a project through a link, and need no account. A project's admin opens Project actions → Share with a client and creates the link:

• Can see tasks: the client sees the project's tasks by status, its timeline and the updates you share.
• Can see and comment: they can also comment, approve tasks and ask for changes.

A link can expire after 7, 14, 30 or 90 days, or never, and you can turn it off at any time. A client sees no other project, channel or person's profile. Sharing needs guest access to be on for the workspace (Settings → Security → Guest access).

When your workspace updates

You don't need to do anything for roles to work. When your workspace updates:

• Everyone keeps their place. A project's admins stay its admins, and its members become members. Commenter and viewer are new: use them for people who follow a project without working in it.
• Members can now change tasks. Before, only a project's admins could add or change its tasks. After the update, the workspace's choice is Members, so members of every project can add, change and complete tasks, and delete the ones they made. To keep a project as it was, set its Who can change tasks to Admins only, or set Admins for the whole workspace in Settings → Permissions.
• Admins are told once. The admins of existing projects, and workspace admins, see a notice on the projects pages and in Settings → Permissions, with a link to choose who can change tasks. Once dismissed, it stays dismissed on every device.
• Project names only need to be different within a team. A name another team uses no longer stops you from naming your project the same.
• API tokens act as members in projects (see below), including tokens made by admins.

API tokens, connected apps and agents

An API token acts as the person who made it, but never with more than a member's role. The same goes for apps connected with a token, such as an MCP client.

• A token can do the work a member can, as the project's Who can change tasks allows. In a project set to Admins only, a token can't change tasks, even one an admin made.
• A token can't do anything that needs an admin: it can't change a project's settings, its people or their roles, and it can't archive a project. A team admin's token can't manage the team's projects either.
• Tokens carry none of an admin's powers, whether a workspace admin's, a project admin's or a team admin's. Admins keep those powers for themselves in the app.

If your workspace uses OneCamp AI, the assistant and agents act for the person who asked them, and can do only what that person's role allows in each project.