User Management: End-to-End Onboarding Flow

From Partner AM signing a new SMB customer through populating the organization and managing user lifecycles. Excludes bulk upload.

Based on User Management PRD v34 | April 2026
Partner AM
System
SMB Admin
Invited User
P1 (post-MVP)
P2 (future)
Active Invite Sent Deactivated Ghost Traveler
1
Seed Admin Onboarding

The Partner Account Manager (AM) signs a new SMB customer and initiates business creation. The seed admin is always assigned the Admin role.

Partner AM
PZ-1 PZ-2
Create new business
AM provides DK number (double-entry for typo prevention), one or more admin email addresses, and an optional business name.
  • DK mismatch blocks submission. Incorrect DK after submit requires engineering DB fix.
  • AM can enter their own email to self-invite as admin on the business.
  • Implementation: internal tool (baseline) vs self-serve partner portal. Pending eng input on effort delta.
Partner AM
PZ-4 P2
Existing DK? P2
If the DK is already in the system: P0 shows "This business is already set up. Contact the admin." P2 lets the AM add new admins to the existing business directly.
System
Sec 4
Send admin invitation email
System sends the admin invitation email to each provided address.
Admin's inbox
Seed Admin
PZ-1
Click invitation link and create account
Admin clicks "Accept invitation" in the email and fills in their account details.
System
AT-18
Send one-time password to login email
System sends an OTP to the login email to verify email ownership before completing account creation.
  • OTP has a limited validity window (TBD with engineering).
  • Expires after 10 failed attempts.
  • If expired, the user is sent a new OTP (limit and functionality TBD with engineering).
Seed Admin
AT-18
Enter OTP to complete account creation
Admin enters the one-time password. On success, account is created and admin logs into the portal as Active Admin. Can book travel immediately. No setup required.
System
PZ-5
Notify AM that admin activated
Notification email sent to the AM confirming which admin accepted and for which business.
Partner AM
PZ-6
Resend invitation (if admin hasn't accepted)
AM can trigger a new invitation email to a pending admin. Applies to both implementation approaches (internal tool: ops resends; partner portal: AM resends directly).
ⓘ
Key decision: Seed admin is always Admin role. Only admins can invite other users, so the first person in must have admin access. The admin can book immediately with no setup, payment, or profile completion required.
2
Populate the Organization

The seed admin lands in the admin table (Admin > User Settings > People). They add users and traveler profiles individually via the "+ Add user" button.

Admin
AT-1 AT-2 AT-3
Admin table (People)
Single table showing all users and traveler profiles. Tabs: All | Users | Travelers. Search by name or email. Columns: Name, Email, Role, Status, Travel Policy, Actions.
+ Add user
Card selection: "A user with portal access" or "A traveler profile"
Portal User Path
Admin
AT-4
Fill user form (single step)
First name*, last name*, work email* (becomes login email, write-once), policy tier (Guest/Default/Executive, defaults to Default), optional DOB and gender.
  • Admin role is NOT assignable here. Only via edit modal after invite is accepted.
  • Email uniqueness validated (AT-12).
System
Sec 4
Send user invitation email
New row appears as Invite Sent. Personalized email sent.
User's inbox
Invited User
Click invitation link and create account
User clicks "Accept invitation" and fills in their account details.
System
AT-18
OTP verification
System sends OTP to login email. User enters OTP to complete account creation. On success, row changes to Active. User can book immediately.
  • Limited validity window. Expires after 10 failed attempts.
  • If expired, a new OTP is sent (limits TBD with engineering).
Admin
AT-10 AT-11
Pending invite actions
Resend: sends new invite email, row stays as Invite Sent.
Cancel: confirmation dialog, then revoke invite and remove row.
Traveler Profile Path
Admin
AT-5
Step 1: Traveler profile
First name*, last name*, optional: middle name, DOB, email (booking notifications only), gender, nationality.
Admin
AT-5
Step 2: Additional details (all optional)
Can skip entirely. Four sections:
  • Flight info: required assistance, redress number, known traveler number
  • Frequent flyer: program + number (add multiple)
  • Hotel loyalty: program + number (add multiple)
  • Passport: country of issue, number, expiration
System
Ghost traveler created
New row appears as Ghost Traveler. No portal access, no role, no policy tier. No invitation email sent. Bookable by arrangers at checkout.
Admin
G2U-1 G2U-5
Grant portal access P1
Lightweight modal: name (display-only), email (pre-populated from profile email as suggestion, editable), policy tier (defaults to Default). Traveler profile is NOT modified. Email entered becomes login email only.
  • Role defaults to Traveler. Admin assignable via edit modal after invite accepted.
  • Email validated for uniqueness (G2U-5). Inline errors for duplicates.
  • On submit: invite sent, row changes to Invite Sent, profile data preserved.
  • When the user accepts, OTP verification applies (AT-18).
↻
Continuation loop: After creating a user or traveler, "Add another" loops back to card selection. "Done" returns to the admin table.
3
User Lifecycle Management

Ongoing actions available from the admin table's edit modal. Actions differ by row state.

Admin
AT-6 AT-13 AT-15
Edit active user (pencil icon)
Modal with two tabs:
  • Permissions tab: Admin on/off toggle (switch, with warning when on: "Admins can add and remove users, manage roles, and access organization settings."). Policy tier selector (Guest / Default / Executive).
  • Traveler Profile tab: First name, last name, profile email ("For booking notifications. Independent from login email."), DOB, gender. Login email is not editable.
  • Last-admin protection (AT-15): If this is the only admin, turning off admin and deactivation are both blocked. Error: "This is the only admin. Add another admin before deactivating."
  • Deactivate link at bottom of modal (see below).
Admin
AT-8
Deactivate user
Confirmation dialog: "This will revoke [Name]'s portal access. Their traveler profile will be kept so you can still book for them. You can reactivate their access at any time."
  • Portal access revoked, login disabled.
  • User entity persists: login email, role, traveler profile, user-to-profile mapping all preserved.
  • Traveler profile remains bookable by arrangers.
  • Policy tier preserved on deactivation P1. If not preserved, admin re-assigns on reactivation.
  • Row changes to Deactivated.
Admin
AT-16
Reactivate deactivated user
Restores portal access. Generic email invitation sent. User must complete OTP verification (AT-18) on next login. Login email, role, profile, and mapping all preserved. Tier restored if preserved P1. Row changes to Active.
Admin
AT-9
Delete traveler profile
Available on ghost traveler rows and deactivated user rows. NOT on active users (deactivate first) or invite sent rows (cancel first). Permanent and irreversible. Booking history remains but profile is removed.
System
AT-17
Incomplete profile indicator
Warning icon on rows where a traveler profile exists but is missing date of birth or gender. Shown on active users (with profile), deactivated users, and ghost travelers. NOT on invite sent rows. Disappears once both fields are present.
4
Entity State Transitions

All possible states and the actions that move an entity between them.

Active User

→
Deactivated via "Deactivate" in edit modal (AT-8)
→
Cannot be deleted directly. Deactivate first.

Invite Sent

→
Active when user accepts invitation + completes OTP verification (AT-18)
→
Removed via "Cancel" inline link (AT-11)
→
Cannot be edited or deactivated. Cancel first.

Deactivated

→
Active via "Reactivate" in edit modal (AT-16) + OTP verification on next login (AT-18)
→
Removed via "Delete" in edit modal (AT-9)

Ghost Traveler

→
Invite Sent via "Grant portal access" (G2U-1) P1
→
Removed via "Delete traveler profile" (AT-9)
!
Key Design Decisions
1
Login email is write-once. Set at invitation. Cannot be changed. To change: deactivate the account and create a new invitation.
2
Login and profile emails are independent. Login email lives in URP (authentication). Profile email lives in STP (booking notifications). They can differ.
3
Every user must have a policy tier. Default is assigned if none selected. Ghost travelers do not have their own tier; they inherit the booker's tier at checkout.
4
Admin role is not assignable at creation. All new users are Travelers. Admin is assigned individually via the edit modal after the invite is accepted. Deliberate, individual, reversible.
5
Deactivate preserves everything. Login email, role, traveler profile, user-to-profile mapping, policy tier (P1). Reactivate restores access in one step with no data re-entry. Deletion is separate and irreversible.
6
Last-admin protection. Cannot deactivate or demote the last admin. Must promote another user first.
7
Arranger is a behavior, not a role. Any user with portal access can book for any ghost traveler. No separate permission needed.
8
Invitations do not expire in MVP. No expiry, no follow-up/reminder emails. Under evaluation for future.
9
OTP email verification at first account creation (AT-18). The invitation link proves the recipient received the email, but not that they control the inbox at the time of account creation. A one-time password sent to the login email verifies current email ownership. Applies to all invitation types: seed admin, user invites, reactivation, and ghost-to-user conversion. OTP expires after 10 failed attempts; validity window TBD with engineering.