Using Roles in Playbooks and Projects
What a role is
A role is a job on a project — Implementation Lead, IT Contact, Data Owner. It lets a playbook say who a task belongs to without naming a person, so each project fills in who that actually is.
Roles are internal to your team's view. They never appear in the Customer Portal, including for customer users who hold one.
Setting Task Roles
Roles are defined once for the whole organization under Settings → Task roles, then used everywhere. There is no per-playbook or per-project role list to maintain.
A role has three things:
Role Name — for example, Implementation Lead.
Role description — optional, but it shows beside the role whenever someone is being picked for it, so it earns its keep.
Is this role for customer users? — the checkbox that makes it a customer role instead of an internal one.
That last choice is set at creation and cannot be changed afterwards. It decides who may hold the role: internal roles go to members of your organization, customer roles go to customer users. Nothing crosses over.
This is the usual reason a name is missing from a role's list of people to add. An internal user will never appear under a customer role, and the reverse.
Only Owners, Creators, and OnRamp Admins can add, rename, or archive roles. Contributors and Collaborators cannot open the page at all.
Roles in playbooks and modules
You tag roles on individual tasks, and the playbook's role list builds itself from them. There is no separate place to "add a role to a playbook" — a playbook's roles are simply the distinct roles found across its tasks.
Open any task in a playbook and use the Roles field. Which roles are offered depends on the task:
An internal task offers internal roles.
A customer-facing task offers customer roles.
Modules work exactly the same way, and a module's role list is derived from its tasks too.
If the role you need does not exist yet, you can create it without leaving the task. Pick Create task role at the bottom of the list and it is added to the org library straight away. The option only shows for Owners, Creators, and OnRamp Admins — everyone else picks from what already exists.
The practical consequence of the derived list: to remove a role from a playbook, untag it from every task using it. Once no task references it, it stops appearing when projects are created from that playbook.
Starting a project from a playbook
When a playbook uses roles, project creation adds a step called Choose a coworker for each role. Internal and customer roles are listed separately, each showing its description, and there is a shortcut to assign one person to every role in a group.
The people you pick get two things at once: they become holders of that role on the new project, and they are added as project members if they were not already.
How tasks get assigned
A task is auto-assigned only when its roles resolve to exactly one person. If two people hold the role, both are set in the assignee restrictions.
This means that this task can only be completed by the users in this role. Staffing three people as Implementation Lead means all of those 3 users appear in the assignee restriction when the project is created.
Self-serve playbooks
A self-serve playbook stores its role assignments up front, since nobody is present to choose when a customer starts the project themselves. Until every role in the playbook has someone mapped to it, the playbook is not offered for self-serve.
Roles on a live project
Roles stay editable after a project launches, in four places.
The Members tab lists everyone on the project in a table. A Roles column shows each person's roles as chips, and an archived role still in use reads Name (archived). Above the table, a role filter narrows the list to one role — that is how you check who covers a job, and whether anyone does.
A member's card carries a Roles field you can edit in place. It locks on an archived project, for a removed member, or without permission to manage members.
The add-member dialogs both include an optional Roles field, granted the moment the member is added.
Project tasks have the same Roles field as playbook tasks, in the task panel and as a column in the task list. Tagging a role here connects the task to whoever holds it: a task with no assignee and no restrictions is assigned outright, otherwise the holders are added to its assignee restrictions.
Before saving a task's role change, OnRamp spells out the effect and offers Add role only or Remove role only to change the tag without touching assignment. Remove the last task using a role and it also offers to strip that role from the people holding it — telling you how many open tasks they stay assigned to, because removing a role unassigns nothing.
"Apply to ongoing tasks?"
Granting or removing a role raises this prompt. The role change is saved either way — the choice only decides whether tasks move with it, which matters because the secondary button reads like Cancel and is not.
Apply to tasks — granting adds the member 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 join its assignee restrictions. Removing does the reverse, skipping any task they still reach through another role they hold.
Don't apply to tasks — the role changes, tasks are untouched.
Three things worth knowing:
Only open, unarchived tasks are affected. Completed and archived tasks never change.
No email goes out per task, the same way staffing roles at project creation sends none. People are told they joined the project and the task assignments come with it. Every change still lands in the task's activity history.
A change touching more than 25 tasks is refused, with a prompt to do it in smaller pieces or edit those tasks directly.
Archiving a role
Archiving is not passive. It rewrites every task carrying that role, across the whole organization — playbooks, modules, and live projects alike.
What happens when you archive:
With a replacement chosen — every task tagged with the old role is re-tagged to the new one.
With no replacement — the role is stripped from every task that had it.
Either way the role goes inactive and stops being offered anywhere.
People who hold the role keep holding it. That is why an archived role can still appear in a project's Roles column, reading Name (archived).
OnRamp asks you to pick a replacement only when the role is used in playbooks or modules, and even then a replacement is offered rather than required. Confirm without one and the tag is removed everywhere.
Unarchiving brings the role back and makes it selectable again. It does not restore any tag that archiving removed or replaced; those have to be re-applied by hand.
Common Questions
Archiving reaches live projects, not just the library, and the replacement prompt does not appear for project-only usage.
"Don't apply to tasks" is not Cancel. The role change saves regardless.
Internal and customer roles never mix. A missing name in a picker is almost always this.
Naming
Name roles after the job, not the person or their seniority. Data Owner travels between projects; Dana's tasks does not. Fill in the description — it is the only context anyone sees when choosing who fills the role.