[$250] Travel-"What's your legal name" page instead of "You'll need to use your work email" message

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.4.16-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13177079/test-cases/41237920
Email or phone of affected tester (no customers): agexptest+pr190626c@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11/ Chrome, Samsung S23FE/ Android 16, iPhone 13 Mini/ iOS 26.3
App Component: Workspace Settings

Action Performed:

1. Navigate to staging.new.expensify.com
2. Sign up with a new Gmail account
3. Select any onboarding intent except the Manage my team's expenses
4. Create new workspace
5. Navigate to Workspace Settings > More Features
6. Enable the Travel feature toggle
7. Click on the Travel menu option > Let's Go

Expected Result:

The "Book travel" RHP is displayed with the following message: "You'll need to use your work email (e.g., name@company.com) with Expensify Travel, not your personal email (e.g., name@gmail.com)."

Actual Result:

The "What's your legal name?" RHP is displayed.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7185684_1781888925239.legal_name_screen.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Nathan Lemma
Bug ID: 7185684

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022068264724712363497
• Upwork Job ID: 2068264724712363497
• Last Price Increase: 2026-06-20

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/a237946d9bbc34c0dafa6c933e43ffbf8a2af2d228cedf06c31dba17d674bf99

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a personal-email user (e.g. @gmail.com) enables the Travel feature and clicks Travel > Let's Go, they are shown the "What's your legal name?" RHP instead of the expected "You'll need to use your work email…not your personal email" warning.

What is the root cause of that problem?

In bookATrip() the guard checks run top-to-bottom with early returns, and the legal-name check runs before the public-domain email check:

• BookTravelButton.tsx:126 — areTravelPersonalDetailsMissing(privatePersonalDetails) returns true for any account with no legalFirstName/legalLastName, navigates to the legal-name RHP, and returns.
• BookTravelButton.tsx:139 — isEmailPublicDomain(primaryContactMethod) (the work-email warning) sits after that early return, so it is never reached for a fresh account.

A brand-new signup has no legal name yet, so the legal-name guard fires first and the email warning is bypassed.

This also explains why the bug only repros for onboarding intents other than "Manage my team's expenses": that intent path pre-populates the user's legal name, so areTravelPersonalDetailsMissing returns false and execution reaches the email check.

Supporting evidence

• areTravelPersonalDetailsMissing — PersonalDetailsUtils.ts:593-595: return !privatePersonalDetails?.legalFirstName || !privatePersonalDetails?.legalLastName;
• isEmailPublicDomain — LoginUtils.ts:37-40 (gmail.com is in PUBLIC_DOMAINS_SET).
• Expected message string travel.publicDomainError.message — en.ts:4413 (exact "work email…not your personal email" text).
• Actual page string privatePersonalDetails.enterLegalName ("What's your legal name?") — en.ts:3525, rendered by TravelLegalNamePage.tsx.

What changes do you think we should make in order to solve the problem?

Reorder the guard checks in bookATrip() so the public-domain email check (and the phone-login check) run before the legal-name check. A personal-email user can never book travel, so they should see the work-email warning first rather than being asked to enter a legal name they'll never use.

Concretely, move the isEmailPublicDomain block (lines 139-142) and the SMS/phone block (lines 133-136) above the areTravelPersonalDetailsMissing block (lines 126-130).

What alternative solutions did you explore?

Skip the legal-name step entirely when the email is on a public domain — but simple reordering is cleaner and keeps each guard's responsibility intact.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94108) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[ahmdshrif]

Proposal

Please re-state the problem that we are trying to solve in this issue.

A user who signs up with a public-domain email (e.g. gmail.com) and clicks Travel → Let's Go is shown the "What's your legal name?" RHP instead of the "You'll need to use your work email…" public-domain message.

What is the root cause of that problem?

The eligibility guards in bookATrip() run in the wrong order. A brand-new account hits TWO true conditions at once — it has no legal name yet, and its primary login is a public domain. The missing-personal-details guard is checked first and returns, so the public-domain guard never runs.

