[Due for payment 2026-07-30] Home page opens after clicking Get the free plan when there is a Submit workspace

[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.34-3
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: #95099
Email or phone of affected tester (no customers): applausetester+sdoi22sndos@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.

1. Go to staging.new.expensify.com
2. Open any chat and send this link - https://staging.new.expensify.com/workspaces/submit-plan-welcome
3. Click on the link
4. Click Get the free plan.
5. Go back to the chat and click on the same link - https://staging.new.expensify.com/workspaces/submit-plan-welcome
6. Click Get the free plan.

Expected Result:

App will open Categories page of the existing Submit workspace.

Actual Result:

Home page opens after clicking Get the free plan when there is a Submit workspace.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7208399_1784055549166.12.mp4

View all open jobs on GitHub

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

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/abb30e99d98b23983b79f35d9bd5c09563ef228d2462d1fa5704c62369a3d5e6

[melvin-bot]

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

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

Issue Analysis

Root Cause: When a Submit workspace already exists and the user clicks Get the free plan again, useAutoCreateSubmitWorkspace navigates with an undefined policyID, which the navigation helper treats as "no workspace" and falls back to Home.

The chain, from the PR that introduced this (#95099):

1. useAutoCreateSubmitWorkspace.ts:59 — shouldCreateWorkspace = !isRestrictedPolicyCreation && !onboardingPolicyID && !hasEditableGroupPolicy. Because isGroupPolicy returns true for Submit policies, an already-existing Submit workspace makes hasEditableGroupPolicy true → shouldCreateWorkspace is false.
2. It therefore takes the else branch at useAutoCreateSubmitWorkspace.ts:82, setting newPolicyID = onboardingPolicyID. But onboarding is already complete and onboardingPolicyID is empty/cleared, so newPolicyID is undefined.
3. navigateToSubmitWorkspaceAfterOnboarding (navigateAfterOnboarding.ts:141-144): if (!policyID) { Navigation.navigate(ROUTES.HOME); return; } → lands on Home instead of the existing Submit workspace's Categories page.

The first click works because it actually creates the workspace and gets a real newPolicyID; the second click has nothing to create and no existing ID to fall back to.

Recommended Fix: When shouldCreateWorkspace is false because an editable group/Submit policy already exists, resolve that existing policy's ID and pass it to navigateToSubmitWorkspaceAfterOnboardingWithMicrotaskQueue instead of the empty onboardingPolicyID. Change the hasEditableGroupPolicy selector (or add a companion selector) so it returns the matching policy's id rather than just a boolean, then use that ID in the else branch at line 82 so newPolicyID is never undefined when a Submit workspace exists.

Investigation details & considerations

• The reproduction reaches this code via the direct deep link /workspaces/submit-plan-welcome, which renders SubmitPlanWelcomeModal regardless of the proactive guard's trigger conditions. handleConfirm calls autoCreateSubmitWorkspace(firstName, lastName, false) — see SubmitPlanWelcomeModal.tsx.
• Alternative explanation considered: that navigation itself is broken. Ruled out — the first click navigates correctly with a valid ID; only the "workspace already exists" path produces an undefined ID, which is the sole trigger for the Home fallback.
• Note the modal's trigger conditions only exclude paid (Team/Corporate) policies, so an existing Submit (free) workspace does not suppress the modal — meaning even the proactive path can hit this state, not just the deep link.
• This is entirely within Expensify/App, so it's fixable here.

---

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #95099 - "[Submit] In-product modal for existing "Get paid back" intent users (Wave 4)" by @abzokhattab (High confidence)
Related Issues: N/A

Recommendation: ROLL FORWARD (targeted fix)

This is a one-line navigation-logic bug in a brand-new feature fully gated behind the SUBMIT_2026 beta; a targeted fix is safer and smaller than reverting the whole modal feature (which has multiple dependent onboarding call sites). Keeping DeployBlockerCash since an App PR caused it and no backend change is required.

Assigned: @abzokhattab (PR author), @hungvu193, @iwiznia, @tgolen (approving reviewers) from the causing PR
Labels: No label change. DeployBlockerCash kept (App PR caused the bug); no DeployBlocker present.

📋 Detailed Analysis

Evidence

• PR [Submit] In-product modal for existing "Get paid back" intent users (Wave 4) #95099 introduced the SubmitPlanWelcomeModal and the useAutoCreateSubmitWorkspace hook that back the /workspaces/submit-plan-welcome route and the "Get the free plan" button in the repro.
• Confirmed the PR modifies the exact files on the failing code path: src/components/SubmitPlanWelcomeModal.tsx, src/hooks/useAutoCreateSubmitWorkspace.ts, plus the navigator/guard for the route (gh pr view 95099 --json files).
• PR merged 2026-07-14T09:56:02Z (commit 30db31f), reported same day on v9.4.34-3. The feature does not exist in production — "Reproducible in production?: N/A - new feature" — so this is staging-only, consistent with a bug in a just-merged PR on the current StagingDeployCash checklist #96044 (PR [Submit] In-product modal for existing "Get paid back" intent users (Wave 4) #95099 is line item 106).

Verification

Affected files, all touched by PR #95099:

• src/components/SubmitPlanWelcomeModal.tsx:54 — handleConfirm calls autoCreateSubmitWorkspace(firstName, lastName, false) (shouldCompleteOnboarding = false because the user already onboarded).
• src/hooks/useAutoCreateSubmitWorkspace.ts:59,82,108
• src/libs/navigateAfterOnboarding.ts:141-144
• Supporting: src/libs/PolicyUtils.ts:1361-1363 (isGroupPolicy)

Root Cause

When a Submit workspace already exists, the second "Get the free plan" tap fails to navigate to Categories:

1. useAutoCreateSubmitWorkspace.ts:59 — shouldCreateWorkspace = !isRestrictedPolicyCreation && !onboardingPolicyID && !hasEditableGroupPolicy. hasEditableGroupPolicy is computed via groupPolicySelector (line 48), which uses isGroupPolicy(policy) && canEditWorkspaceSettings(policy). isGroupPolicy returns true for Submit policies (PolicyUtils.ts:1361-1363, isPaidGroupPolicy || isSubmitPolicy). With an existing editable Submit workspace, hasEditableGroupPolicy is true → shouldCreateWorkspace = false.
2. useAutoCreateSubmitWorkspace.ts:82 — the else branch sets policyID: onboardingPolicyID. Onboarding is already complete, so onboardingPolicyID is empty/undefined → newPolicyID is undefined.
3. useAutoCreateSubmitWorkspace.ts:108 — navigateToSubmitWorkspaceAfterOnboardingWithMicrotaskQueue(undefined, ...).
4. navigateAfterOnboarding.ts:141-144 — if (!policyID) Navigation.navigate(ROUTES.HOME); return; → the user lands on the Home page instead of the existing workspace's Categories page.

The else branch assumes the "don't create" case always has a valid onboardingPolicyID, but for an already-onboarded user with an existing Submit workspace that assumption is false. The fix should resolve the existing editable Submit workspace's policyID and pass it into the navigation call (so it routes to Categories), rather than falling back to the empty onboardingPolicyID.