Members & the user directory

The user directory — People → Members — is where people are added, reviewed, suspended and removed. It is one screen because those are one decision made repeatedly, and splitting them across four is how an administrator ends up reaching for the wrong one.

Add a member#

1. Choose Add member. A drawer titled Add a member opens.
2. Type their work address.
3. Optionally give their full name — see below for what that decides.
4. Pick the role they start with, or leave it on Member.
5. Choose Add member again to confirm.

They receive an email with a link. They set the master password and generate the keys — the organization never holds either, and cannot read what they store. Until they accept, the seat is held by the pending invitation, so a member you are onboarding cannot be double-booked.

The role is not a commitment: change it later from the member's own panel — choose their name in the directory, then Roles & permissions. Only organization-scope roles are offered here — team roles are given by the team, not at the door. To put the new member in a team, see Teams.

The name is a decision, not a label#

Leave Full name blank and the person names themselves when they set up their account, the way any account works.

Fill it in and it becomes their name — shown in the directory, prefilled and locked on the sign-up page, and read-only on their own profile. They cannot change it; correcting it is an administrator's job.

That is the point of the field. A company directory whose names are typed by the people being onboarded is a directory that says j.smith, Johnny and John Smith (Sales) for three colleagues. Fill the column in when the directory matters, and leave it blank when it does not.

Seats are bought in the same drawer#

An invitation can only use a seat you have already paid for. If every paid seat is in use, the drawer shows a seat panel and the button at the bottom changes with the situation:

On a plan that is already at its seat ceiling there is nothing to buy; the panel tells you to change plan. Seats you buy stay yours even if the invitation does not go through. Prices, trial rules and the full purchase flow are in Seat management.

Add several at once#

Add several adds up to 100 people per send. Paste a list of addresses, upload a file, or both. Everything lands in one list you can edit before anything is sent.

1. Choose Add several.
2. Optionally pick a Role for new rows. Rows added from then on get it.
3. Paste addresses, or upload a .csv or .txt.
4. Fix anything under Needs fixing: a bad address, a domain your policy does not admit, the same address twice, or a role you cannot give.
5. Choose Add N people.

Nothing is sent until that last step. Afterwards each row stays in the list, marked Added or Refused with the reason beside it.

Roles#

Every row shows the role it will be given, and that is exactly what is sent. Role for new rows sets the role of the rows you add next. Apply to all gives every row still to send the same role, and you can change any single row. Only the organization's owner can give Organization Administrator.

Seats and your plan's limit#

Only people who need a new seat count. An address that already has a live invitation is resent and keeps its seat. The list shows how many more people fit on your plan: Team holds up to 10, Business up to 500. Rows beyond that are held back with the reason, still listed, until you remove someone or upgrade. If the people who fit need more paid seats than you have, the drawer offers to buy them first.

Finding rows#

All, Needs fixing, Ready and Added filter the list, and the search box finds a person by address or name. Long lists are paged.

The file#

One required column and two optional ones. Download an example file in the drawer gives you a sheet with the right headers already in it.

email,fullname,role
ana.ruiz@example.com,Ana Ruiz,Member
tom.hale@example.com,Tom Hale,
lee.nguyen@example.com,,

A file needs a header row as soon as it has more than one column. A file is refused, before anything is listed, if:

• it is larger than 256 KB;
• it names the same column twice;
• it has a quote that is never closed.

Pasting Ana Ruiz <ana@acme.com> keeps just the address.

Closing the drawer#

The drawer only closes from Cancel or the ✕. Clicking outside it, or pressing Escape, does nothing. If the list still has people you have not added, you are asked to confirm before it is discarded. It never closes while a send is in progress.

Invited#

The Invited tab is everyone you have asked for who has not accepted yet. They are not in the Members list and will not be until they accept, because there is no membership to list — an invitation is the whole of their existence here so far.

Each row carries when it was sent, how many times it has been resent, and whether the link is still live:

Resend issues a fresh link and invalidates the old one — the previous email stops working the moment you do it. There is a limit; past it, revoke the invitation and start again. Revoke kills the link immediately and frees the seat, and asks first: the link it breaks is already sitting in somebody's inbox, and inviting them again sends a different one. Resend asks nothing — it takes nothing away.