1. Missing-details guard fires first and navigates to the legal-name page:
   

   App/src/components/BookTravelButton.tsx

   Lines 126 to 130 in cc90dd2

   	if (areTravelPersonalDetailsMissing(privatePersonalDetails)) {
   	shouldResumeBookingRef.current = true;
   	Navigation.navigate(ROUTES.WORKSPACE_TRAVEL_MISSING_PERSONAL_DETAILS.getRoute(policy?.id ?? String(CONST.DEFAULT_NUMBER_ID)));
   	return;
   	}

   
   (areTravelPersonalDetailsMissing = no legalFirstName/legalLastName, always true for a new account:

   App/src/libs/PersonalDetailsUtils.ts

   Lines 593 to 595 in cc90dd2

   	function areTravelPersonalDetailsMissing(privatePersonalDetails: OnyxEntry<PrivatePersonalDetails>): boolean {
   	return !privatePersonalDetails?.legalFirstName || !privatePersonalDetails?.legalLastName;
   	}

   )
2. The public-domain guard that shows the correct message only runs later, after that early return:
   

   App/src/components/BookTravelButton.tsx

   Lines 138 to 142 in cc90dd2

   	// Spotnana requires a private domain email for travel booking
   	if (isEmailPublicDomain(primaryContactMethod)) {
   	navigateToPublicDomainError();
   	return;
   	}

A public-domain user can NEVER be provisioned for travel, so that hard-stop must gate before we ask them to complete a profile — otherwise they fill in a legal name and still hit the work-email wall. This is the single entry point behind all Book-Travel surfaces (ManageTrips, GetStartedTravel), so all are affected.

What changes do you think we should make in order to solve the problem?

Move the areTravelPersonalDetailsMissing block (L126-L130) to run AFTER the phone-login and public-domain eligibility checks (L133-L142):

if (!primaryContactMethod || Str.isSMSLogin(primaryContactMethod)) { /* phoneError */ return; }
if (isEmailPublicDomain(primaryContactMethod)) { navigateToPublicDomainError(); return; }
// only now, for an eligible user, collect missing legal name:
if (areTravelPersonalDetailsMissing(privatePersonalDetails)) { /* legal-name page */ return; }

Regression safety: a private-domain user with missing details still reaches the legal-name page (just one check later) and the shouldResumeBookingRef resume path is unchanged.

What alternative solutions did you explore? (Optional)

Block the legal-name page itself for public-domain users — incomplete: it duplicates the domain check in a second place and leaves the phone-login user equally mis-routed. Reordering the guards once fixes every ineligible case at the source.

[lorretheboy]

Proposal

What is the root cause of that problem?

In bookATrip, the missing-personal-details check runs first, before the email validation. So a brand-new Gmail signup (who has no legalFirstName/legalLastName yet and a public-domain email) is sent to the legal-name page before the public-domain branch can ever run.

The personal-details check is evaluated first here:

App/src/components/BookTravelButton.tsx

Lines 126 to 130 in cc90dd2

	if (areTravelPersonalDetailsMissing(privatePersonalDetails)) {
	shouldResumeBookingRef.current = true;
	Navigation.navigate(ROUTES.WORKSPACE_TRAVEL_MISSING_PERSONAL_DETAILS.getRoute(policy?.id ?? String(CONST.DEFAULT_NUMBER_ID)));
	return;
	}

areTravelPersonalDetailsMissing returns true for any user with no saved legal name, which is always the case for a fresh account:

App/src/libs/PersonalDetailsUtils.ts

Lines 593 to 595 in cc90dd2

	function areTravelPersonalDetailsMissing(privatePersonalDetails: OnyxEntry<PrivatePersonalDetails>): boolean {
	return !privatePersonalDetails?.legalFirstName || !privatePersonalDetails?.legalLastName;
	}

Because that branch navigates and returns, the public-domain check below it never executes for this user:

App/src/components/BookTravelButton.tsx

Lines 138 to 142 in cc90dd2

	// Spotnana requires a private domain email for travel booking
	if (isEmailPublicDomain(primaryContactMethod)) {
	navigateToPublicDomainError();
	return;
	}

Causal chain: fresh Gmail account → no legal name saved → areTravelPersonalDetailsMissing is true → navigate to the missing-details (legal name) page and return → the isEmailPublicDomain branch that would show "You'll need to use your work email…" is skipped. A public-domain user should be stopped before being asked for personal details, since they can't book travel at all.

