Rules - RHP does not open after workspace upgrade

[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.48-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #95310
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Log in with Expensifail account.
• Create a Collect workspace.

1. Go to staging.new.expensify.com
2. Go to Collect workspace settings > More features.
3. Enable Rules.
4. Go to Rules.
5. Enable Flag expenses older than.
6. Click Upgrade > Got it, thanks.

Expected Result:

Flag expenses older than RHP will open after workspace upgrade (similar to GL code in Categories page).

Actual Result:

Flag expenses older than RHP does not open after workspace upgrade.
This issue happens to all fields and tabs that require workspace upgrade in Rules.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7223160_1785554809400.2.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @Krishna2323

[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/6d3cdb7984190b822346369008df0569af30101750d3d8c1ad5884365555df02

[melvin-bot]

Triggered auto assignment to @neil-marcellini (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

Deploy Blocker Analysis

Culprit PR: #95310 — "Enable Rules for Collect workspaces with Control upgrade gating" by Krishna2323 (merged 2026-07-31, in the 9.4.48-0 StagingDeployCash). This PR introduced the entire Collect→Control Rules upgrade-gating flow and is beta-gated behind RULES_REVAMP, consistent with the report's "N/A - new feature, doesn't exist in prod." Confidence: High.

Root Cause: When a Collect admin taps a Control-only Rules field (e.g. "Flag expenses older than"), the app routes to the upgrade page with a backTo value. The working Categories/GL-code flow passes the field-specific RHP route as backTo, so after "Got it, thanks" the RHP opens. The Rules revamp flow instead hardcodes the Rules list page as backTo for every field — so after upgrade the user lands back on the Rules list and no RHP opens. This is why it affects all fields/tabs in Rules that require upgrade.

Recommended Fix (roll forward, not revert): In handleMenuItemPress (and the other Collect-gated entry points), pass each item's own destination RHP route as backTo to tryNavigateToControlPolicyUpgrade — e.g. ROUTES.RULES_MAX_EXPENSE_AGE.getRoute(policyID) for "Flag expenses older than" — mirroring the Categories GL-code pattern so goBack(backTo) opens the intended RHP after upgrade. A revert would tear out the whole feature (47 files, new betas, tests, and follow-up #96012), so a targeted fix is preferable. Blast radius is limited by the RULES_REVAMP beta gate.

Investigation details

Blob SHA adf7411a9109955331bc35ab39ab50be306de99c (9.4.48-0 staging HEAD).

• Broken backTo hardcoded to the Rules list instead of the field RHP: src/pages/workspace/rules/IndividualExpenseRulesSectionRevamp.tsx:99

  const rulesUpgradeBackTo = ROUTES.WORKSPACE_RULES.getRoute(policyID);

• Same backTo reused for every menu item regardless of target route: IndividualExpenseRulesSectionRevamp.tsx:102-107
• Upgrade navigation whose backTo default is also the Rules list page: src/libs/PolicyUtils.ts:1450-1456
• Post-upgrade goBack returns to backTo (the list), never opening the field RHP: src/pages/workspace/upgrade/WorkspaceUpgradePage.tsx:173-174

  case CONST.UPGRADE_FEATURE_INTRO_MAPPING.rules.id:
      return Navigation.goBack(route.params.backTo ?? ROUTES.WORKSPACE_MORE_FEATURES.getRoute(policyID));

Working reference (the "GL code in Categories" the report expects parity with), which passes the field-specific RHP route as backTo: src/pages/workspace/categories/CategorySettingsPage.tsx:336-353

---

Next Steps: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[neil-marcellini]

This page is hidden behind a beta, so it is not a deploy blocker.