[$250] [Exploratory] Spend-Send invoice navigates to “Hmm not here” and inconsistent back navigation

[jponikarchuk]

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.3.64-23
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/13176671/test-cases/41237461
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: User Settings

Action Performed:

1. Launch app
2. Login with new gmail account via get paid by employer
3. Go to Spend
4. Search Type: invoice
5. Tap send invoice
6. Note directed to hmm not here
7. Tap device back button and note user directed to previous page correctly
8. Tap send invoice again
9. Tap app top left arrow in hmm not here page
10. Note user not directed to previous page instead directed to workspace page

Expected Result:

Instead of showing the “Hmm not here” page, the app should display a proper empty-state or informative screen indicating that no workspace is available or required to send invoices.

Using the top-left back arrow on the “Hmm not here” page should consistently redirect the user back to the previous page (Spend/search page), same as the device back button behavior.

Actual Result:

When a new user without any workspace taps “Send invoice” from Spend → Search → Type: Invoice, the app redirects to the “Hmm not here” page.

After tapping “Send invoice” the second time and using the top-left back arrow on the “Hmm not here” page, the user is redirected to the workspace page instead of the previous Spend/search page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054387577083017709
• Upwork Job ID: 2054387577083017709
• Last Price Increase: 2026-05-13

[MelvinBot]

Proposal

What is the root cause of that problem?

There are two issues here:

1. "Send invoice" navigates to "Hmm not here": When a user without an admin workspace taps "Send invoice" from the empty search view, EmptySearchView.tsx calls startMoneyRequest(INVOICE, generateReportID()), which navigates to IOURequestStartPage. That page wraps content in AccessOrNotFoundWrapper, which evaluates the CREATE access variant. This calls canSendInvoice(), which returns false for users with no admin workspace that has invoices enabled — causing the not-found page to render.

2. Inconsistent back navigation: PageNotFoundFallback checks isPolicyNotAccessible first. Since the policy is undefined (the randomly generated reportID has no associated report/policy), isPolicyNotAccessible is true, so it calls goBackFromWorkspaceSettingPages(). That function checks if the previous route is REPORTS_SPLIT_NAVIGATOR; since the user came from Search, it navigates to WORKSPACES_LIST instead of going back. The hardware back button works correctly because IOURequestStartPage registers useAndroidBackButtonHandler which calls Navigation.closeRHPFlow(), bypassing this logic entirely.

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

In PageNotFoundFallback, when isMoneyRequest is true and isPolicyNotAccessible is true, the back button should call Navigation.goBack() without a route argument (or use Navigation.closeRHPFlow()) instead of calling goBackFromWorkspaceSettingPages(). The current code conflates two scenarios: accessing an inaccessible workspace settings page vs. a money request flow failing an access check with no workspace context. The fix should add an isMoneyRequest check before the isPolicyNotAccessible branch:

if (isPolicyNotAccessible) {
+   if (isMoneyRequest) {
+       Navigation.goBack();
+       return;
+   }
    goBackFromWorkspaceSettingPages();
    return;
}

What alternative solutions did you explore? (Optional)

• Hiding the "Send invoice" button in EmptySearchView when canSendInvoice is false would prevent the user from reaching this page at all. However, this doesn't fix the general back-navigation bug for money request not-found pages, and the button visibility may be intentional to prompt workspace creation.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[neerajbachani]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-13 18:10:23 UTC.

Proposal

What is the root cause of that problem?

Symptom 1 — “Hmm… it’s not here” instead of a helpful empty state

Spend → Search → type Invoice → empty results always offered Send invoice, which called startMoneyRequest(INVOICE, …) with no prior check. The invoice start screen is wrapped in AccessOrNotFoundWrapper with CREATE access. For iouType === INVOICE, that path requires canSendInvoice(allPolicies, login) (admin workspace with invoicing enabled). When that is false, the wrapper shows the generic not-found page. So the UI advertised an action the access layer is defined to reject.

Symptom 2 — header back vs device back disagreed on the not-found screen

PageNotFoundFallback handled isPolicyNotAccessible first and called goBackFromWorkspaceSettingPages(), which can send the user to Workspaces when the root stack does not look like inbox under the modal. The money-request start screen’s device back still runs Navigation.closeRHPFlow() from IOURequestStartPage while that route is focused, so users saw two different exit strategies for the same blocked flow. This is not tied to “get paid by employer” or small screens only; it is policy capability + which back handler runs.

