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.
Related
Related guides
Groups in Trips — what they are, when to use them
Groups are Trips' primitive for hosted cohorts — cruise groups, escorted tours, themed trips, corporate incentives. This article explains what a Group is, when to reach for one instead of individual Trips, and how the pieces fit together.
Group financials — sales, commission, and per-member payment tracking
How the Financials tab on a Group rolls up sales, commissions, and per-member payment status across every attached Trip's invoices. The three sub-tabs (Overview, Per member, Commission), how "days behind deposit" is calculated, and how the numbers flow into your regular Sales and Commission reports.
Creating a Group — statuses, destinations, and settings
A field-by-field tour of the New Group form and the Settings tab: the five status states (Draft / Open / Sold out / Waitlist / Archived), the destinations list that feeds every member's Trip, roommate matching, and the archive workflow.