Using Roles on a Project (Beta)
Last updated: September 10, 2026
Overview
A role is the job someone does on a project — Implementation Lead, IT Contact, Data Owner. Roles let you staff a project by job rather than by name: your playbook says a task belongs to the Implementation Lead, and each project fills in who that actually is.
Roles carry no permissions. They describe who is responsible for what. What someone is allowed to do in OnRamp is controlled separately, by their access level.
Roles are internal to your team's view of a project. They never appear in the Customer Portal.
Roles vs. access levels
These are two different things, and both appear on a member's card.
Access level — Org Owner, Collaborator, Contributor, and so on. Set for the person, controls what they are permitted to do in OnRamp. One access level per person. NOTE: This only appears if your org is configured with RBAC
Role — the role they have on this particular project. A person can hold several roles, or none, and can hold different roles on different projects.
Changing someone's role never changes what they can do. Changing their access level never changes what they are responsible for.
Where roles come from
Roles are defined once for your whole organization, then used across projects.
To see or create them, go to Settings → Task Roles. Each role has:
Role Name — for example, Implementation Lead
Role Description — optional, but it appears next to the role when someone is being assigned to it, so it is worth filling in
Is this role for customer users? — this sets whether the role is an internal role or a customer role
That last choice is fixed when the role is created, and it decides who can hold the role:
Internal roles can only be held by internal users — members of your organization.
Customer roles can only be held by customer users.
If you are looking for someone in a role's list of people to add and cannot find them, this is usually why: an internal user will never appear in a customer role's list, and vice versa.
Access to Settings → Task Roles is limited. Contributors and Collaborators cannot open it.
Where to find a project's people
There are two members surfaces on a project, and they do different jobs.
The [# Members] button in the upper-right corner of any project opens the members panel — a quick check on who is on the project and how engaged they are.
The Members tab, in the project's tab row, is the fuller view. It has two views of its own, Members and Roles, switched with the toggle in the upper left.
Roles can be edited from either surface. The Roles field on a member's card works the same way in the panel and on the tab. The Roles view is on the Members tab.
Assigning people to roles
There are four places you can do this. They all do the same thing.
When a project is created from a playbook. If the playbook uses roles, project creation includes a step called Choose a coworker for each role, listing internal and customer roles separately. Whoever you pick here becomes that role's holder on the new project, and the project's tasks are assigned accordingly.
When you add a member. Both + Internal User and + Customer User include an optional Roles field. Anything you select is granted as soon as the member is added. You can leave it empty and assign roles later.
On a member's card. The Roles field on each member card can be edited in place. It is unavailable on an archived project, for a member who has been removed, or if your access level does not permit managing members.
In the Roles view. Use the Add column to assign a role to an existing project member. See below.
The Roles view
The Roles view shows one row per role in use on this project — every role tagged on a task here, and every role somebody here holds.
To reach it, open the Members tab on the project and switch the toggle to Roles.
Each row shows:
Role — the name, tagged either Internal or Customer. An Archived tag means the role has been retired in Settings but is still in use on this project. Existing holders keep it, and nobody new can be given it.
Holders — everyone who holds the role. Needs a holder means nobody does. Remove someone with the × next to their name.
Tasks — how many tasks on this project are tagged with this role, and how many of those are still open. Not used by any task yet means people hold the role but no task calls for it.
Add — assign the role to another project member. Only members of the matching type appear in the list.
If the view is empty, no task on this project tags a role and no member holds one.
Roles on tasks
A task can be tagged with one or more roles, using the Roles field in the task's detail panel. Internal tasks can be tagged with internal roles; customer-facing tasks with customer roles.
Tagging a role on a task connects that task to whoever holds the role:
If the task has no assignee and no assignee restrictions, adding a role assigns the task directly to the role's holder.
Otherwise, the role's holders are added to the task's assignee restrictions, meaning the task can be assigned to any of them.
OnRamp explains what will happen before saving, and offers Add role only or Remove role only if you want to change the role tag without touching assignment.
If you remove a role from the last task using it on this project, OnRamp will also offer to remove that role from the people holding it here. It will tell you how many open tasks those people are still assigned to — removing the role does not unassign them from anything.
"Apply to ongoing tasks?"
Whenever you grant or remove a role, OnRamp asks whether the change should also reach the project's ongoing tasks.
Your role change is saved either way. This choice only decides whether tasks move with it.
Apply to tasks — when granting a role, the member is added to the project's open tasks tagged with that role. A task with no assignee and no restrictions is assigned to them outright; otherwise they are added to that task's assignee restrictions. When removing a role, the reverse happens — they come off those tasks, except any they still reach through another role they hold.
Don't apply to tasks — the role changes and tasks are left exactly as they are.
A few things worth knowing:
Only open, unarchived tasks are affected. Completed and archived tasks are never changed.
Applying to tasks does not send an email for each task, the same way staffing roles when a project is created doesn't. People are notified that they have joined the project, and the task assignments come with it. Every change is still recorded in the task's activity history.
If a single change would affect more than 25 tasks, OnRamp will ask you to make it in smaller pieces, or to edit those tasks directly.
Keeping roles filled
The Roles view is the quickest way to see whether a project is properly staffed. Needs a holder on a row means a job on this project has nobody attached to it.
Two things commonly cause it:
A member was removed from the project. Removing someone also removes them from the Roles view. Any role only they held will show Needs a holder until you assign someone else. Removal does not reassign roles for you.
A module or task was added after launch. Adding to a live project can bring in tasks tagged with roles that nobody on the project holds yet. Where a role already has holders on the project, OnRamp fills them in for you.
Archiving a role
Archiving a role in Settings → Task Roles stops it being used on anything new. It does not disturb projects already using it:
Existing holders keep the role.
Tasks already tagged with it keep the tag.
In the Roles view the role still appears, marked Archived.
Nobody new can be assigned to it.
Best practices
Give every role a description. It is the only context someone sees when choosing who fills it.
Name roles after jobs, not people or seniority — Data Owner travels between projects, Dana's tasks does not.
Check the Roles view for Needs a holder when a project kicks off, and again whenever someone leaves the project.
When you remove someone from a project, reassign their roles in the same sitting. Nothing will do it for you.