What I verified in code / diff

• Entry: invoice empty state lived only in src/pages/Search/EmptySearchView.tsx; no canSendInvoice gate before navigation.
• Exit: src/pages/Search/AccessOrNotFoundWrapper.tsx PageNotFoundFallback mixed workspace-settings back logic with money-request not-found.

---

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

A — Gate the invoice empty state on the same rule as invoice creation (primary fix for Symptom 1)

• Compute userCanSendInvoice with canSendInvoice(allPolicies, login) (same idea as FAB InvoiceMenuItem).
• Only show Send invoice when true.
• When false: show new copy under search.searchResults.emptyInvoiceResults.*CannotSend* and offer New workspace → ROUTES.WORKSPACE_CONFIRMATION.getRoute(Navigation.getActiveRoute()) when policy creation is not restricted; otherwise only the restricted subtitle.

B — Money-request not-found uses the same RHP exit as the live IOU screen (primary fix for Symptom 2 + wide layout)

• In PageNotFoundFallback, if isMoneyRequest, call Navigation.closeRHPFlow() and return before goBackFromWorkspaceSettingPages() / generic goBack.
• Keep goBackFromWorkspaceSettingPages() for real workspace-settings not-found (!isMoneyRequest && isPolicyNotAccessible).
• Set shouldShowBackButton to true when isMoneyRequest so wide layouts still get a header back that matches the flow exit.

C — Tests and locales

• Extend tests/ui/components/EmptySearchViewTest.tsx: SESSION + CurrentUserPersonalDetailsProvider; cases for cannot-send vs invoice-eligible policy (areInvoicesEnabled, admin).
• Add the three new keys next to existing emptyInvoiceResults strings in all shipped locale files so TranslationDeepObject<typeof en> stays aligned.

Minimal diff (for understanding only — not the full patch)

AccessOrNotFoundWrapper.tsx — money request exits the RHP first; workspace path unchanged for non–money-request.

 onBackButtonPress={() => {
+    if (isMoneyRequest) {
+        Navigation.closeRHPFlow();
+        return;
+    }
     if (isPolicyNotAccessible) {
         goBackFromWorkspaceSettingPages();
         return;
     }
-    Navigation.goBack(policyID && !isMoneyRequest ? ROUTES.WORKSPACE_OVERVIEW.getRoute(policyID) : undefined);
+    Navigation.goBack(policyID ? ROUTES.WORKSPACE_OVERVIEW.getRoute(policyID) : undefined);
 }}
-    shouldShowBackButton={... ?? (!shouldShowFullScreenFallback ? shouldUseNarrowLayout : undefined)}
+    shouldShowBackButton={... ?? (isMoneyRequest ? true : !shouldShowFullScreenFallback ? shouldUseNarrowLayout : undefined)}

EmptySearchView.tsx — invoice branch: subtitle + buttons from capability (conceptual).

+const userCanSendInvoice = canSendInvoice(allPolicies, currentUserLogin);
+// subtitle: invoiceSubtitleKey from cannot-send vs can-send + hasSeenTour / restricted
+// buttons: test drive (optional) + either Send invoice OR New workspace (if allowed)

en.ts (same keys added in other locales):

 emptyInvoiceResults: {
     ...
+    subtitleCannotSendInvoice: '...',
+    subtitleWithOnlyCreateButtonCannotSendInvoice: '...',
+    subtitleCannotSendInvoiceRestricted: '...',
 },

---

What alternative solutions did you explore? (Optional)

• Back-only change in PageNotFoundFallback: Fixes Symptom 2 but users still hit not-found from Search if any other CTA or deep link starts invoice without capability.
• Hide invoice type in Search when !canSendInvoice: Search already keeps Invoice visible when the user has invoice-related history but may not be allowed to send; hiding the type is the wrong product tradeoff; fixing the empty-state CTA matches the issue’s “informative empty state” expectation.
• Weakening canSendInvoice in the wrapper: Rejected; security/product boundary should stay; UX belongs in Search empty state + consistent exit on not-found.

Reminder: Plain English, brief. No PR unless hired. Minimal snippets above are illustrative; full change is in branch diff (~189 insertions / 32 deletions across 13 files).

Results: