Roles and permissions

Proba.run controls access on two levels: an organization role that governs administration of your account, and a project role that governs what a person can do inside a specific project. This page explains what each role can do and how to manage access.

Organization roles

Every person in your organization has one of three roles, shown on the organization's members page:

Only the owner can transfer ownership — pick another active member and they become the new owner, while you become an admin. Deleting the organization itself isn't available from this page; if you need it, contact support.

Project roles

Inside a project, access is controlled separately by a project role. Every project member is assigned exactly one role, and the same person can hold different roles in different projects. Proba.run ships three built-in roles:

manager is a read-only role: it sees everything in the project but can't create, edit, or delete anything (it can still export cases). tester can do the day-to-day testing work but can't manage fields, case layout, or project members — those stay admin-only. Anyone in the project, regardless of role, can see the list of members.

Viewing content is never restricted by role — every project member can read everything in the project. Roles and permissions only control actions: creating, editing, deleting, and running things.

Custom roles

If the built-in roles don't fit, an organization admin can create a custom role from the Roles & Permissions page — either starting from scratch or by copying an existing role. Give it a name (must be unique) and turn on exactly the permissions it needs, area by area. A custom role can't be granted anything an admin doesn't already have, and the admin role's own permission set can only be adjusted by your instance's platform owner.

A role that's currently assigned to at least one project member can't be renamed away or deleted until you move those members to a different role first.

Assigning roles and per-project overrides

When you add someone to a project, you pick their role from the catalog (or leave it on "Auto", which uses their default role). You can change a member's project role later from the project's Members panel — this resets any custom overrides for that member, and Proba.run warns you before doing it.

For finer control, you can turn off individual permissions for one member in one project without touching their role everywhere else — for example, giving a tester every tester permission except managing milestones just for this project. You can only take permissions away this way, never add ones the role doesn't already have.

Managing organization members

The organization's members page lets an admin edit a member's display name, reset their password, deactivate or reactivate their account, or remove them. A member who owns content (cases, runs, results) can't be deleted outright — deactivate them instead, or use anonymize to permanently strip their personal data while keeping their contributions attributed to "Deleted user."

Inviting people

An admin or the owner invites someone by email and picks their organization role — Admin or User (ownership itself can't be granted through an invitation). Proba.run generates a personal invitation link that you copy and send yourself; automatic email delivery isn't available yet. The link:

• expires after 7 days
• can be revoked at any time, immediately breaking it
• can be resent, which issues a fresh link and invalidates the old one
• works once — accepting it creates the membership and can't be reused

The invited person has to sign in (or create an account) with the exact email address the invitation was sent to. Since an account can currently belong to only one organization, someone who already belongs to another organization can't accept a new invitation until that changes.