[emkhalid]

Explanation of Change

Only shows the Home and FAB Travel actions for provisioned workspaces. Normal booking no longer collects legal names through the admin-only workspace Travel route; legal names remain part of the admin provisioning flow.

This prevents members from reaching the workspace Travel route that renders NotFound after their role changes.

Fixed Issues

$ #85803
PROPOSAL: #85803 (comment)

Tests

Preconditions:

• Use a fully provisioned Travel workspace with terms accepted.
• Invite a private-domain user with missing legal-name details as an admin.

1. Sign in as the invited admin and verify Travel appears on Home.
2. As the workspace owner, demote that admin to member.
3. As the member, select Travel and then Book travel if the Travel RHP opens.
4. Verify the workspace legal-name page and “Hmm... it’s not here” do not appear.
5. Using a Travel-enabled but unprovisioned workspace, verify Travel is hidden from both the Home quick actions and the narrow-screen green + menu.

• Verify that no errors appear in the JS console

Offline tests

Repeat step 5 offline after loading the workspace data while online.

QA Steps

Same as tests.

// TODO: These must be filled out, or the issue title must include "[No QA]."

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

macos-fix.mov

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/components/BookTravelButton.tsx	84.93% <ø> (+0.59%)	⬆️
...nents/Navigation/QuickCreationActionsBar/index.tsx	92.04% <100.00%> (ø)
...bar/FABPopoverContent/menuItems/TravelMenuItem.tsx	4.34% <0.00%> (ø)
... and 122 files with indirect coverage changes

[melvin-bot]

@Krishna2323 Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f4989d6fc5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Resume non-admin booking after account verification

When an unvalidated non-admin taps Book travel on a provisioned/accepted workspace while the IS_TRAVEL_VERIFIED beta is enabled, this navigation includes a policyID but does not set a non-admin resume target. VerifyAccountPage interprets any policyID in that beta as navigateForwardTo = TRAVEL_ENABLE, so after OTP validation the member is sent into the enablement/terms flow instead of going straight to TravelDot as this branch intends; they never hit the openTravelDotLink(..., onError) path unless they back out and press the button again.

Useful? React with 👍 / 👎.

[emkhalid]

Addressed. The verification flow could close without resuming booking or redirect beta users to Travel enablement. Added an explicit booking-resume intent and reused the existing verification-resume helper so non-admin booking continues to TravelDot, while admin provisioning remains unchanged. Added regression tests for both paths.

[trjExpensify]

Good from product on avoiding a NotFoundPage.

CC'ing @stitesExpensify for eyes on the solution though.

[Krishna2323]

Will start reviewing today.

[Krishna2323]

@emkhalid A member of a travel-enabled but unprovisioned workspace now gets "Something went wrong. Please try again later." It's better than the old dead end, but still misleading since Travel just isn't set up yet and retrying won't help.

Travel already has similar messaging elsewhere — travel.blockedFeatureModal and travel.domainPermissionInfo.restriction — so a generic error feels a bit out of place here.

@stitesExpensify two things:

1. Should we have a specific message for this state, e.g. "Travel isn't set up for this workspace yet — ask a workspace admin to enable it"?
2. Does GenerateSpotnanaToken distinguish "workspace not provisioned" from a real transient failure? We'd need that to show the right message.

web_chrome.mp4

[stitesExpensify]

I'm a bit confused by this solution tbh cc @marcochavezf

The behavior should be:

1. The travel button does not show up at all on the home page unless the policy is provisioned for travel (isWorkspaceProvisionedForTravel not policy.isTravelEnabled).
2. Legal name is only collected when the policy is being provisioned (terms are being accepted) by an admin

[marcochavezf]

Oh I see, I thought this was a regression of an expected behavior, also I wasn't aware of isWorkspaceProvisionedForTravel

@emkhalid could you change the solution to what @stitesExpensify suggested? (cc @Krishna2323) Apologies for the confusion!

[emkhalid]

Thanks for the clarification, I am working on it.

[emkhalid]

@Krishna2323, I’ve updated the solution based on the above clarification:

