[Due for payment 2026-06-03] [$250] More Features - Upgrade modal doesn't show up when try to enable restricted feature

[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: v9.3.79-1
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: #87833
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Android 13 / Xiaomi Poco F5, iOS 15.8.3 / iPhone 7 Plus
App Component: Workspace Settings

Action Performed:

Precondition (OD):

• Login using Expensifail account
• Navigate to Settings > Workspace > Group > select Submit workspace

Steps in ND:

1. Open the hybrid app
2. Login using same account as precondition
3. Go to More Feature
4. Try to enable one of these features: Accounting, Company Cards, Expensify Card, Travel, and Invoicing

Expected Result:

There's an upgrade modal show up when try to enable Accounting, Company Cards, Expensify Card, Travel, and Invoicing features.

Actual Result:

Upgrade modal doesn't show up when try to enable restricted feature.
Note:

• Not reproduced in Web

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7160409_1779437606313.iOS_Upgrade_modal.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @hungvu193

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022058805663675626866
• Upwork Job ID: 2058805663675626866
• Last Price Increase: 2026-05-25

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

[melvin-bot]

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

[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

What is the root cause of that problem?

The upgrade modal for restricted features on Submit workspaces is gated by tryNavigateToSubmitWorkspaceUpgrade, which calls canAccessSubmitWorkspaceFeatures. This function requires both isSubmitPolicy(policy) AND isSubmit2026BetaEnabled to return true.

When isSubmit2026BetaEnabled is false, tryNavigateToSubmitWorkspaceUpgrade returns false, and the toggle handler falls through to directly enable the feature — no upgrade modal is shown.

In hybrid app mode, the SUBMIT_2026 beta is likely unavailable when the user reaches the More Features page. The betas are not part of HybridAppSettings passed from OldDot during the transition — they must come from the OpenApp/ReconnectApp API response. Additionally, ONYXKEYS.BETAS is not in KEYS_TO_PRESERVE, so betas can be wiped during Onyx clear operations that occur during the hybrid app transition. The policy data, however, persists separately — creating a window where the policy is loaded (type submit2026) but betas are empty/stale, causing the gate to silently skip the upgrade modal.

There is no platform-specific code — WorkspaceMoreFeaturesPage has no .native.tsx variant, no HybridApp checks, and the Switch component is identical across platforms. The issue is purely a data availability problem in hybrid app mode.

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

The tryNavigateToSubmitWorkspaceUpgrade function should not silently fall through when the beta check fails on a Submit workspace. When the policy is a Submit workspace (isSubmitPolicy is true) but the beta is not yet available, the function should still show the upgrade modal rather than allowing the feature to be enabled directly.

Concretely, in tryNavigateToSubmitWorkspaceUpgrade, the condition should be changed so that the upgrade navigation fires when isSubmitPolicy(policy) is true, regardless of isSubmit2026BetaEnabled. The beta check gates access to the Submit workspace features, but the upgrade modal should be shown whenever a user on a Submit workspace tries to enable a restricted feature — the beta being disabled shouldn't bypass the paywall, it should reinforce it.

Similarly, useRedirectSubmitWorkspaceFeatureUpgrade should redirect based on isSubmitPolicy(policy) alone.

What alternative solutions did you explore? (Optional)

1. Adding ONYXKEYS.BETAS to KEYS_TO_PRESERVE — this would prevent betas from being cleared during hybrid app transitions, but doesn't address the root design issue where a missing beta bypasses the paywall instead of enforcing it.
2. Ensuring OpenApp completes before allowing navigation to workspace pages in hybrid mode — this would fix timing but adds complexity and potentially degrades perceived performance of the hybrid app transition.

---

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.

[hungvu193]

This will require your account to have isSubmit2026BetaEnabled. As I commented here