What changes do you think we should make in order to solve the problem?

Reorder the checks in bookATrip so the email-eligibility checks (the phone-login check and especially the isEmailPublicDomain check) run before the areTravelPersonalDetailsMissing check. A public-domain user then correctly lands on the public-domain error RHP, and only eligible (private-domain) users get prompted for their legal name.

Concretely, move this block down so it sits after the public-domain / admin-domain validation:

App/src/components/BookTravelButton.tsx

Lines 126 to 130 in cc90dd2

	if (areTravelPersonalDetailsMissing(privatePersonalDetails)) {
	shouldResumeBookingRef.current = true;
	Navigation.navigate(ROUTES.WORKSPACE_TRAVEL_MISSING_PERSONAL_DETAILS.getRoute(policy?.id ?? String(CONST.DEFAULT_NUMBER_ID)));
	return;
	}

so the email validation here is reached first for public-domain users:

App/src/components/BookTravelButton.tsx

Lines 138 to 142 in cc90dd2

	// Spotnana requires a private domain email for travel booking
	if (isEmailPublicDomain(primaryContactMethod)) {
	navigateToPublicDomainError();
	return;
	}

The auto-resume effect that re-triggers bookATrip after the legal name is saved still works, because once details are no longer missing the (now later) check simply passes through to the booking logic.

What alternative solutions did you explore? (Optional)

Alternatively, gate the missing-details branch with the eligibility condition (e.g. only navigate to the legal-name page when !isEmailPublicDomain(primaryContactMethod) and the contact method isn't an SMS login). This keeps the block where it is but avoids prompting ineligible users; reordering is cleaner since it reuses the existing public-domain branch as the single source of truth.

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @truph01 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022068264724712363497

[godzillaxbox19982014-lgtm]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Travel-"What's your legal name" page instead of "You'll need to use your work email" message

What is the root cause of that problem?

I traced this to the path that handles the issue-specific state:

• src/pages/workspace/expensifyCard/WorkspaceExpensifyCardAddWorkEmailPage.tsx:64 (navigate): Navigation.navigate(ROUTES.WORKSPACE_EXPENSIFY_CARD_VERIFY_WORK_EMAIL.getRoute(policyID, fundID));
• src/pages/workspace/expensifyCard/WorkspaceExpensifyCardAddWorkEmailPage.tsx:92 (navigate): Navigation.navigate(ROUTES.WORKSPACE_EXPENSIFY_CARD_VERIFY_WORK_EMAIL.getRoute(policyID, fundID));
• src/pages/workspace/WorkspaceInitialPage.tsx:399 (singleExecution): action: singleExecution(waitForNavigate(() => Navigation.navigate(ROUTES.WORKSPACE_EXPENSIFY_CARD.getRoute(policyID)))),
• The local evidence matches this recurring failure shape: shared workspace list builds options without the same eligibility filter as another workspace surface. Here, src/pages/workspace/expensifyCard/WorkspaceExpensifyCardAddWorkEmailPage.tsx:64 and src/pages/workspace/expensifyCard/WorkspaceExpensifyCardAddWorkEmailPage.tsx:92 do not agree on the same the issue-specific state value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

What changes do you think we should make in order to solve the problem?

• Update src/pages/workspace/expensifyCard/WorkspaceExpensifyCardAddWorkEmailPage.tsx:64 to derive the issue-specific state from the workspace setup and policy state that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/workspace/expensifyCard/WorkspaceExpensifyCardAddWorkEmailPage.tsx:92; that follows the safer family move to move the rule into the shared selector/helper, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Workspace, Policy, Categories, Tags, Rules surface and avoid changing account/admin permission surfaces, policy owner/current-user exceptions.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/Policy*.ts for the exact issue flow: Travel-"What's your legal name" page instead of "You'll need to use your work email" message.
2. Cover the counter-case near src/pages/workspace/expensifyCard/WorkspaceExpensifyCardAddWorkEmailPage.tsx:64 so valid existing the issue-specific state behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep the issue-specific state consistent at the first read/write boundary shown above.