[Due for payment 2026-06-16] [$250] Web - Onboarding - Concierge RHP doesn't open after land on Home page

[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.89-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-35246/41236545/1447301550?sort=%2Bidentifier
Email or phone of affected tester (no customers): leungbratt6sdasda@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10/Chrome
App Component: Left Hand Navigation (LHN)

Action Performed:

Precondition: Enter cookie setup lc-debug: 1, lc-qa:1, and refresh the page

1. Create a new user (Without +)
2. Select the purpose "Track expenses for my business."
3. Enter a valid name and click "Continue."
4. Verify that the Home page loads with the Concierge RHP open, displaying the Welcome to Expensify message and the three onboarding tasks:

Expected Result:

Step 10. Verify that the Home page loads with the Concierge RHP open, displaying the Welcome to Expensify message and the three onboarding tasks:

Actual Result:

The user only land on Home page but Concierge RHP doesn't open

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7166063_1780031404271.rhp.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022060354858337930238
• Upwork Job ID: 2060354858337930238
• Last Price Increase: 2026-05-29

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

[MelvinBot]

Proposal

What is the root cause of that problem?

On Web, the "Track expenses for my business" (TRACK_BUSINESS → newDotTrackWorkspace) path goes through useAutoCreateTrackWorkspace, which awaits CompleteGuidedSetup and extracts nvp_onboardingRHPVariant from the API response. The Concierge RHP only auto-opens when that variant is trackExpensesWithConcierge.

A frontend fallback exists for TRACK_PERSONAL only — useAutoCreateTrackWorkspace.ts:109-111. For TRACK_BUSINESS, if the backend response omits nvp_onboardingRHPVariant, rhpVariant stays undefined, shouldOpenRHPVariant returns false (RHPVariantTest/index.ts:38-54), and navigateAfterOnboarding falls through to Navigation.navigate(ROUTES.HOME) without calling SidePanelActions.openSidePanel. As a result, NVP_SIDE_PANEL.open is never set and the side panel renderer short-circuits to null (useSidePanelDisplayStatus.tsx:14-28).

The lc-debug: 1, lc-qa: 1 cookie precondition is not referenced anywhere in App/src — those cookies are interpreted server-side. Under those QA cookies, the backend (CompleteGuidedSetup in Web-Expensify) is most likely not setting nvp_onboardingRHPVariant=trackExpensesWithConcierge for TRACK_BUSINESS (e.g., A/B-test bucket exclusion for internal/QA accounts), so the frontend correctly falls through to Home without opening the panel.

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

Mirror the existing TRACK_PERSONAL fallback at useAutoCreateTrackWorkspace.ts:109-111 so that TRACK_BUSINESS also defaults rhpVariant to CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE when the backend response does not provide one. The simplest version is to drop the TRACK_PERSONAL check and apply the fallback for any isTrackOnboardingChoice(onboardingPurposeSelected), since both Track flows are expected to land on Concierge with the welcome tasks.

This makes the RHP-open behavior deterministic on web regardless of backend variant assignment. The parallel backend fix (ensuring CompleteGuidedSetup always emits the variant NVP for TRACK_BUSINESS) is in Web-Expensify and out of scope for the App repo — it should be tracked separately if backend-side ownership is preferred.

What alternative solutions did you explore? (Optional)

• Backend-only fix in Web-Expensify CompleteGuidedSetup to always emit nvp_onboardingRHPVariant for TRACK_BUSINESS. Cleaner ownership but requires internal engineer access and does not protect against future regressions in segmentation/A-B logic.
• Force openSidePanel(true) inside navigateAfterOnboarding for all isTrackOnboardingChoice purposes on web. Equivalent effect but couples the navigation helper to onboarding-purpose semantics, whereas the variant fallback keeps the contract in the dedicated hook.

Investigation details

Data flow that fails:

1. User selects "Track expenses for my business" → TRACK_BUSINESS (value newDotTrackWorkspace).
2. User enters name and clicks Continue → BaseOnboardingPersonalDetails.tsx:151-155 routes Track choices into autoCreateTrackWorkspace instead of the regular completeOnboarding path.
3. CompleteGuidedSetup runs; response is passed to extractRHPVariantFromResponse which reads nvp_onboardingRHPVariant from onyxData.
4. On web isSidePanelReportSupported=true, so the hardcoded native fallback is skipped. The remaining fallback only fires for TRACK_PERSONAL, leaving rhpVariant=undefined for TRACK_BUSINESS.
5. navigateAfterOnboarding calls shouldOpenRHPVariant(undefined) which returns false (the micro-company branch requires onboardingCompanySize, which is never set on the Track path). Code falls through to Navigation.navigate(ROUTES.HOME) — no SidePanelActions.openSidePanel is ever called.
6. useSidePanelDisplayStatus reports shouldHideSidePanel=true (NVP_SIDE_PANEL.open unset) → SidePanel renders null → user sees only Home.

Why I'm confident:

• The TRACK_PERSONAL-only fallback was added in commit 87130bb (2026-05-05), which itself acknowledges that the variant must come from the backend and adds a client-side safety net. The same safety net was simply not extended to TRACK_BUSINESS.
• The QA cookies (lc-debug, lc-qa) are not referenced anywhere in App/src (grep -rn 'lc-debug\|lc-qa' src → 0 matches), so any conditional behavior they cause is necessarily backend-side.
• Bug is reproducible in staging and production at v9.3.89-1; HEAD code is materially identical to that release for the relevant files.

Related issues from quick scan:

• [$250] Onboarding - Not here page appears briefly after completing onboarding #91437 — Onboarding "Not here" page appears briefly after completing onboarding (likely a separate navigation-timing bug).
• [$250] Onboarding - Duplicated task on Concierge when clicking "Continue" button more than 1 time #89904 — Duplicated task on Concierge when clicking Continue more than once (different code path).

---

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

[yusufdeveloper2903]

Proposal

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

On web, after a brand-new user selects "Track expenses for my business" and enters their name, the app lands on the Home page but the Concierge RHP (Welcome message + the three onboarding tasks) never opens.

What is the root cause of that problem?

The "Track" onboarding flows open the Concierge RHP by passing an rhpVariant of trackExpensesWithConcierge to navigateAfterOnboarding. On web (isSidePanelReportSupported === true), useAutoCreateTrackWorkspace initializes rhpVariant to undefined and then sets it only from the CompleteGuidedSetup API response, falling back to trackExpensesWithConcierge for TRACK_PERSONAL only:

App/src/hooks/useAutoCreateTrackWorkspace.ts

Lines 104 to 111 in afb4a2b

	if (isSidePanelReportSupported) {
	rhpVariant = extractRHPVariantFromResponse(response);
	// TRACK_PERSONAL should also navigate to concierge in RHP, same as TRACK_BUSINESS.
	// The backend only returns trackExpensesWithConcierge for TRACK_WORKSPACE (TRACK_BUSINESS),
	// so we fall back to it for TRACK_PERSONAL when the backend doesn't set it.
	if (!rhpVariant && onboardingPurposeSelected === CONST.ONBOARDING_CHOICES.TRACK_PERSONAL) {
	rhpVariant = CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE;
	}

TRACK_BUSINESS has no such fallback — it depends entirely on the backend returning nvp_onboardingRHPVariant in the response. When the response omits that key (reproducible in both staging and production), rhpVariant stays undefined.

undefined then flows into navigateAfterOnboarding. On a large screen the trackExpensesWithConcierge branch is skipped, shouldOpenRHPVariant(undefined) returns false (the Onyx nvp_onboardingRHPVariant is also empty), and because a brand-new gmail user has no onboardingAdminsChatReportID to redirect to, it falls through to Navigation.navigate(ROUTES.HOME) with the side panel never opened — exactly the reported symptom:

App/src/libs/navigateAfterOnboarding.ts

Lines 83 to 102 in afb4a2b

	if (shouldOpenRHPVariant(variantOverride)) {
	handleRHPVariantNavigation(onboardingPolicyID, variantOverride);
	return;
	}
	const reportID = getReportIDAfterOnboarding(
	isSmallScreenWidth,
	canUseDefaultRooms,
	conciergeReportID,
	archivedReportsIdSet,
	onboardingPolicyID,
	onboardingAdminsChatReportID,
	shouldPreventOpenAdminRoom,
	);
	if (reportID) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(reportID));
	} else {
	// Navigate to home to trigger guard evaluation
	Navigation.navigate(ROUTES.HOME);
	}

