Roles and permissions
Every person in a Piprio organization holds exactly one role. The role decides what that person can see and change, from running the whole account down to read-only access. Six roles cover the work, and the set is fixed: an administrator assigns one of the six to each member, and there is no facility to define new ones.
The roles, from most authority to least, are Owner, Admin, Data Steward, Senior Reviewer, Reviewer, and Viewer. Authority is layered. Each role can do everything the role below it can, plus more. A buyer evaluating Piprio against a build-it-in-house option gets a working access model out of the box, with the guarantees a security review looks for: a single role per member, a clear ceiling on what each role can touch, and a recorded history of every change.
Role matrix
The table below describes what each role can do, framed as capabilities rather than screens. "Review work" means accepting, rejecting, and editing the labels on a document and pulling unassigned work from the queue. "Design schemas" means authoring and versioning the labeling specifications. "Manage the pipeline" means configuring source connectors and running crawls that bring documents in.
| Capability | Owner | Admin | Data Steward | Senior Reviewer | Reviewer | Viewer |
|---|---|---|---|---|---|---|
| View documents, schemas, and quality reports | Yes | Yes | Yes | Yes | Yes | Yes |
| Review work (accept, reject, edit labels) | Yes | Yes | Yes | Yes | Yes | No |
| Design and version schemas | Yes | Yes | Yes | No | No | No |
| Manage connectors and run crawls | Yes | Yes | Yes | No | No | No |
| Author and approve work-routing rules | Yes | Yes | Yes | Yes | No | No |
| Assign work to other people | Yes | Yes | Yes | Yes | No | No |
| Run and schedule exports | Yes | Yes | No | No | No | No |
| Manage members, teams, and integrations | Yes | Yes | No | No | No | No |
| Configure single sign-on and API keys | Yes | Yes | No | No | No | No |
| Change billing and delete the organization | Yes | No | No | No | No | No |
A few lines deserve a plain reading.
A Viewer sees everything that matters for oversight, documents, schemas, quality dashboards, and the team chart, but changes nothing. This is the role for an auditor, a manager checking progress, or a stakeholder who needs visibility without a hand on the controls.
A Reviewer does the labeling. Reviewers pull documents from the unassigned queue, propose and edit values, and accept or reject AI-proposed labels. They cannot reassign another person's work or reach into schema and connector settings.
A Senior Reviewer adds authority over how work flows: writing and approving the rules that route documents to teams, and assigning documents to other people. Senior Reviewers do not change schemas or connectors.
A Data Steward owns the data pipeline. Stewards define and version the labeling schemas, configure connectors, run crawls, and manage how schemas bind to incoming documents, on top of everything a Senior Reviewer can do.
Admin covers all of the above plus the controls that govern the account itself: members, teams, single sign-on, API keys, exports, and integrations. The one thing an Admin cannot do is touch money or end the account.
Owner is the only role that can change billing or delete the organization. An organization always has at least one Owner, and the system will not let the last one be removed or demoted.
Read access to the member list is open to every role, because assignment menus, team views, and reviewer dashboards all need to show who is on the team. Internal membership is not treated as sensitive. Every action that changes state, by contrast, is gated to the roles above.
Assigning roles
A role is set when a person joins and can be changed at any time afterward by an Admin or an Owner. No lower role can change anyone's role, including its own.
People join an organization in one of three ways, and each carries a role:
- The person who creates an organization becomes its Owner.
- An invited member arrives at the role named in the invitation. Reviewer is the default when none is specified, the most common day-to-day role.
- When single sign-on is set up, a member signing in for the first time is provisioned at the organization's configured default role. The default is a setting an administrator controls, so an organization can decide whether new single-sign-on arrivals land as Viewers, Reviewers, or something higher.
Three guarantees govern role changes, and each one prevents a class of mistake that a procurement review tends to ask about.
The last Owner cannot be demoted. An attempt to lower the only remaining Owner to any other role is refused, so an organization can never be left with nobody able to manage billing or close the account.
A role change takes effect immediately and forces re-authentication. When a member's role changes, their active sessions are ended, so the next request runs under the new role rather than a cached copy of the old one. A revoked permission stops working the moment the change is saved, not whenever the session would have expired on its own.
A team lead cannot be quietly stripped of the authority the lead role needs. Team leads are drawn from the higher roles, and the system will not lower a lead's role below the level that lead work requires until a different lead has been named on each affected team. This stops an organization from ending up with a team led by someone who no longer has the standing to lead it.
On that last point: "Team Lead" is a label, not a separate role. It marks a member who heads a team and is shown as a convenience in team views. The underlying role, and the authority it carries, stays the same whether or not a person leads a team. Putting someone on a team never widens or narrows what they can do across the organization.
Separate from the six organization roles, Piprio's own staff hold a platform operator grant used to support customers and run the service. That grant is not part of any customer's role model, is not assignable by a customer, and is managed only by Piprio. It governs cross-account support tooling, never the account-level roles a customer administers.
Custom roles
The role set is fixed. An organization works with the six built-in roles, and there is no facility to define new roles, rename them, or hand-pick individual permissions per person. Assignment is the lever: an administrator chooses which of the six fits each member.
This is a deliberate design. A fixed, layered set of roles is straightforward to reason about during a security review and leaves no room for a hand-built permission matrix to drift out of alignment with what the system actually enforces. The six roles were drawn to match the real division of labor on a labeling team, from full account control down to read-only oversight, with the review and pipeline responsibilities split out in between. For finer-grained control over who handles which documents, work is steered through team membership and routing rules rather than through per-person roles.
Auditing role changes
Every change to a member's standing is recorded. When an Admin or Owner changes someone's role, the record captures who made the change, when it happened, and both the prior role and the new one. Removing a member is recorded the same way. Inviting a member captures the invited address and the role offered.
These records are written as part of the same transaction as the change itself, so a recorded event always corresponds to a change that actually took effect, and a change that took effect always leaves a record. There is no window in which one happens without the other. The history is append-only, in line with the rest of Piprio's audit trail: entries are added, never edited or deleted in the normal course of operation.
An organization Owner can review this administrative history for the account. The result is a defensible answer to the question a compliance reviewer asks first: who granted this person this access, and when. The same trail covers membership changes and other administrative actions, so a single history shows how the shape of the team changed over time.