Roles & permissions

Organization access control is role-based. Permissions come in two scopes — organization-wide and per-team — so the same person can be an admin of one team and a member of another.

Organization-scoped permissions#

These apply across the whole organization:

Permission	Allows
business:member:manage	Invite people, remove them, and change which role a member holds. Does not grant access to any vault
business:config:manage	Change organization settings — branding, domains, password and sharing policies, approval rules
business:audit:read	Read the organization's audit trail: who did what, and when
business:report:read	Read the access report and compliance reports. Read-only
business:subscription:manage	Change the plan, seats and payment method
business:billing:read	See invoices and billing history, without being able to change the plan
business:vault:create	Create new vaults. It does not grant access to vaults that already exist — see Vault access below
business:project:create	Create new projects to scope DevOps work
business:project:read	See every project in the organization, including ones you are not a member of. It does not grant access to their secrets or vaults — see Project visibility below
business:vault:custodian	Receive a key to every vault your members create from now on. Granted to one person at a time, never through a role
business:vault:delete	Delete a vault and everything in it — see Deleting is its own permission
business:project:delete	Permanently delete an archived project
business:member:remove	Remove a member from the organization. Separate from member:manage, because removal closes their account
business:role:delete	Delete a custom role
business:backup:manage	Configure the backup archive — its keys, its destination, its runs and downloads. It receives every DevOps secret, so grant it deliberately. Enterprise. Never bundled into a role
business:permission:delegate	Give somebody else one of the four delete permissions above, business:backup:manage or this permission itself, or put a delete permission into a role. The owner can do all of this without holding it. Never bundled into a role

There is also a secrets:* family — twelve permissions covering DevOps secrets, namespaces, environments, machine identities and credential validation. They appear in the role builder under their own heading; each one carries a description explaining what granting it does.

Team-scoped permissions#

These apply only within a specific team:

Permission	Allows
team:config:manage	Edit team name, settings, and policies
team:member:manage	Add/remove team members and assign team roles
team:vault:manage	Create/delete team vaults and configure encryption
team:vault:read	Access the team's vaults
team:audit:read	View the team's audit logs

Built-in system roles#

Role	Scope	Summary
Organization Administrator	Organization	Runs the organization: members, billing, policies, audit and DevOps secrets
Finance Manager	Organization	business:subscription:manage, business:billing:read. No vault, member or audit access
Auditor	Organization	business:audit:read, business:report:read. Changes nothing
Member	Organization	The baseline role every member holds. It grants access to the product itself and adds nothing administrative — see the note below
Team Lead	Team	All team permissions, bounded to that team
Team Contributor	Team	team:vault:manage, team:vault:read
Team Viewer	Team	team:vault:read

Assign roles#

An organization role is assigned from the member's own panel.

1. Open People → Members.
2. Choose the member's name to open their panel.
3. Go to Roles & permissions.
4. Pick the new role and choose Change role.

A member holds one organization role, so this is a swap rather than an addition: the new role is granted and the previous one retired together. The change takes effect on their next request — they are not signed out — and is recorded in the audit log against both the administrator who made it and the member it was made to.

Who can assign which role#

You can give a role only if it ranks below your own, so an administrator can give Finance Manager, Auditor, Member or a custom role. The picker lists only the roles you are allowed to give.

Only the organization's owner can appoint another Organization Administrator. The owner does it from the same picker, either when adding the person in Add a member or later from their Roles & permissions tab. Other administrators hold the same role but cannot create more administrators.

An invitation that would make someone an administrator is checked again when they accept it. If the person who sent it no longer owns the organization by then, the invitation is refused, and the organization has to invite them again.

Who can manage whom#

You can only change the access of someone who ranks below you. That covers changing their role, granting or revoking a permission, suspending, reinstating and removing them.

• Administrators are managed by the owner alone. One administrator cannot demote, suspend or remove another. A custom role that can manage members cannot act on an administrator.
• Nobody can change the owner's access. Ownership moves by transferring it.
• You cannot raise your own access. Only the owner can grant a permission to themselves.
• The same rule applies to custom roles. You can only edit a custom role if it ranks below you, you do not hold it yourself, and everyone who holds it ranks below you.

When you cannot act on someone, the member list and their panel say Managed by the owner instead of offering the actions. An administrator invitation sent by the owner reads Sent by the owner: only someone who could give that role can resend or revoke it.

Vault Custodian is granted only by the owner, or by someone holding Delegate Deletion Rights, because a custodian holds a key to every company vault.

Team roles are separate, and are assigned from the team rather than here: a team role applies only inside that team, and offering one in this picker would be refused on save.

Individual permissions can also be granted to one person on top of their role, from the same panel. See Review one member for what the three permission groups mean and which of them can be revoked.

Custom roles#

