Organization User Management

Use Organization -> Members to invite people, change roles, resend or cancel pending invites, reset passwords when needed, and remove access.

For most teams, this is the only access screen that matters. The install-wide Super Admin surface is separate and is only relevant for the person operating the whole Vivd instance.

This is not the public signup flow

This page is about member management after you already have access to a workspace or a self-host install. It is not a public “create account” path for the hosted product.

How access works

• Each person has one account.
• That account can belong to one or more organizations.
• Day-to-day permissions come from the person’s organization role.
• The global system role mostly matters only for install operators.

In other words: for normal end users, think in terms of Owner, Admin, and User inside the organization they are currently working in.

Roles at a glance

Role	What it is for	Typical capabilities
Owner	Highest-trust organization role. Keep this to one or two responsible people.	Everything an admin can do, plus protected organization-level ownership tasks such as renaming the organization.
Admin	Day-to-day organization management.	Add and remove members, change member roles, reset another member’s password, create and manage projects, and run organization-level maintenance tasks.
User	Regular project contributor.	Work inside existing projects, use Studio, review content, and handle normal project work without managing the organization itself.
Client Editor	Deliberate single-project handoff or client-review role.	Automatically lands in one assigned project, can use Studio and AI editing features there, but cannot roam across projects or manage organization settings.
Super Admin	Install-wide operator role, not a normal project-team role.	Cross-organization and instance-wide administration such as instance settings and global user management.

What admins do in practice

From the Members tab, organization admins and owners can:

• send an invite email to a new or existing teammate
• track pending invites and resend or cancel them
• change a member between User and Admin
• remove a member from the organization
• reset another member’s password when local password auth is used and recovery is needed

Users cannot manage people or organization settings, but they can still do normal project work inside the projects they already have access to.

Invite-first onboarding

Vivd uses invite-only member onboarding instead of public signup:

• Admins send an invite from the organization workspace.
• The invitee opens the email link and either creates their own password or signs in with an existing account that matches the invited email address.
• Membership is attached only after the invite is accepted.
• Client Editor invites still carry the single assigned project automatically.

This keeps mailbox proof tied to the invite email while avoiding the old manual “admin creates your password for you” handoff.

Password reset is a recovery tool

Password reset still exists for local password auth, but it is no longer the normal way to onboard a new teammate. Use invites first, and use password reset only when someone already has an account and needs help regaining access.

Guardrails you should expect

• You cannot change your own role from inside the organization workspace.
• You cannot remove yourself from the current organization.
• Owners are treated as protected members in the normal organization UI.
• Organization name changes are owner-only.

These guardrails are intentional. They keep the org-management surface safe from accidental lockouts and make it clear that Owner is a higher-trust role than day-to-day Admin.

Recommended setup

1. Keep Owner very limited.
2. Use Admin for people who manage team access or organization operations.
3. Use User for regular collaborators working inside existing projects.
4. Use Client Editor only when you want that single-project handoff behavior.
5. Re-check membership before launch, project handoff, or staffing changes.

About Client Editor

Client Editor remains a narrower, project-scoped role. Prefer Owner, Admin, and User for most team setups, and use Client Editor when you explicitly want one person routed into one assigned project without broader workspace access.