• Home and FAB Travel actions are now shown only for provisioned workspaces.
• Normal booking no longer collects legal names through the admin-only workspace route, preventing members from reaching the NotFound page.
• Legal-name collection remains unchanged in the admin provisioning flow.

Could you please re-review the updated approach when available?

[emkhalid]

@Krishna2323 conflicts resolved can you please review, Thanks!

[Krishna2323]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately and each prop has a /** comment above it */
  • The file is named correctly
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
  • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
  • All JSX used for rendering exists in the render method
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

android_hybrid.mp4

Android: mWeb Chrome

android_mWeb.mp4

iOS: HybridApp

ios_hybrid.mp4

iOS: mWeb Safari

ios_mWeb.mp4

MacOS: Chrome / Safari

web_chrome.mp4

[Krishna2323]

@MelvinBot review

[MelvinBot]

🤖 Code review — looks solid, aligned with the requested behavior. The changes correctly implement both points from stitesExpensify's clarification: gate the Travel entry points on provisioning (isWorkspaceProvisionedForTravel, not the stale isTravelEnabled flag), and stop collecting legal names outside the admin provisioning flow. No dead code is left behind and the tests cover the new behavior.

Root cause fix is correct: the NotFound was caused by BookTravelButton routing members to the admin-only WORKSPACE_TRAVEL_MISSING_PERSONAL_DETAILS route. Removing that pre-check (BookTravelButton.tsx:130) resolves it — for a provisioned workspace a demoted member now falls through to openTravelDotLink, which matches the issue's "Travel page opens" expected result.

Verified:

• The removed areTravelPersonalDetailsMissing / WORKSPACE_TRAVEL_MISSING_PERSONAL_DETAILS usages are still referenced by the admin provisioning + billing flows (EnableTravelContent.tsx, WorkspaceTravelBillingSection.tsx), so legal-name collection is preserved where it belongs and no code is orphaned.
• isPolicyProvisioned is still used further down bookATrip (legacy request-access path), so it wasn't left dangling after the pre-check was removed.
• email and allPolicies are both in scope for the new QuickCreationActionsBar memo, and the useMemo dep array [allPolicies, email] is correct.

Minor observations (non-blocking)

1. Inconsistent accessibility check between the two entry points. QuickCreationActionsBar/index.tsx:80-83 gates on isWorkspaceProvisionedForTravel(...) && isPolicyAccessible(policy, email ?? ''), while TravelMenuItem.tsx:35 gates only on isWorkspaceProvisionedForTravel(activePolicy?.travelSettings). This is fine as-is — QuickCreationActionsBar iterates over all policies so it needs to filter out ones the user has no role in, whereas TravelMenuItem only looks at activePolicy (which the user is a member of). Just flagging the asymmetry in case future readers wonder why only one has the isPolicyAccessible guard.

2. Edge case: if email hasn't loaded yet in QuickCreationActionsBar, isPolicyAccessible(policy, '') returns false and Travel is briefly hidden until it loads. Harmless (it re-renders once email resolves), just worth being aware of.

3. Tests: the added tests (BookTravelButtonTest "does not collect a missing legal name outside the travel enablement flow", QuickCreationActionsBarTest "does not show travel for a workspace that is not provisioned and has a stale enabled flag") are well-targeted and cover exactly the regression scenarios. I reviewed them statically but was not able to execute the Jest suite in this environment, so please rely on CI for the green check.

Verdict: the implementation matches the agreed approach and the linked issue's expected behavior. Once CI is green and the manual test steps (especially step 5 — Travel hidden on a Travel-enabled but unprovisioned workspace) are confirmed on the recorded videos, this looks good to me.

---

view run

[Krishna2323]

LGTM!

@emkhalid please merged main.

[emkhalid]

@emkhalid please merged main.

Done.

[stitesExpensify]

All you @marcochavezf

[github-actions]

🚧 marcochavezf has triggered a test Expensify/App build. You can view the workflow run here.

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #98227.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-a2a0303-1e6b60c-4ba85f158fbf47cd39a63a008c5067fec57e8d7c/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-a2a0303-1e6b60c-a75d9cfd5c13d6dc019b17e6e97565c31a96c974/index.html

