Authentication and Staff Access

What this page is for

Authentication pages control how staff enter the workspace, activate invitation links, recover from access errors, and start audited impersonation sessions when support access is allowed.

Who should use it

Staff, owners, managers, support

Where to find it

/authentication/login, /authentication/register, /authentication/accept-invite?token=..., /authentication/impersonate?token=..., /authentication/error

Before you start

• Authentication flow completion gate: document login, invite activation, invite-only registration explanation, audited impersonation, and error handling from the current staff app.
• Login route is /authentication/login and requires Staff email and Password.
• Successful login creates a workspace session through the staff foundation API and redirects to /dashboard.
• Register route is /authentication/register and is informational because staff access is invite-only.
• Accept invitation route is /authentication/accept-invite?token=... and requires a pending unexpired invitation token.
• Accept invitation fields are Locale, Timezone, Create password, and Confirm password.
• Accept invitation password must be at least 8 characters and must match Confirm password before activation.
• Impersonation route is /authentication/impersonate?token=... and consumes a time-limited audited support token.
• Authentication error route is /authentication/error and sends staff back to Home instead of bypassing access control.
• Missing invite or impersonation token must stop activation and show an error rather than creating a session.
• Use staff email and password from the invitation activation flow. Do not share owner or staff credentials between employees.
• Accept invitation links before expiry, set locale/timezone correctly, and create a strong password during activation.
• Registration is informational for staff provisioning; staff accounts should normally be created by an owner/admin invite, not self-created.
• Support impersonation must include a reason and is audited. Staff should leave impersonation mode after the support task is complete.
• Authentication errors should not be bypassed by creating duplicate staff users unless the owner confirms the original invite/account is invalid.

Daily workflow

• Owner/admin invites staff from Staff & Access.
• Staff opens /authentication/accept-invite?token=..., verifies invited staff, workspace, expiry, locale, and timezone, sets a password, confirms it, then activates the session.
• On /authentication/login, staff enters Staff email and Password, waits for the server session, and confirms the tenant/subdomain is correct before operating People, POS, Schedule, or Admin.
• If staff opens /authentication/register, explain that access is invite-only and have an owner/admin create or resend the staff invite instead of asking the staff member to self-register.
• If support opens /authentication/impersonate?token=..., confirm the support reason, tenant, and audited context before operating; stop using the session when the support task is complete.
• For access issues, use the error page message to decide whether to request a new invite, reset credentials, or contact support.

Watch out

• Never ask staff to use dev-session or another tenant URL in production-like operation.
• If the wrong gym appears after login, stop and resolve tenant routing before creating records.
• Do not convert invite or impersonation query tokens into reusable links. Treat them as one-time/time-limited access secrets.
• Do not use the register page as an open signup path; production staff accounts are provisioned through Admin with role, permission template, and location access.

Related help

• Use the left menu to open related pages in Troubleshooting.
• Use Ask Docs for questions that are already covered in this public documentation.