The built-in roles cover most organizations. When they do not, Team, Business and Enterprise plans can define their own — a named bundle of the permissions listed above.

1. Open People → Roles & permissions and choose New role.
2. Give it a name and a code. The code is unique within your organization — another customer using the same name does not affect you.
3. Pick the permissions it should carry, grouped by scope: organization permissions apply everywhere, team permissions apply only inside the team the role is held in.
4. Save, then assign it exactly as you would a built-in role.

A custom role sits between Organization Admin and Organization Member in seniority, so it can never be used to grant more than the person creating it already has.

Deleting one is refused while anyone still holds it, and tells you how many people that is. Move them to another role first. A deleted role stays in your audit history.

Your plan sets how many custom roles you can have; the roles screen shows the number in use.

Project visibility#

A project is visible to the people who are on it — added directly, or through a team that was added. Being in the organization is not enough on its own.

That covers more than the projects list. Naming a project you are not a member of returns "not found" everywhere it can be named: its namespaces, its policies, its service accounts, its machine activity and its validation results. The answer is deliberately the same one an unknown project gets, because a "you may not" would tell you the project is there and what it is called.

Two ways past it, and they are different things:

	What it gives
business:project:read	See every project in the organization, member or not. Visibility only — it does not let you change a project, and grants nothing inside one
A project role	PROJECT_ADMIN, PROJECT_DEVOPS or PROJECT_VIEWER, on that one project. This is what lets you act

Organization Administrators hold business:project:read, so they see the whole estate. You can put it on a custom role — for an auditor or a platform lead who needs the overview without the authority — and take it away again, and it shows in the access report either way.

Creating a project makes you its PROJECT_ADMIN, so your own projects never disappear on you.

Deleting is its own permission#

Being able to manage something does not make you the person who can destroy it, and the four permissions above exist so your organization can say where that line sits.

Two things surprise people, and both are deliberate.

Owning the thing is not enough. The person who created a vault still needs business:vault:delete to delete it. Both checks run: the permission answers "may you delete vaults at all", and the ownership check answers "may you delete this one". An administrator who holds the permission still cannot delete a vault that isn't theirs.

Granting deletion is not the same as granting anything else. Handing somebody business:vault:delete — or putting it into a role — takes the organization's owner, or somebody the owner gave business:permission:delegate to, one person at a time. The same goes for granting business:permission:delegate itself. So an administrator can manage your members without being able to quietly give themselves, or everybody, the power to delete — or first the power to hand it out.

What is deliberately not gated#

Everyday editing — creating and deleting items, notes, folders and attachments inside a vault — needs no extra permission. Neither does anything that takes access away: revoking a share, revoking an API key, rescinding an invitation, removing a custodian. Those make your organization safer, and putting a permission in front of them would mean a leaked credential could not be shut off by whoever happened to be dealing with it.

Deleting the organization itself#

Find it under Organization → Organization → Information, in the Delete organization section at the bottom of the page — visible only to the owner. See Organization information.

No permission grants this, and none can be created. Only the organization's owner may do it, and only after re-entering their master password — the confirmation is single-use and cannot be delegated.

Deleting the organization deletes the owner's account with it. The account is signed out everywhere at once, can no longer sign in, and is permanently erased 14 days later. There is no undo from inside PulsVault, so export anything you need first. The organization's plan has to be cancelled before it can be deleted.

Vault access is not a permission#

The question the role builder raises and cannot answer: there is no "read vaults" permission in the list, and there will not be one.

A vault's secrets are encrypted with a key that is wrapped for each person it is shared with. PulsVault holds no copy of it. So a permission saying "may open vaults" could pass the check and still return something nobody can read — it would appear to grant access while granting nothing, which is worse than not offering it at all.

Who may open which vault is decided per vault, at one of four levels you can assign. A fifth, Owner, belongs to whoever created the vault and can never be handed out through sharing:

Level	Can
Manager	Manage the vault, its settings and who else it is shared with
Editor	Create, edit and delete items inside it
Viewer	Read items
Limited	Use credentials without revealing passwords

So "this person may create vaults, that one may only read" is expressed in two places, not one:

• Creating is a permission — business:vault:create, granted through a role or to one person.
• Access to a vault that already exists is a share at one of the levels above, and only somebody who can already open that vault can grant it. Their device does the key wrapping, so no administrator can grant it on their behalf.

For an organization-wide answer, business:vault:custodian gives one person a key to every vault your members create from that point on. Grant it from the member's own panel, one person at a time — it is deliberately not offered in the role builder, because a custodian holds a key to everything and that should never arrive with a promotion.

To see what one person can currently reach, open their panel and choose Access: it lists every vault they can open and the level they hold, alongside their permissions.

How roles interact with sharing#

Roles govern administration; access levels govern individual vault/item shares. A user's effective access is the combination, subject to shared-vault policies.