[Due for payment 2026-08-27] Expense - Tapping "Submit to employer" and using device back button leads to workspace chat

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.46-2
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #97057
Email or phone of affected tester (no customers): applausetester+ib0036@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Motorola MotoG60 / Android 12 (Hybrid app)
App Component: Money Requests

Action Performed:

Prerequisite: User expensifail account.
Prerequisite 2: Account has Self DM and only one workspace.

1. Open the Expensify app.
2. Navigate to Self DM.
3. Create a manual expense.
4. Tap on "Submit to my employer"
5. On confirm page, use device´s back button.
6. Note that you land on workspace chat instead of returning to Self DM.

Expected Result:

Using back button from confirm page after starting "Submit to my employer" flow, should return to Self DM.

Actual Result:

Tapping on "Submit to my employer" and using device´s back button on confirm page, leads to workspace chat instead of returning to Self DM.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7221454_1785376405261.Employ_3.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7221454

Issue Owner

Current Issue Owner: @abzokhattab

[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/e09c98a52a9fce0fd8fe9deffad47acba16d4dfbbbf4b381c489b52bfd2d2891

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #97057

[melvin-bot]

@iwiznia @hungvu193 you have been assigned to this deploy blocker because you reviewed the offending PR: #97057

[melvin-bot]

@abzokhattab you have been assigned to this deploy blocker because you authored the offending PR: #97057

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug (fix belongs in Expensify/App)
Causing PR: #97057 - "Fix Submit to my employer: Report field showing None and back button swapping the report" by @abzokhattab (High confidence)
Related Issues: #96798 and #96796 (the two bugs #97057 set out to fix — a revert reintroduces both)

Recommendation: ROLL FORWARD (targeted fix)

The one-line rebinding that #97057 added to fix the "Report field shows None" bug is what flips the back-button destination to the workspace chat; the same PR already solved this exact problem for the zero-workspace branch, so the safe move is a small targeted follow-up rather than a revert that would reintroduce two just-fixed bugs. REVERT is a clean fallback (the PR only touches ReportUtils.ts + tests) if a fix cannot land quickly.

Assigned: @abzokhattab (PR author), @hungvu193 and @iwiznia (approving reviewers) — already auto-assigned to this blocker.
Labels: No change. This is a frontend bug, so DeployBlockerCash stays. No DeployBlocker (Web) label is present, so nothing to remove.

📋 Detailed Analysis

Evidence

• The bug is staging-only (9.4.46-0), not on production, which points at a PR in the current StagingDeployCash (Deploy Checklist Deploy Checklist: New Expensify 2026-07-29 #97375). Fix Submit to my employer: Report field showing None and back button swapping the report #97057 merged 2026-07-29 and is in that deploy.
• Fix Submit to my employer: Report field showing None and back button swapping the report #97057 is specifically the "Submit to my employer" flow and its back-navigation — the exact flow in this report.
• The repro uses an account with exactly one workspace, which hits the filteredPoliciesCount === 1 branch of createDraftTransactionAndNavigateToParticipantSelector.
• Comparing the PR's merge commit f9e6fa9 against its parent 78f9b1e, the only change to that branch is the added line:
  setMoneyRequestReportID(transactionID, policyExpenseReport.reportID); (src/libs/ReportUtils.ts:11907). The Navigation.navigate(...MONEY_REQUEST_STEP_CONFIRMATION...) call and its route reportID argument are byte-identical before and after the PR — so the route param is not the trigger; the draft transaction's reportID field is.

Verification

• Affected file(s): src/libs/ReportUtils.ts (the change), src/libs/IOUUtils.ts, src/pages/iou/request/step/IOURequestStepConfirmation.tsx, and src/pages/iou/request/step/confirmation/getSubmitExpensePreMountDestinationRoute.ts (the consumers that turn transaction.reportID into the revealed report).
• Confirmed Fix Submit to my employer: Report field showing None and back button swapping the report #97057 modifies src/libs/ReportUtils.ts (gh pr view 97057 --json files): it touches only src/libs/ReportUtils.ts + two test files.
• Confirmed line 11907 is present at current origin/main HEAD (99c3ee1).

Root Cause

Before #97057, in the single-workspace branch the draft transaction kept its inherited reportID = UNREPORTED_REPORT_ID (it lives on the self DM). #97057 rebinds it to the destination workspace expense chat via setMoneyRequestReportID so the confirmation page stops rendering "None" and resolves the right policy (the intended fix for #96798). That rebinding has a navigation side effect on the back/dismiss destination:

1. resolveReportForMoneyRequest returns undefined when transaction.reportID === UNREPORTED_REPORT_ID. After the rebinding it instead returns the workspace expense chat, so the confirmation page's report is now that chat.
2. destinationReportID is derived from that report (routeDestinationReportID = report?.reportID). Pre-PR it resolved to undefined (and selfDMReportID is undefined here because this is a SUBMIT, non-self-DM destination); post-PR it resolves to the workspace chat.
3. getSubmitExpensePreMountDestinationRoute then pre-inserts ROUTES.REPORT_WITH_ID.getRoute(destinationReportID) under the RHP (this flow is not global-create, so !isFromGlobalCreate makes report pre-insert eligible and destinationReportID is now valid). On device back the RHP dismisses and reveals that pre-inserted workspace chat instead of the self DM the user started from.

Net: pre-PR destinationReportID was undefined → no pre-insert → back simply revealed the self DM behind the RHP (correct). Post-PR it is the workspace chat → back reveals the workspace chat (the reported regression).

Notably, #97057 anticipated this class of problem for the zero-workspace branch — it computes visibleReportID = isReportTopmostSplitNavigator() ? Navigation.getTopmostReportId() : undefined and threads it through so back returns to the report the user was viewing (ReportUtils.ts:11884). The single-workspace branch got the setMoneyRequestReportID rebinding but not the equivalent back-destination handling, which is the gap.

Suggested targeted fix

Mirror the zero-workspace branch: for the filteredPoliciesCount === 1 path (and the identical isRestrictedToPreferredPolicy path at ReportUtils.ts:11927), thread the visible/source report (the self DM the flow started from) into the confirmation navigation so destinationReportID/back resolves to it — e.g. pass a backTo/backToReport for the report the user was on rather than letting the pre-mount fall through to the newly-bound workspace chat. This keeps the #96798 fix (report field shows the destination workspace, not "None") while restoring the correct back-to-self-DM behavior.