ORGONAUT
Login Signup
Docs
Users and Access (Owner/Admin)

Users and Access (Owner/Admin)

Orgonaut's tenant authorization model currently uses five membership roles:

  • owner
  • admin
  • manager
  • member
  • viewer

The management surface at /settings/members is intentionally limited to owner and admin. Managers, members, and viewers participate in the broader role-based authorization model across the app, but they cannot open the user-management page unless their role is changed.

Open the management page

Go to:

  • /settings/members

You will see different actions based on your role.

The Active Members table includes User Type, Joined Since, and Last Login so you can quickly see access level, membership age, and each member's most recent successful sign-in.

In the Invite User card, click user type in the helper sentence to open the live comparison matrix. The modal groups abilities by app section and shows exactly which roles can perform each action based on the current role bundle configuration.

Role boundaries

At a high level:

  • owner: full tenant administration plus all tenant feature abilities
  • admin: broad tenant administration without ownership transfer
  • manager: operational modeling access, including destructive modeling actions, without tenant administration
  • member: contributor access without tenant administration or destructive delete actions
  • viewer: read-focused access

In the current role bundles:

  • manager can delete actors, placements, positions, teams, departments, and initiatives
  • member can create and update those records where allowed, but cannot delete them

In practice, viewers can read the tenant surfaces their role allows, but they do not get tenant-admin or mutation controls. For example, viewers cannot open /settings/members, /settings/export, or /settings/ai/costs, and they do not see edit, deactivate, compensation, or placement-management actions on people, agents, teams, departments, or positions.

Owner can:

  • invite users as admin, manager, member, or viewer
  • resend and revoke pending invites
  • archive and reactivate non-owner memberships
  • change non-owner user types
  • transfer ownership to an active admin
  • manage billing/subscription
  • change tenant name and slug

For the owner billing workflow, see Billing and Subscriptions.

Admin can:

  • invite users as admin, manager, member, or viewer
  • resend and revoke pending invites
  • archive and reactivate non-owner memberships
  • change non-owner user types

Admin cannot:

  • assign owner through invites or user-type changes
  • transfer ownership
  • manage billing
  • change tenant name/slug
  • delete the tenant

Astro can describe the current members, invitations, and ownership context when your permissions allow it, but Astro cannot invite users, revoke invites, archive memberships, or transfer ownership. Those tenant-admin actions remain human-owned in the settings workflows.

Invitation workflow

Invitations are email-based and tenant-scoped.

Rules:

  • invite role must be selected as one of admin, manager, member, or viewer
  • owner cannot be assigned from invites or user-type edits
  • invite links are single-use
  • invite expiry is 7 days from creation
  • invite links open an acceptance page that guides users to sign in or create an account first when needed
  • invite emails are rendered from the shared tenant-branded invitation mailable for both new and existing users
  • accepting account email must match the invite email (normalized compare)
  • resending creates a new pending invite and revokes the previous pending invite
  • the Pending Invitations table shows the invited user type for each pending invite

The user-type comparison modal is read directly from the current ability catalog and role bundles, so it stays aligned with the real enforcement rules used by the web app, API, tokens, and assistant.

Invite states:

  • pending
  • accepted
  • expired
  • revoked

Accepted, expired, and revoked invites are terminal.

Membership lifecycle

Membership lifecycle in V1:

  • active
  • archived

Archive is used instead of hard delete.

Effects of archive:

  • archived users lose tenant-scoped web/API access
  • archived users are removed from tenant switch/fallback membership eligibility
  • owner membership cannot be archived

Reactivation restores tenant access for that membership.

User type updates:

  • are available to tenant owners and admins on /settings/members
  • use a modal-based edit flow from the User Type badge row action
  • apply immediately to active memberships
  • require archived memberships to be reactivated before the user type can be changed
  • cannot assign owner
  • cannot change the current owner row

Ownership transfer

Ownership transfer is immediate and atomic:

  • source owner becomes admin
  • target active admin becomes owner
  • exactly one active owner is preserved
  • the owner must confirm in a modal by entering their account password before the action is executed

Target must already be an active tenant admin.

API parity

The API mirrors the same permissions and lifecycle model:

  • GET /api/v1/tenant-members
  • PATCH /api/v1/tenant-members/{user}/archive
  • PATCH /api/v1/tenant-members/{user}/reactivate
  • PATCH /api/v1/tenant-members/{user}/role
  • POST /api/v1/tenant-members/transfer-ownership
  • GET /api/v1/tenant-invitations
  • POST /api/v1/tenant-invitations
  • POST /api/v1/tenant-invitations/{invite}/resend
  • POST /api/v1/tenant-invitations/{invite}/revoke

Use the API reference for full request and response contracts.

Audit trail

Invitation lifecycle changes, membership lifecycle changes, and ownership transfer are written to the tenant activity/audit pipeline for operational traceability.