Account Access
| Symptom | Check |
|---|---|
| Staff lands on the wrong page | Clerk session role, tenant slug, tenant membership, and backend session destination. |
| Technician cannot see a job | Assignment, repair-order state, branch scope, and Technician role. |
| Customer cannot enter portal | OTP session, tenant slug, customer link, and portal session expiry. |
| Customer code does not arrive | Confirm the email entered matches the intended workshop record, wait for the current code window, then use Resend code when enabled. SMS is not available unless the login page explicitly offers it. Do not ask the customer to share any code. |
| Customer entered the wrong email | Choose Change email and begin a new request. The previous challenge is not reused for the new contact. |
| Customer portal fails while another workspace is signed in | Keep the valid tenant customer OTP session authoritative. Staff, platform, Fleet Admin, and Driver sessions cannot replace it. If the OTP session is expired, revoked, malformed, or for another tenant, start a fresh customer login; do not grant or reuse the other role. |
| Customer cannot open a saved vehicle or history URL | Confirm the vehicle is still currently owned by that customer and use Garage to open the current record. Former-owner, Fleet-owned, other-customer, and cross-tenant vehicle IDs intentionally return the same safe unavailable behavior. |
| Browser repeatedly returns to sign-in | Clear expired/corrupted site cookies, then start a new sign-in or OTP session. Malformed session cookies are treated as signed out. |
| Fleet Admin cannot see active service or an approval | Confirm the Fleet account is active, the vehicle was fleet-owned at check-in, and the approval’s active rule names this Fleet Admin. Refresh the manual snapshot; do not use staff Fleet pages or another account URL. |
| Fleet workspace is unavailable | Authorized staff should check whether Fleet is enabled, the account is active and the user has the intended Fleet membership or Driver assignment. Privacy/provider review reminders do not block Fleet. The external page hides backend diagnostics; do not broaden permissions to bypass a denial. |
| Driver sees “No assigned vehicles” | Confirm the Driver membership is active and add or restore an active assignment if access is intended. Saved vehicle/history URLs remain unavailable until then. |
| Fleet user is finished on a shared device | Use Log out, then replay a protected Fleet route and confirm it returns to sign-in before another user takes over. |
| Feature page is unavailable | Entitlement, module readiness, provider readiness, and role permission. |
Use safe not-found behavior for unauthorized IDs. Do not tell a user whether another tenant’s record exists.
Customer login codes and contact changes
Customer sign-in has two stages: request a code with the registered email, then enter the six-digit code in one field. Paste and device OTP autofill are supported. The field clears after an attempt; enter the newest code again after a safe error. Change email starts a fresh request, and Resend code becomes available after the displayed challenge’s expiry. A sign-in started with Book service returns to booking after successful verification.
Submitting a registration request does not enable sign-in. Wait for staff approval, then use Customer sign in. If registration shows Verification is temporarily unavailable, contact the workshop; there is no form to complete until verification is configured. See request customer access.
If a customer receives a cooldown response, ask them to use the most recently issued code and wait for it to expire before requesting another. Repeated request or resend clicks for the same contact do not create additional deliverable codes.
The customer should enter the newest code on the same device. Motornauts staff and support must never ask for, receive, or enter that OTP. The login page intentionally gives the same safe response whether or not a customer record exists. Do not use that response to confirm an account or contact.
If a code stops working after staff change the customer’s email address or phone number, the customer must start a new login request with the current contact. Do not resend an older challenge to a changed contact.
When access still fails, authorized staff should check that the tenant has exactly one active customer record for the contact, that the customer and bound account are active, and that the contact belongs to the intended customer. Do not disclose duplicate records, alternative identities, one-time codes, challenge identifiers, or whether another account exists. Escalate ambiguous or occupied identity records for manual review instead of selecting or merging one.
Staff, platform, and fleet access uses Clerk and remains separate from customer OTP access. If Clerk sign-in finishes on the safe routing page, retry sign-in first. Authorized administrators may then check the role, tenant or fleet membership, and backend session destination in restricted tools; do not ask the user for a password, one-time code, token, request ID, or screenshot containing private account data.
External Fleet failures show generic safe guidance without a request ID. Authorized operators may correlate server logs through their restricted tools; Fleet Admins and Drivers should describe the company workspace, route they opened, and visible safe state instead of copying internal evidence.
Fleet setup required concerns the service center’s operational setup. Ask its administrator to check the displayed setup guidance. Privacy and provider review reminders do not require a separate approval to use Fleet. Fleet is not enabled points to the service center’s enabled features. A Driver’s No vehicles assigned means the workspace opened successfully, but that Driver has no current assignment. Access not confirmed does not establish a Fleet role or company membership.
Invitation email must be verified
Motornauts accepts a pending staff invitation only after Clerk reports the signed-in user’s primary email as verified. A matching but unverified address, a secondary fallback address, or a custom session claim does not grant tenant or platform access. Verify the primary address in the identity provider, then sign in again. Tenant administrators should revoke and reissue stale invitations rather than changing an existing identity’s contact details to force a match.