[Due for payment 2026-06-19] [Due for payment 2026-06-18] [$250] After creating category on confirm page, app returns to category list instead of confirm page

[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: 9.4.5-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92161
Email or phone of affected tester (no customers): odjosdjosjnojdiosj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Click + > Create expense > Manual.
4. Enter amount > Next.
5. On confirm page, click Category.
6. Click Add category button.
7. Enter any name and save it.

Expected Result:

App will return to confirm page.

Actual Result:

App returns to category list instead of confirm page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7177427_1781135482443.3.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7177427

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022064954064300344819
• Upwork Job ID: 2064954064300344819
• Last Price Increase: 2026-06-11

Issue Owner

Current Issue Owner: @huult

[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/613c9e9ae403bb117a8ba891f3f598ff21e3a49f3c1b2d8487f318d4f46fe39e

[melvin-bot]

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

[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]

Proposal

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

On the expense confirmation page, opening Category → Add category and saving a new category returns the user to the category list instead of the confirmation page. This is a regression from #92161 (navigation migration part 2).

What is the root cause of that problem?

When the category list page opens the "Add category" page, it now passes the category list route itself as backTo (via Navigation.getActiveRoute()), instead of the confirmation page.

DynamicIOURequestStepCategoryPage.tsx:113

Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_CATEGORY_CREATE.getRoute(action, iouType, transactionID, reportID, reportActionID, Navigation.getActiveRoute()));

On save, the create page runs Navigation.goBack(backTo), so backTo = category list sends the user back to the list rather than the confirmation page:

IOURequestStepCategoryCreate.tsx:151-155

if (!isEditing && action === CONST.IOU.ACTION.CATEGORIZE && !backTo) {
    Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(action, iouType, transactionID, report?.reportID ?? reportID));
    return;
}
Navigation.goBack(backTo); // backTo = category list → wrong destination

Why this is a regression (before vs after #92161)

• Before: the category page passed its own backTo (the confirmation page) to the create page, and the create page's back button rebuilt the category route. So save → confirmation and cancel/back → category list were two distinct destinations.
• After: the create page back button was simplified to Navigation.goBack(backTo), and line 113 was changed to pass getActiveRoute() (the list) so the back button would still land on the list. But the save path also uses goBack(backTo), so saving now incorrectly lands on the list too.
• For comparison, selecting an existing category works correctly because it calls navigateBack() → goBack(backPath), where backPath resolves to the confirmation page via useDynamicBackPath.

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

On save, the create page should land on the confirmation page (matching the behavior of selecting an existing category), while the back/cancel button continues to return to the category list.

Recommended: in IOURequestStepCategoryCreate.tsx, after the new category is applied, navigate to the confirmation page for the non‑edit flow instead of goBack(backTo):

if (!isEditing) {
    Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(action, iouType, transactionID, report?.reportID ?? reportID));
    return;
}
Navigation.goBack(backTo);

This preserves the new back-button design (cancel still returns to the category list) and fixes the save destination. The existing CATEGORIZE && !backTo branch is subsumed by this and can be folded in.

Simpler alternative (one-liner): pass backPath instead of Navigation.getActiveRoute() at DynamicIOURequestStepCategoryPage.tsx:113. This fixes save, but because the create page's back button also uses backTo, cancel would then skip the list and return to confirmation too — a minor UX change worth confirming.

What alternative solutions did you explore? (Optional)

Restoring the pre-#92161 create-page back button (rebuilding the category route from params) would also work but reintroduces the reportActionID plumbing the migration removed, so it's the least clean option.

Confidence: High — clear regression introduced by #92161; the backTo value change at line 113 directly explains the symptom, and the working "select existing category" path confirms the intended destination is the confirmation page.

---

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

[huult]

Checking...