This is why only TRACK_BUSINESS is broken while TRACK_PERSONAL works — the latter already carries the App-side fallback.

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

Extend the existing fallback to cover every Track choice instead of just TRACK_PERSONAL, using the existing isTrackOnboardingChoice helper. This is safe because autoCreateTrackWorkspace is only ever invoked for Track choices — both callers guard with isTrackOnboardingChoice (e.g. BaseOnboardingPersonalDetails#L151-L153) — so any Track flow should land in the Concierge RHP, mirroring what native already hardcodes.

In src/hooks/useAutoCreateTrackWorkspace.ts:

-                    // TRACK_PERSONAL should also navigate to concierge in RHP, same as TRACK_BUSINESS.
-                    // The backend only returns trackExpensesWithConcierge for TRACK_WORKSPACE (TRACK_BUSINESS),
-                    // so we fall back to it for TRACK_PERSONAL when the backend doesn't set it.
-                    if (!rhpVariant && onboardingPurposeSelected === CONST.ONBOARDING_CHOICES.TRACK_PERSONAL) {
+                    // Every Track choice should land in the Concierge RHP. The backend doesn't reliably
+                    // return trackExpensesWithConcierge for all Track choices, so fall back to it whenever
+                    // the response omits a variant.
+                    if (!rhpVariant && isTrackOnboardingChoice(onboardingPurposeSelected)) {
                         rhpVariant = CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE;
                     }

Add the import:

+ import isTrackOnboardingChoice from '@libs/OnboardingUtils';

No other files change; native is unaffected (it already hardcodes the variant), and TRACK_PERSONAL keeps working.

What alternative solutions did you explore? (Optional)

• Default rhpVariant to trackExpensesWithConcierge on web too (line 90) and let the response override it. Rejected — it would override even when the backend deliberately returns a different variant, and it silently changes the documented "web relies on the response" contract; gating on isTrackOnboardingChoice is more precise.
• Fix navigateAfterOnboarding to use the Onyx-fallback variant instead of the raw variantOverride at line 83. Rejected — the backend never wrote nvp_onboardingRHPVariant for this flow, so the Onyx value is empty too; this doesn't restore the missing source of truth.
• Backend fix to always return the variant for TRACK_BUSINESS. Out of scope for the App repo, and the App already owns the equivalent fallback for TRACK_PERSONAL, so handling it App-side keeps the behavior consistent and offline-safe.

[melvin-bot]

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

[melvin-bot]

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

[ReaperOAK]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @ReaperOAK Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[KJ21-ENG]

Proposal

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

On web, after a new user chooses Track expenses for my business and finishes the name step, the app lands on Home but does not open the Concierge side panel with the "Welcome to Expensify" onboarding tasks.

What is the root cause of that problem?

The Track-business onboarding path is routed through autoCreateTrackWorkspace: the personal-details step calls it for any Track choice (BaseOnboardingPersonalDetails.tsx#L154-L157), and the purpose step does the same when details are already available (BaseOnboardingPurpose.tsx#L121-L124).

Inside that hook, web starts with no local RHP variant and waits for CompleteGuidedSetup to return nvp_onboardingRHPVariant (useAutoCreateTrackWorkspace.ts#L88-L106). If the response omits the variant, there is a fallback, but it only covers TRACK_PERSONAL (useAutoCreateTrackWorkspace.ts#L107-L112). TRACK_BUSINESS therefore can pass undefined into navigateAfterOnboardingWithMicrotaskQueue (useAutoCreateTrackWorkspace.ts#L120-L129).

That missing override matters because navigateAfterOnboarding only opens the Concierge RHP when shouldOpenRHPVariant(variantOverride) is true (navigateAfterOnboarding.ts#L77-L85). shouldOpenRHPVariant returns true for trackExpensesWithConcierge, but not for undefined (RHPVariantTest/index.ts#L38-L50). With no admin room to open for this new-user path, navigation falls through to ROUTES.HOME (navigateAfterOnboarding.ts#L88-L102), matching the video: Home loads, but the right-side Concierge panel never appears.

The QA cookies in the repro are not referenced in App source, so their effect is backend-side. App already has a defensive fallback for one Track flow; the bug is that the fallback is too narrow for the Track-business flow.

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

In src/hooks/useAutoCreateTrackWorkspace.ts, import the existing isTrackOnboardingChoice helper and use it for the fallback instead of checking only TRACK_PERSONAL:

+import isTrackOnboardingChoice from '@libs/OnboardingUtils';

-                    // TRACK_PERSONAL should also navigate to concierge in RHP, same as TRACK_BUSINESS.
-                    // The backend only returns trackExpensesWithConcierge for TRACK_WORKSPACE (TRACK_BUSINESS),
-                    // so we fall back to it for TRACK_PERSONAL when the backend doesn't set it.
-                    if (!rhpVariant && onboardingPurposeSelected === CONST.ONBOARDING_CHOICES.TRACK_PERSONAL) {
+                    // Every Track onboarding choice should land with Concierge tasks. If the backend response
+                    // omits the RHP variant, keep the web behavior deterministic for the whole Track family.
+                    if (!rhpVariant && isTrackOnboardingChoice(onboardingPurposeSelected)) {
                         rhpVariant = CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE;
                     }

That preserves backend-controlled variants when one is returned, but ensures both TRACK_BUSINESS and TRACK_PERSONAL still land on Home with Concierge RHP open when the response is missing the variant.

I would also add a focused unit test for useAutoCreateTrackWorkspace, mirroring the existing submit-workspace hook test style, with completeOnboarding returning no nvp_onboardingRHPVariant and asserting that navigateAfterOnboardingWithMicrotaskQueue(..., CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE) is called for CONST.ONBOARDING_CHOICES.TRACK_BUSINESS.

What alternative solutions did you explore? (Optional)

• Fixing only navigateAfterOnboarding to read the Onyx fallback would not solve this case when the backend never sends/writes nvp_onboardingRHPVariant.
• Defaulting rhpVariant to trackExpensesWithConcierge before the API call would work, but the narrower fallback is safer because it still lets a backend-provided variant win.
• A backend fix to always return nvp_onboardingRHPVariant for Track-business may also be useful, but App already owns a client fallback for Track-personal and should make that fallback consistent across the Track choices.