If the email does not arrive, resend rather than adding the address again: adding it a second time resends anyway, and tells you so.

Which addresses you may add is set by your domains & invitation policy. When that policy is restrictive, an Invitation policy note at the end of the form lists the accepted domains. An address at any other domain is flagged under the field as soon as you leave it, and the note turns amber. An address at an accepted domain turns green.

An accepted domain only means the policy admits the address. The server can still refuse it, and that refusal appears under the address field too, with the drawer left open so you can correct it. The messages begin:

The second answer is only given for addresses at a domain you have verified. Elsewhere the invitation is sent, and the person is told when they open it. That is not an inconsistency: on your own verified domain you run the mail server and can already answer the question, so telling you reveals nothing. Off it, an immediate answer would let anybody with a Team plan test which addresses are registered with PulsVault, which is a thing this product will not do.

An address that was used before#

Removing a member closes their account — it does not free the address. The account stays as a blocked record (the audit trail needs it) and the address stays spoken for, permanently. There is no reopen, no reinstate and no recovery; Reinstate applies to a suspended member, never a removed one.

So an address can only ever hold one work account in its lifetime. If somebody rejoins — the same person, or a successor at a recycled address — they need a new address. This is refused when you add them, not later, so you never spend a seat on an invitation that cannot be accepted.

Somebody who already has a PulsVault account#

They keep it, untouched. Nothing in their own vaults is read, moved or shared with you, and there is no merge, transfer or conversion on offer — the product cannot separate what was theirs from what was the company's afterwards, in either direction, so it does not pretend to. Add them at a work address instead.

Review one member#

Choosing a member's name opens their detail panel. It has four tabs, and the whole point of it being one panel is that these four questions are usually asked together.

Overview#

Who they are and where their membership stands: when they were invited and by whom, when they joined, when they were last active, and which teams they belong to with the role they hold in each.

Underneath, their security posture — two-factor, trusted devices, open sessions, and the health of their vault. Two absences here are deliberate and mean different things:

• "The Security Centre is not part of this organisation's plan" — nothing was measured.
• "This member has never run a password analysis" — they were never measured. Their counts are unknown, not zero, so none are shown. A dashboard reporting "0 weak passwords" for somebody nobody has scanned is worse than a blank.

The same applies to breach checks: if the plan does not include them, the panel says so instead of reporting nothing found.

Any organization policy the member currently trips is listed by name — "Two-factor authentication is required and not set up" — rather than as a bare not compliant, which tells an administrator to go looking without saying where.

Access#

Everything that member can reach through the organization: their teams, the projects and secret namespaces they hold directly, the vaults shared with them, their live sessions and the service accounts they created.

It is the same projection the removal preview computes, so "what does this person have?" and "what would removing them take?" are one answer and cannot drift apart. Run it against somebody nobody is removing and it is an access review.

Roles & permissions#

Change their organization role here, and grant or take back individual permissions.

Changing the role is one step, not two. Picking a new role grants it and retires the old one together — a member holds exactly one organization role. The owner's role is not changeable here: it is a property of owning the organization, so it moves by transferring ownership.

Your own row is not editable here either — not your role, and not the permissions granted to you. A self-demotion drops the role your business:member:manage came from, and revoking your own grant takes away the authority that would put it back: the change would be the last one you could make. Another administrator, or the owner, does it for you.

Permissions are grouped by where they come from, because that decides whether you can do anything about them:

Only the first group has a Revoke button, and that is on purpose: offering one next to a permission that cannot be revoked individually teaches you the screen is broken.

History#

This account's own audit trail, read from either end:

• Done to them — what administrators changed on the account: roles assigned, permissions granted or taken away, suspensions, reinstatements, removals, and who did each.
• Done by them — what this member did across the organization.

They are two lists rather than one merged feed, because "an administrator suspended Dana" and "Dana signed in" answer different questions and burying one in the other is how a review misses the four rows that mattered. Routine sign-ins and reads are hidden by default on the second list and can be switched on.

Acting on the member#

The panel's footer carries the member's own actions, so you act where you have just read:

• Suspend / Reinstate — reversible, and the state to put somebody in while you find out.
• Remove from organisation — opens the removal preview described below.

The owner's panel shows no footer actions at all rather than greyed ones: both acts are refused for them, and the way out is transferring ownership. A former member's shows none either — there is nothing left to act on, and neither does your own: suspending yourself withholds your own business:* permissions and ends your sessions in the same step, so Reinstate would sit behind the door you just locked.

Suspend, or remove#

Both are reachable two ways: from the member's panel footer, or straight from their row in the directory when you already know what you want to do.

These are deliberately different acts, and the difference is whether it comes back.

Suspend is the one to reach for when you are not sure. It puts somebody out now — every device signed out, every API key they created paused — and gives all of it back on reinstatement, because nothing was taken away.

It asks before it runs, from the row and from the panel alike, naming the person and what lands on them. Remove has always had its preview; this is the same pause for the other act that puts somebody out, and it exists because the effect is immediate and a row is an easy thing to misclick. Reinstate asks nothing, deliberately: it gives access back, and a confirmation on every button is how confirmations stop being read.

A suspended member stays on the Members tab, badged Suspended, with Reinstate beside them. They are still a member and still hold their seat — that is what makes suspension the reversible one.

Removing asks you to type their address#

Choosing Remove on a row opens a panel showing what removal will actually take away, computed by running the removal in dry-run mode against that person. Below it, the red button stays disabled until you type their email address.

That is not ceremony. The panel protects you from misreading the blast radius; typing the address protects you from the other mistake — having the wrong row open. On a directory where every row carries the same red word, that is the likelier of the two, and it is the only step a misclick cannot get through.

Removed#

The Removed tab is everyone who used to be a member, with the date they left.

The membership record outlives the membership on purpose: an organization has to be able to answer who was here, and when did that stop — for an access review, for an incident, for an auditor. So a removal marks the record rather than deleting it.

It is a record, not a recycle bin. There is no action on these rows and nothing to restore: removal closed the account, and a closed account cannot be reopened or reused. Someone returning to the organization is added again at a different address — the message on the Invited tab says so when you try the old one.

What removing does#

Before anything happens you are shown exactly what it will do, computed by running the removal itself in a dry run. Read it: this is the most consequential button in the product.

• Their account is closed. They cannot sign in again, on any device. It was an account the organization provided, so it ends with the membership.
• Every session ends immediately — not at the next token refresh.
• The API keys they created are paused, and the service accounts are named so you know which pipelines stop. Paused, not deleted: hand each one to somebody else and reactivate its key rather than rebuilding it.
• Teams, projects and namespace grants they held directly are revoked. Access they held through a team goes with the team membership.
• Tasks assigned to them are unassigned, not handed to somebody else. Routing another person's work is a decision the product will not make on your behalf.
• Vaults whose keys they had seen are flagged for rotation. They have already seen those keys, so only the vault's owner rotating them is real revocation — the server cannot do it.

And what it does not do:

• Nothing they stored is deleted. Their personal vault is not read, moved or destroyed, and nobody in your organization ever held a key to it. But the account that opens it is closed, so it cannot be reached from here either.
• Organization vaults they owned stay with the organization, and its other custodians keep their keys. Ownership moves separately, before they go.

Three removals are refused#

Both are checked before anything else runs, so a refusal leaves nothing half-done.

Leaving voluntarily#

A member who leaves from Account → My organization reaches exactly the same path, with exactly the same outcome — including the account closing. It is the case most likely to surprise somebody, so the confirmation says it first, before anything else.

Who can do this#

Adding, suspending, removing, reading one member's detail, changing their role and granting them a permission all require business:member:manage — the owner and organization admins, and a permission the owner can delegate. The History tab additionally requires business:audit:read, which is delegated separately. The member list itself is open to every member: sharing a vault, assigning a task and picking a namespace grantee all need to see colleagues, and an admin-only directory is what once forced each of those features to invent its own list of people.

Related#

• Domains & invitation policy — which addresses you may add, and how a domain is proved
• Roles & permissions — what a member can do once they are in
• Seat management — how a pending invitation and an active member both count against your seats
• Audit logs — where additions, suspensions and removals are recorded