User Roles

A user’s role decides what they can do in Pactly: which contracts they can see, whether they can edit or only view, and whether they can manage other users or change company settings. This page is the reference for every role, how a company can customize them, and the one scoping rule that explains most “why is this button greyed out?” questions.

Roles are assigned when you add or edit a user, under Account settings → User management. Only an Admin sees the role field. For the step-by-step of assigning a role, see Adding and Managing Users.

Pactly ships ten built-in system roles. Every user has exactly one. The role key (the lowercase value Pactly stores, like manager) never changes, but a company can relabel it and adjust its permissions (see Custom roles below). Grouped by the job they do:

The same roles, with their default permissions in one place:

The admin role is locked: its permissions can’t be edited, and Admin users can’t be deleted from the user list. This is deliberate, so a company can never lock itself out of its own account.

The single most common source of “I can see this contract but the buttons are greyed out” is scoping, not the role label. Each permission carries a condition that decides which records it applies to:

A plain user can find and create contracts across the whole company, but can only edit or manage the ones they own. So a user will often see a colleague’s contract in the list, open it, and find the actions disabled. That is working as intended: they aren’t the owner. An admin or manager gets company-wide scope on those same actions, which is why the same screen looks fully enabled for them.

This scoping is invisible in the interface. When a user reports a missing button, check whether they own the contract and whether it sits in a group they belong to before changing their role. For a full symptom-to-cause walkthrough, see Why can’t this user do X?.

A company doesn’t edit the system roles directly. Instead, under Account settings → User management → Roles, an Admin can create a custom role that sits on top of a system role and adjusts it.

Each custom role is built as:

• a required base role (one of the ten system roles),
• a set of added permissions, and
• a set of removed permissions.

The user’s effective permissions are the base role, minus the removed ones, plus the added ones. There are no free-form roles built from scratch: every custom role starts from a system base. In the role editor, you click a role to open it, then toggle permission pills on or off per area; coloring shows what’s been added, removed, or left unchanged. Save stores only the difference from the base.

To undo all customization, use Reset role, which deletes the overlay and returns the role to its system defaults. The admin role can’t be opened or edited at all.

A company can also rename any role for its own users without changing what the role does. The displayed label is per-company, while the underlying key stays the same. A manager might appear as “Faculty Admin” or “Team Lead” in one account, for example.

Because of this, the label a user sees may not match the role names in this reference. A renamed role is still one of the ten system roles underneath, with the same permissions (plus any overlay adjustments). When troubleshooting, the system key, not the display label, is what determines access.

To keep the role picker short, an Admin can hide roles a company doesn’t use so they don’t appear when assigning a role. A role can’t be hidden while users are still assigned to it; reassign those users first.

• Adding and Managing Users
• Why can’t this user do X?
• Role Permissions Reference
• Using groups for document access