When a client says they can't sign into the portal, it's almost always one of a handful of things. Here's how to figure out which — and how you (the agent) push them past it without bouncing tickets back and forth.
A "portal invite" is really a claim link — a one-time link the client clicks to set a password. After they've set the password they sign in normally with email + password at your-agency.urtravelpro.com/portal/login (or your custom domain). The same flow handles forgotten passwords — they request a reset and get a new claim link by email.
The claim link says it's expired or invalid.
Claim links are valid for 7 days from the moment you send them. After that the client sees an "invalid link" page. Resend from the trip's Travelers strip — that rotates the token and starts a fresh 7-day window. No data is lost.
The client clicked the link but landed on a "page not found" or "wrong agency" screen.
Portal URLs are agency-scoped — /portal/{slug}/... — so a link minted for Agency A won't work on Agency B's subdomain. If they pasted the link into the wrong tab, or your agency's Portal slug was changed after the link was sent, the link goes dead. Resend; the new link bakes in the current slug.
They tapped the link in their email app and the password page won't save.
Gmail and Outlook open links in their own in-app browser, which sometimes loses cookies between the password form and the redirect. Tell the client to copy the link and paste it into their real browser (Safari, Chrome) before setting a password. Or just resend and ask them to long-press → Open in browser.
They already claimed the link and now the link does nothing.
Claim links are single-use — once they've set a password, that token is cleared. Going back to the original email lands them on the "invalid link" screen. They should sign in normally at /portal/login with the email + password they just set. If they forgot the password, use Forgot password on the login page or Send password reset from the trip.
They're sure they typed the right password but it bounces them.
Two things to check. First, the email they're typing — must match the email on the contact record exactly (lowercase, no aliases). Second, the account isn't disabled. Open the contact and look at the Access tab — if it says Disabled, someone (or the archive cascade) turned it off. Click Reactivate & reinvite to flip it back on and mint a fresh link.
I want to see when (or whether) they actually tried.
Every sign-in attempt — success or fail — is logged with the timestamp, IP address, user agent, and a reason code (success, fail_password, fail_disabled, magic_link_claim). Engineering can pull the trail for you if a client claims they never got in; include the email address and the rough date range when you open a ticket.