[$250] Unable to switch to Expensify Classic using the option under Account > Switch to Expensify Classic.

[m-natarajan]

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:
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @timothysmall
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Log in as a migrated customer
2. Navigate to Accounts
3. Click Switch to Expensify Classic in General section

Expected Result:

User navigated to Classic

Actual Result:

Error message "Hmm... it's not here Oops, this page cannot be found"

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The video for the issue is in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @FitseTLT

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022049147869820079057
• Upwork Job ID: 2049147869820079057
• Last Price Increase: 2026-04-28

[exfy-zapier]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[melvin-bot]

📣 @exfy-zapier! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[MelvinBot]

Proposal

What is the root cause of that problem?

This is a duplicate of #88986, which has already been fixed and deployed to production (v9.3.63-0).

On wide screens, the default central pane in Settings is Settings_Profile (SettingsSplitNavigator.tsx:40). When "Switch to Expensify Classic" is clicked from InitialSettingsPage.tsx:341, createDynamicRoute builds the path relative to the active route (e.g. settings/profile/exit-survey/reason). The entryScreens for EXIT_SURVEY_REASON in ROUTES.ts previously only allowed Settings_Troubleshoot, so Settings_Profile was rejected — causing a fallthrough to a 404.

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

No changes needed — this is already fixed. PR #88990 changed entryScreens to ['*'] for both EXIT_SURVEY_REASON and EXIT_SURVEY_CONFIRM, and was deployed on 2026-04-28.

This issue should be closed as a duplicate of #88986.

Related issues

• [Due for payment 2026-05-05] [$250] "Switch to Expensify Classic" button on Settings page leads to 404 due to missing entryScreen #88986 — same root cause, already fixed and deployed
• [$250] No reason and confirm pages open when user switch to Expensify Classic #88476 — similar dynamic route issue with exit surveys on HybridApp

[melvin-bot]

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

[melvin-bot]

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

[aswin-s]

Proposal

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

On web, clicking Account > Switch to Expensify Classic can navigate to a 404 page instead of opening the exit survey / Classic redirect flow, so migrated users cannot switch to Expensify Classic from Settings.

What is the root cause of that problem?

The bug was introduced when the exit-survey flow was migrated from fixed settings routes to dynamic routes:

• src/pages/settings/InitialSettingsPage.tsx and src/pages/settings/Troubleshoot/TroubleshootPage.tsx now call createDynamicRoute(DYNAMIC_ROUTES.EXIT_SURVEY_REASON.path) / createDynamicRoute(DYNAMIC_ROUTES.EXIT_SURVEY_CONFIRM.path).
• createDynamicRoute() uses Navigation.getActiveRoute(), so it appends the exit-survey suffix to whichever Settings screen is currently focused.
• In src/libs/Navigation/AppNavigator/Navigators/SettingsSplitNavigator.tsx, the switch-to-classic action lives in the persistent sidebar screen SCREENS.SETTINGS.ROOT, while the focused central pane on wide layouts is SCREENS.SETTINGS.PROFILE.ROOT by default, and can also be ABOUT, HELP, SECURITY, WALLET, etc.
• That means the same sidebar action can legitimately generate routes like:
  • settings/profile/exit-survey/reason
  • settings/about/exit-survey/reason
  • settings/security/exit-survey/confirm

In src/libs/Navigation/helpers/getStateFromPath.ts, dynamic routes are only accepted if the focused underlying screen is listed in DYNAMIC_ROUTES.<route>.entryScreens.

The root cause is that src/ROUTES.ts treated EXIT_SURVEY_REASON and EXIT_SURVEY_CONFIRM as if they had a small fixed set of valid entry screens, even though the action is launched from a persistent settings sidebar and therefore inherits whichever settings central pane is active underneath it. As a result, valid settings URLs were rejected by getStateFromPath() and fell through to Not Found.

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

1. In src/ROUTES.ts, set both DYNAMIC_ROUTES.EXIT_SURVEY_REASON.entryScreens and DYNAMIC_ROUTES.EXIT_SURVEY_CONFIRM.entryScreens to ['*'].

This is the correct fix because the exit-survey dynamic routes are intentionally reusable from any Settings central pane that sits under the persistent Settings sidebar. A partial allow-list is fragile and will keep breaking as soon as the user opens the same sidebar action from another Settings pane.

2. Add regression coverage for this navigation pattern.

A good test would verify that a path such as settings/profile/exit-survey/reason is accepted by getStateFromPath() and does not resolve to SCREENS.NOT_FOUND. That protects the actual failure mode that caused this bug.

What alternative solutions did you explore? (Optional)

An alternative is to enumerate every valid Settings central pane explicitly, such as SCREENS.SETTINGS.PROFILE.ROOT, SCREENS.SETTINGS.ABOUT, SCREENS.SETTINGS.HELP, SCREENS.SETTINGS.SECURITY, SCREENS.SETTINGS.WALLET.ROOT, SCREENS.SETTINGS.RULES.ROOT, SCREENS.SETTINGS.PREFERENCES.ROOT, SCREENS.SETTINGS.SUBSCRIPTION.ROOT, and SCREENS.SETTINGS.TROUBLESHOOT.

I would not use that approach. The navigation model already supports wildcard access for dynamic routes that can be opened from multiple underlying screens, and DYNAMIC_ROUTES.KEYBOARD_SHORTCUTS is an existing working analog that uses entryScreens: ['*'] for the same reason. The wildcard fix is more precise to the actual behavior and avoids another partial allow-list regression later.

[twilight2294]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.