Users and Access (Owner/Admin)

Orgonaut's account authorization model currently uses five access roles:

• owner
• admin
• manager
• member
• viewer

Sign in and choose an account

Use https://app.orgonaut.co/login when you do not know the exact Organisation Account URL. If a saved or mistyped *.orgonaut.co workspace no longer exists, Orgonaut sends you to the shared login and account chooser instead of attempting to sign in on that host.

Social sign-in uses the normal two-hour Orgonaut session and does not keep a long-lived Orgonaut login automatically. Google sign-in asks you to confirm which Google account to use. Your identity provider may still recognise an active session and complete its own step without asking for a password. Password sign-in only persists beyond the normal session when you explicitly select Remember me.

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 account administration plus all account feature abilities
• admin: broad account administration without ownership transfer
• manager: operational modeling access, including destructive modeling actions, without account administration
• member: contributor access without account 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 account surfaces their role allows, but they do not get administrative 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 users
• change non-owner user types
• transfer ownership to an active admin
• manage billing/subscription
• change account name and slug

Changes to the account name or slug are recorded in the Activity log, with the previous and new values.

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 users
• change non-owner user types

Admin cannot:

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

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

Invitation workflow

Invitations are email-based and account-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 account-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.

Access lifecycle

Access lifecycle in V1:

• active
• archived

Archive is used instead of hard delete.

Effects of archive:

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

Reactivation restores account access for that user.

User type updates:

• are available to account owners and admins on /settings/members
• use a modal-based edit flow from the User Type badge row action
• apply immediately to active access
• require archived access 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 account admin.

Delete your user account

You can delete your own user account from Settings → Profile → Danger zone after confirming your password. Deletion signs you out immediately.

If you own any Organisation Account, transfer ownership first. Orgonaut blocks deletion while an owner membership remains so an organisation cannot be left without an owner.

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, access lifecycle changes, and ownership transfer are written to the account activity/audit pipeline for operational traceability.