[Due for payment 2026-08-11] [$250] [Exploratory] Getting started - Create a workspace task is unresponsive after opening Connection task

[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-9
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: https://test-management.browserstack.com/projects/2219752/folder/13176924/test-cases/41236546
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 15 iOS 26.5.3
App Component: Workspace Settings

Action Performed:

1. Sign up to ND with a new gmail account without a +
2. Select Manage Team -> 11-50 Employees -> QBO
3. When navigated to Home, tap the "Create a workspace" task
4. Tap back button to return to Home
5. Tap "Connect to QBO" task, tap back button
6. Tap "Create a workspace" again

Expected Result:

After tapping "Create a workspace" task user is navigated to the workspace settings

Actual Result:

Nothing happens after tapping the "Create a workspace" task, if previously interacted with the "Connect to QBO" task

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7208254_1784045979336.create_workspace.1.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022078174335213088625
• Upwork Job ID: 2078174335213088625
• Last Price Increase: 2026-07-24

Issue Owner

Current Issue Owner: @mallenexpensify

[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/3fc2188b2f8257bc8dbafdd441647c2a993fd726397de5256982778cc3e6c833

[MelvinBot]

Proposal

Problem

The two "getting started" tasks — Create a workspace and Connect to QBO — are both markdown links built with the same onboardingPolicyID, so they resolve into the same WORKSPACE_SPLIT_NAVIGATOR instance:

• Create a workspace → workspaces/<policyID>/overview (SCREENS.WORKSPACE.PROFILE)
• Connect to QBO → workspaces/<policyID>/accounting (SCREENS.WORKSPACE.ACCOUNTING.ROOT)

On iOS (narrow layout), tapping the accounting task opens the accounting central-pane screen. Pressing back pops that screen but leaves the split navigator still mounted (focused on WORKSPACE.INITIAL, its state preserved). When the user then taps Create a workspace again, the navigate targets a route inside the already-mounted split navigator, and linkTo drops it as a no-op — so nothing happens.

Root Cause

The second navigation is silently deduped in linkTo/index.ts:172-175: when the resolved target route/params look already-focused (or the split navigator's preserved inner state still holds the previous central route), the action is not dispatched.

On narrow layout, openLink in Link.ts:402 skips the RHP close/swap handling entirely and calls Navigation.navigate directly, so the previously-opened workspace navigator is never popped or re-targeted. There is already a special-case for the analogous "current top is already RHP" bug at linkTo/index.ts:222-225 (issue #89006) — the workspace-split-navigator analog is not handled, which matches this symptom exactly.

Recommended Fix

Handle the case where the app navigates into a WORKSPACE_SPLIT_NAVIGATOR that is already the top full-screen route but to a different central-pane screen than the preserved one: force the central screen to switch rather than letting linkTo treat it as an already-focused no-op (mirroring the existing #89006 guard). This keeps the fix scoped to the navigation layer so it also covers any other two-task combination that shares a policyID.

Investigation details & evidence

Task link definitions

• en.ts:3322 — Create a [workspace](${workspaceSettingsLink})
• en.ts:3393 — Connect to [${integrationName}](${workspaceAccountingLink})

Links share the same policyID — ReportUtils.ts:12075 and :12082, so both resolve into one WORKSPACE_SPLIT_NAVIGATOR (WorkspaceSplitNavigator.tsx:22,27,54-56).

Tap path — the anchor always calls openLink with no per-press dedup (AnchorRenderer.tsx:53-59) → Navigation.navigate → linkTo. The drop is downstream in linkTo, aggravated by the split navigator's preserved state (usePreserveNavigatorState.ts) keeping the accounting sub-stack after back.

Data flow

1. Tap "Create a workspace" → split navigator opens with PROFILE central pane ✅ (first tap works)
2. Tap "Connect to QBO" → same navigator, ACCOUNTING.ROOT central pane shown
3. Back → accounting screen pops; split navigator stays mounted (WORKSPACE.INITIAL focused), state preserved
4. Tap "Create a workspace" again → navigate into already-mounted navigator → linkTo early-returns / StackRouter no-op → nothing happens

Confidence: Medium. Code evidence is strong and consistent, but the exact drop point (the areNamesAndParamsEqual/arePathAndBackToEqual early-return vs. a StackRouter intra-navigator no-op) depends on the runtime nav state after "back," which wasn't confirmed on-device. Capturing navigationRef.getRootState() immediately after pressing back from the accounting page would pin down the precise branch.

---

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

[melvin-bot]

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