Web 🕸️
https://98227.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[OSBotify]

🚀 Deployed to staging by https://github.com/marcochavezf in version: 9.4.66-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[MelvinBot]

Yes — help site changes were required. Draft PR: #100104

Why: this PR changed when the Travel booking entry points appear. Before, Book travel in the + menu (and the Travel quick action on Home) showed as soon as a workspace had isTravelEnabled set — that is, as soon as an admin flipped the Travel toggle in More features. Now both only appear when the workspace is actually provisioned for Expensify Travel and the user is still a member of it. Two help site claims went stale as a result.

Stale claim	Where
"Once Expensify Travel is enabled: Team members can book flights, hotels, cars, and trains" — the toggle alone is no longer enough	Enable-Travel-on-a-Workspace.md:25-27
"If you don't see Book travel, ask a Workspace Admin to enable Expensify Travel on the workspace" — points at the toggle, not at completing setup	9 travel articles

What the draft PR changes (docs only, 10 files):

• travel/company-setup/Enable-Travel-on-a-Workspace.md — added a ## How to finish Expensify Travel setup so members can book travel section (Workspaces > [Workspace Name] > Travel > Let's go, then legal name / workspace address / admin email domain / Legal entity tax ID, then terms), noted that toggling Travel on does not finish setup, reworded "What happens after enabling Expensify Travel" to trigger on completed setup, added an FAQ for "Why don't my members see Book travel after I turned on the Travel toggle?", and recorded that members are no longer asked for their legal name at booking time.
• 9 travel articles — rewrote the "If you don't see Book travel" line to say setup must be finished, and converted the full help.expensify.com URL to a relative link per HELP_AUTHORING_GUIDELINES.md.

UI verification and authoring notes

Labels were checked against dev NewDot web, not written from memory:

• More features → the toggle is Travel, under the Spend section.
• Workspace left menu gains an item labeled Travel.
• The workspace Travel page is headed Get started with Expensify Travel with a Let's go button.
• On a workspace with the toggle on but setup incomplete, neither the Home quick actions row nor the + menu shows any travel entry — which is exactly the new behavior this PR introduces.

Applied HELPSITE_NAMING_CONVENTIONS.md (bolded UI labels, exact casing, navigation tabs phrasing), HELP_AUTHORING_GUIDELINES.md (task-based ## headings, single # title plus # FAQ, relative links only), and TEMPLATE.md.

Two things I deliberately left out:

• The Home quick actions row is not documented anywhere on the help site today, so I did not introduce it. The + menu is the documented path and covers the same behavior change.
• The removed missing-legal-name prompt was never documented, so there was nothing to delete — I only recorded where legal name is collected now.

One thing I could not do: GitHub rejects emkhalid as an assignee on Expensify/App (read-level access, so not in the assignable list). The label HelpDot and the PullerBear review request are both applied, and you're tagged in the PR body. Once you comment on #100104 you become assignable and can self-assign.

@emkhalid, please review the linked help site PR and confirm it reflects the current behavior. Then mark the linked help site PR Ready for review

---

view run

[kavimuru]

@emkhalid Applause does not have private domain, could you help us how to execute this one?

Invite a private-domain user with missing legal-name details as an admin.

cc @stitesExpensify @trjExpensify

[emkhalid]

@emkhalid Applause does not have private domain, could you help us how to execute this one?

Invite a private-domain user with missing legal-name details as an admin.

cc @stitesExpensify @trjExpensify

Thanks for checking. You can use a fresh @applause.expensifail.com account for the invited user—Expensifail is treated as a private/work domain by the app.

Please leave its legal name unset, invite it to the Travel workspace as an admin, then demote it to member and continue with the test steps.

[OSBotify]

🚀 Deployed to staging by https://github.com/marcochavezf in version: 9.4.68-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	cancelled 🔪

[OSBotify]

🚀 Deployed to production by https://github.com/francoisl in version: 9.4.68-1 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

• Android