Adding users — as a Project Admin

In one line. You run your project’s people yourself — add, invite, remove — from one page, without needing workspace access. You’ll be able to. Add someone who already exists, invite a brand-new person, hand over a one-time password when your workspace allows it, and take someone out of the project again. Where this lives. Studio ▸ Governance ▸ Users & Access.

The page you’re on

Three tabs sit under the title:

Tab	What it’s for
People	Everyone in the project, and what each of them holds here.
Personas	Who runs the project, and your solution’s workflow roles.
Effective policy	Read-only: the access rules this project inherits from the workspace.

The header also carries About roles — a drop-down that explains the two vocabularies on this page, Project access and Personas — and a ? link back to this guide.

The add, edit and remove controls only appear for someone who actually runs this project: a Workspace Admin, the person who created the project, or a holder of the Project Admin role. Everyone else sees the same screen read-only, which is why a colleague may tell you the buttons aren’t there.

Who is a Project Admin?

Every project carries a protected Project Admin role. You’ll find it on the Personas tab, in the Project access section, tagged Protected. Anyone in the project can be given it from the card’s Edit members button — a tick-list of your people with a search box and a live count line, e.g. “4 people have this role.”

It can’t be renamed or deleted, and it has no collection, stage or action settings — by design it is the run-the-project role, so its card offers members only. A project must always keep at least one holder: untick everyone and Save greys out with “A project must keep at least one Project Admin.”

This is your admin seat: with it you run your project’s people day to day without going through a Workspace Admin.

Add a person

Open the People tab and press + Add user. It’s the same dialog everywhere in the product; what it offers here depends on what your workspace allows.

Email. Type the address of the person you want in.
Personas in this project. Tick the personas they should hold — e.g. Underwriter, L1-Reviewer. If the project hasn’t defined any yet, the dialog says “No personas defined yet — the person is added without one.”
How do they get access? Choose one:
- Email invite — they set their own password via a secure link. There is nothing for you to share.
- One-time password — you hand it over yourself; they should change it after signing in. This is recorded in the audit trail.
Read the sentence. The highlighted line at the bottom spells out exactly what is about to happen, e.g. “jane@acme.com will join this project as Underwriter — they receive an email to set their own password — there are no passwords to share.” Confirm.

An email that already exists vs a brand-new one

A brand-new email creates the account and joins it to this project in the same step. An email that already has an account is never duplicated — the person is simply added here with the personas you ticked. If they are already in this project, the dialog tells you so: “This person is already a member here.”

If you chose the one-time password

The dialog turns into a hand-over panel: “<email> added — hand over this one-time password”, the password itself, and a Copy button, under the warning “Won’t be shown again. Ask them to change it after signing in.” Copy it before you close the panel — it cannot be shown a second time.

Whatever you choose, the person accepts the Terms & Conditions themselves at their first sign-in. You can’t accept on their behalf.

Three shapes the dialog can take

Your workspace uses company sign-in only. The field is labelled “Person (from your identity provider)”, the delivery choice disappears, and the button reads Pre-assign — the person gets their access the moment they first sign in with company sign-in. Outside email addresses cannot join.
One-time passwords are reserved for a higher level. The second delivery option is replaced by a line naming who can hand them out — “One-time passwords are handed out by your workspace admins. Email invite works fully.”
Adding people is reserved for Workspace Admins. The dialog opens straight onto a message instead of a form: “Adding users is reserved for workspace admins here. You can still manage the people already in your project”, with “Set by workspace <name> ▸ Policies — ask your workspace admin.”

Refusals always appear inside the dialog, so you can read them and change what you asked for.

Effective policy — why the dialog behaved like that

You never have to guess, and you don’t have to ask first. The Effective policy tab is a read-only summary headed “What applies here — set by workspace <name>. Ask your workspace admin to change it.” It answers four questions:

How people join — company sign-in only, company sign-in plus invited guests, or email invites.
Can you invite people? — “Yes — you can add users here.” or “No — your workspace admins add people.”
Can you hand out passwords? — “Yes — one-time passwords are available when you add a user.” or “No — passwords are handed out by your workspace admins. Email invites still work fully.”
Defaults — the role new members land on, and whether two-factor verification is required.

Nothing here is editable at project level by design. It exists so you can see the rule and who set it.

Manage someone already in the project

Select them in the People list. The panel on the right shows:

Personas & access — the personas they hold here, as chips (or “No role assigned”).
Active — a tick-box that switches their membership of this project on or off. It parks them here; it does not suspend their account, and it does not touch any other project.
Manage — Edit roles to change their personas, and Remove from project.
Workspace role — a drop-down that changes their role across the whole workspace, from inside the project. You get it while your workspace lets project admins bring in their own people (Policies ▸ Who can invite people = Workspace + Project admins, the usual setting); it disappears when the workspace reserves invites for its own admins.

Removing, suspending, reactivating

Remove from project is the narrowest of the product’s three removals: it warns “Their account and workspace access are untouched.” They keep their sign-in and everything they hold elsewhere.

Suspending an account — blocking someone from signing in anywhere — and reactivating them afterwards are not project-level actions; they happen at platform level. If someone has left the company, ask your platform team to suspend the account. Removing them from your project is the right move for you either way.

Personas — your solution’s workflow roles

The Personas tab separates two things the product deliberately keeps apart:

Project access — who runs this project. That’s the protected Project Admin card described above.
Personas — your solution’s workflow roles, e.g. Underwriter or L1-Reviewer. Each persona bundles the pages, actions and data that role uses here.

Press + Add persona (the primary button changes when you switch to this tab) to create one. You give it a name, choose the collections it covers, the workflow stages it works in, and the people who hold it. Can view (acts as a superset of) lists the personas whose work this one may preview — leave it empty for a leaf persona. Show Advanced Settings opens the per-action picker and content filtering by label.

Deleting a persona tells you exactly who is affected before it goes — e.g. “3 people will lose this persona, and any workflow-stage mappings will be removed.”

See also: G1 · Access & roles for the full role model · G7 if you also administer the workspace.