Roles and permissions

Roles decide what each person in an organization is allowed to do: an organization hands somebody a role instead of a list of permissions, and every organization starts with five of them.

Roles cost nothing. They are not part of a plan, no permission is sold behind one, and an organization with no plan at all composes roles exactly as one paying for fifty seats does. What a plan decides is whether the feature a permission governs exists for you at all — the five under Workspaces and projects govern shared workspaces, the three under Shared settings govern managed settings and the five under Prompt library govern the prompts an organization publishes, all three of which need a seat — but the permission itself is yours to grant, keep and take back for free, and it is waiting the day the plan arrives.

Where roles live

Roles are managed on the web, in your account panel: open the organization, then Roles. You get there from Settings → My account → Manage on the web in the app, or from the Sign in link in this site's header.

There is no role editor in Plexus itself, and that is deliberate rather than pending. The app shows you who is in an organization and hands the rest off to the browser, the same way it hands off buying a plan and reading invoices.

The Roles page appears only for people who may use it — an organization's owner and its admins, by default. For everybody else the item is simply not in the sub-navigation, rather than being a page that refuses when clicked.

What a role is

A role is a name with a set of permissions ticked behind it. A permission names one act — Manage members, Publish prompts, Edit shared settings — and never a job title. Nobody is granted a permission directly: you compose permissions into roles, and hand out roles.

The catalogue is fixed at 37 acts, grouped on the editing screen by what they are about: Organization, Workspaces and projects, Shared settings, Prompt library, Knowledge and wiki, Code-style rules, Contribution, Sessions, Organization hooks, Inference, and Presence.

Several of those groups name features Plexus has not shipped yet. Their checkboxes are greyed out and labelled — "Publish proposals — planned, Wave 6" — and cannot be ticked. Nineteen are enforced today, across four groups:

• Organization — changing the organization's details, deleting it, managing members, managing roles, assigning seats, and managing billing.
• Workspaces and projects — Create workspaces, Attach projects, Edit workspaces, Delete workspaces and Manage membership. These five decide who may set up the workspaces an organization shares: create one, attach repositories to it, change its name or who may join, withdraw it, and answer the people asking to get in. Owner and Admin hold all five; Maintainer, Member and Restricted hold none, so a curator role that should also run workspaces is a copy with those five ticked.
• Shared settings — View settings, Edit settings and Enforce settings. These three decide who may see and set the settings an organization manages on its members' machines: read the list and the dry-run counts, publish a recommendation or a dry run and withdraw one, and lock a value on every member's machine. Owner and Admin hold all three; Maintainer, Member and Restricted hold View settings only, so every member can read what their organization manages. Enforcing is deliberately a separate act from publishing: an organization can let a wide circle propose values and a narrow one impose them, by ticking the two boxes on different roles.
• Prompt library — Use prompts, Propose prompts, Publish prompts, Manage revisions and Delete prompts. These five decide who may receive and shape the prompts an organization publishes: be handed the library at all, write a new revision, put a revision on every member's machine, roll one back or drop a draft, and retire a template. Owner and Admin hold all five; Maintainer holds all but Delete prompts; Member and Restricted hold Use prompts and Propose prompts. A role that denies Use prompts receives nothing from the library, and a member whose role lacks Publish prompts is refused by the organization's own service, not merely by a hidden button.

The five you start with

The five are read-only. Nobody edits them — not you, and not us on your behalf. Pressing Edit on one opens it anyway, so you can read exactly what Maintainer grants; it is Save that refuses, with "That role ships with Plexus, so it cannot be edited. Make a copy of it and change the copy."

That is a redirection rather than a wall, and the reason for it is that these five names have to mean the same thing everywhere. Support can answer "does Maintainer publish prompts" without first opening your organization's editor, and a role edited in place would silently rewrite what everybody already holding it is allowed to do — the one change a permission model must never make quietly. Copying costs one click and gives you a role you own outright.

Making your own

Two buttons on the Roles page:

• Copy takes any role — one of the five, or one of yours — asks for a name, and hands back a role holding the same permissions that is yours to edit. This is the answer to every sentence that starts "Admin, but…". The copy starts with no description, deliberately: the original's sentence stops being true the moment the copy differs from it.
• New role starts from a name, a one-line description, and an empty matrix.

Edit opens the same form on a role you own: rename it, reword the description, tick and untick. The ticks are laid out by group, so "what may these people do with the prompt library" is one block rather than a hunt down a list of 37.

Delete is refused while anybody still holds the role, and the refusal counts them for you — "That role is still held by 3 members. Give them another role first, then delete it." Deleting anyway would strip every holder of whatever it granted, with nothing to put it back.

Giving somebody a role

On the organization's Members page, Change roles on somebody's row opens a checklist, not a dropdown: a membership holds as many roles as you tick.

It must hold at least one. Untick everything and the save is refused — somebody holding no role at all can do nothing in the organization while still appearing in its member list and possibly holding a paid seat, which is never what anybody meant.

Plexus asks the account service what you are allowed to do on every request and keeps no cached answer, so a role change takes effect the moment it is saved. In the app it shows up the next time that page loads, which includes coming back to the Plexus window.

Holding more than one role, and why a denial wins

Roles add up. Hold three of them and you are allowed anything any one of them allows; there is no ordering, no precedence between roles, and no "highest role wins".

There is exactly one exception, and it is the whole reason Restricted works: a role can also deny a permission, and a denial beats every allow, unconditionally, however many other roles grant it.

Restricted is the one shipped role built on a denial. It grants what Member grants minus contributing, and then denies contributing outright — both halves deliberately. The ordinary way somebody picks up the rest of a member's access is by also holding Member, so a contractor who is Restricted and Member would get contributing back from Member if Restricted merely stayed quiet. Taking something away reliably is that role's entire purpose, and "reliably" is the word an omission cannot deliver.

What the app shows, and what the panel shows

The app's people list gives one word per person — Owner, Admin or Member — and that word is a summary of the whole set, not one of the roles in it:

• Owner if their roles between them grant everything.
• Admin if their roles include managing members.
• Member otherwise.

So somebody holding Maintainer reads as Member in the app, because a maintainer does not manage people; somebody holding Maintainer and a copy of Admin reads as Admin. The account panel's Members page shows the actual set of roles, which is the answer to reach for when the badge surprises somebody.

The last owner

An organization cannot be left without an owner. Taking the Owner role off the only person holding it is refused — "An organization needs an owner. Make somebody else an owner first." — and so is removing that person from the organization, and so is deleting your Plexus account while you still own one.

Owner is also the one role an invitation cannot name. Handing an organization over has to be a deliberate act by an owner against somebody who is already a member, which is what Change roles is for; an invitation, by contrast, is redeemed by whoever holds a mailbox.

Inviting people into a role

An invitation carries the role the person joins with.

• In the account panel, the list offers every role the organization has except Owner — the other four, plus anything you wrote, named as you named it. That is the point of writing roles at all.
• In the app, Invite someone offers Member or Admin. To invite somebody straight into Maintainer, Restricted or a role of your own, send that invitation from the panel.

If the role an invitation named is deleted before the invitation is accepted, the person joins as a Member rather than the invitation failing on them — an unanswered invitation is not a reason to lock somebody out of joining.

Plans, seats and billing covers the rest of what an invitation does, including how long it is good for and why a seat is a separate step afterwards.

If you are refused

A refusal names the act, not the role — "You do not have permission to manage this organization's billing." — because the role you hold is not the useful half of the answer. The person who can fix it is your organization's owner, and what they need to hear is which permission you were missing.

None of this touches your own machine. Sessions, worktrees, the agent terminal, review, the explorer, the git client, hooks, pull requests and the dashboard have nothing to do with roles: they are yours, they run locally, and no role in any organization has ever switched one of them off.

Next: Your Plexus account for organizations, devices and what leaves your device, Plans, seats and billing for seats and invitations, Shared workspaces and Managed settings for what the workspace and settings permissions actually govern, Prompts your organization publishes for what the five prompt permissions govern, or Cross-device sync and Prompt templates for what a plan unlocks.