[$250] Onboarding - The app redirects to the Home page briefly, then Concierge chat appears

[lanitochka17]

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.3.79-2
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/folder/13176677/test-cases/41237663
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 15 iOS 26.4.2 Safari
App Component: Other

Action Performed:

1. Sign up to ND, select the purpose "Organize my personal spending"
2. Enter the name and tap Continue
3. Verify that the app redirects to the Home page

Expected Result:

The app redirects to the Home page after selecting "Organize my personal spending" and completing the onboarding

Actual Result:

The app redirects to the Home page briefly, then Concierge chat appears after selecting "Organize my personal spending" and completing the onboarding

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7160891_1779474908965.Concierge_instead_of_Home.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

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

Issue Owner

Current Issue Owner: @amyevans

[MelvinBot]

Proposal

What is the root cause of that problem?

When a user selects "Organize my personal spending" (PERSONAL_SPEND), the app classifies it as a "track" onboarding choice via isTrackOnboardingChoice(). This triggers useAutoCreateTrackWorkspace, which sets the RHP variant to TRACK_EXPENSES_WITH_CONCIERGE.

After onboarding completes, navigateAfterOnboardingWithMicrotaskQueue first calls Navigation.dismissModal() (line 115) — which reveals the Home page underneath the onboarding modal — and then schedules the actual navigation via a microtask. On small screens (iOS Safari/App), the check at navigateAfterOnboarding.ts:78-81 explicitly navigates to the Concierge report:

if (isSmallScreenWidth && variant === CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE) {
    Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(conciergeReportID));
    return;
}

The gap between dismissModal() (revealing Home) and the microtask navigation (redirecting to Concierge) causes the brief Home page flash. On large screens, the same variant navigates to Home and opens the side panel with Concierge — there's no redirect away from Home.

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

The small-screen behavior at navigateAfterOnboarding.ts:78-81 should be updated so that PERSONAL_SPEND users on small screens are not redirected to Concierge. Instead, they should land on the Home page (or the last accessed report via the existing getReportIDAfterOnboarding logic), consistent with the expected behavior described in the issue. The TRACK_EXPENSES_WITH_CONCIERGE redirect to Concierge on small screens may still be appropriate for TRACK_BUSINESS users, so the fix should scope the change to only skip the Concierge redirect for PERSONAL_SPEND (and possibly TRACK_PERSONAL) onboarding choices. This could be done by passing the onboardingPurposeSelected through to navigateAfterOnboarding and conditioning the small-screen Concierge redirect on the purpose.

What alternative solutions did you explore? (Optional)

An alternative would be to remove the microtask scheduling and combine dismissModal with the navigation into a single operation to eliminate the Home flash entirely. However, the microtask approach exists for a reason (allowing the navigation state to settle after modal dismissal), and the core issue is the unwanted Concierge redirect — not just the flash.

Possibly related issues

• Expensify/App#91437 — "Not here" page appears briefly after completing onboarding (similar post-onboarding navigation timing issue)
• Expensify/App#85242 — Home page appears instead of the expected room after signing in with a new account

---

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.

[KJ21-ENG]

Proposal

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

After a new user chooses "Organize my personal spending" and finishes onboarding on iOS/small-screen web, the app lands on Home only briefly and then opens the Concierge chat. The expected final destination for this personal-spending onboarding path is Home.

What is the root cause of that problem?

The personal-spending option is CONST.ONBOARDING_CHOICES.TRACK_PERSONAL, and both the purpose screen and name screen route that choice through useAutoCreateTrackWorkspace.

Inside that hook, we force the post-onboarding RHP variant to trackExpensesWithConcierge for track flows. On native this is initialized for every track choice before completeOnboarding runs, and on web we also add a fallback that forces TRACK_PERSONAL to the same variant when the backend does not return one. Then navigateAfterOnboarding treats trackExpensesWithConcierge specially on small screens and navigates directly to ROUTES.REPORT_WITH_ID.getRoute(conciergeReportID), which explains the Home flash followed by Concierge.

Relevant lines:

App/src/hooks/useAutoCreateTrackWorkspace.ts

Lines 88 to 112 in eaaffe3

	// On mobile, hardcode trackExpensesWithConcierge since the web flow already works
	// with the CompleteGuidedSetup response and side panel isn't supported on native.
	let rhpVariant: OnboardingRHPVariant | undefined = isSidePanelReportSupported ? undefined : CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE;
	try {
	const response = await completeOnboarding({
	engagementChoice,
	onboardingMessage: onboardingMessages[engagementChoice],
	firstName,
	lastName,
	adminsChatReportID: newAdminsChatReportID,
	onboardingPolicyID: newPolicyID,
	shouldWaitForRHPVariantInitialization: isSidePanelReportSupported,
	introSelected,
	isSelfTourViewed,
	betas,
	});
	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;
	}

App/src/libs/navigateAfterOnboarding.ts

Lines 73 to 80 in eaaffe3

	// On mobile (small screen), Track workspace admins with the trackExpensesWithConcierge variant
	// should navigate directly to the Concierge DM (which contains onboarding tasks).
	// This check is outside shouldOpenRHPVariant because that function returns false on native
	// (Side Panel doesn't exist on native), but we still need to navigate to Concierge on mobile.
	const variant = variantOverride ?? onboardingRHPVariant;
	if (isSmallScreenWidth && variant === CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(conciergeReportID));
	return;

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

Update useAutoCreateTrackWorkspace so TRACK_PERSONAL does not opt into CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE.

Concretely:

• On native/small-screen app, initialize rhpVariant to trackExpensesWithConcierge only for the business track path, not for TRACK_PERSONAL.
• On web, remove the TRACK_PERSONAL fallback that converts a missing backend variant into trackExpensesWithConcierge. If the selected onboarding purpose is TRACK_PERSONAL, leave the extracted variant undefined so the existing navigateAfterOnboarding fallback can navigate to Home.
• Add or extend hook coverage for useAutoCreateTrackWorkspace to assert that TRACK_PERSONAL calls navigateAfterOnboardingWithMicrotaskQueue without the Concierge variant, while the business track path still preserves the Concierge variant behavior where applicable.

Scope boundaries: I would not change navigateAfterOnboarding itself, because it is correctly honoring an explicit trackExpensesWithConcierge variant and is shared by other onboarding paths. I would also leave the backend CompleteGuidedSetup contract alone, since the frontend currently creates the incorrect destination by forcing a variant for the personal-spending choice.

What alternative solutions did you explore? (Optional)

I considered special-casing TRACK_PERSONAL inside navigateAfterOnboarding, but that would make the shared navigation helper second-guess its caller and could break valid trackExpensesWithConcierge callers. Keeping the distinction in useAutoCreateTrackWorkspace is narrower: that hook has both the selected purpose and the variant decision in one place.

[melvin-bot]

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

[melvin-bot]

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

[lxyct825-ops]

Proposal

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

[$250] Onboarding - The app redirects to the Home page briefly, then Concierge chat appears

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

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

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.

[lxyct825-ops]

Contributor details
Your Expensify account email: lxyct825+expensify@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01174eaf71ab8fc150

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

"Organize my personal spending" maps to CONST.ONBOARDING_CHOICES.TRACK_PERSONAL (newDotTrackPersonalWorkspace):

App/src/languages/en.ts

Line 3043 in e7ab359

[CONST.ONBOARDING_CHOICES.TRACK_PERSONAL]: 'Organize my personal spending',

So on Continue, BaseOnboardingPersonalDetails.handleSubmit treats it as a "track" choice (isTrackOnboardingChoice) and routes it through useAutoCreateTrackWorkspace, where TRACK_PERSONAL is given the trackExpensesWithConcierge RHP variant in two places:

• On native, the variant is hardcoded for every track choice:

App/src/hooks/useAutoCreateTrackWorkspace.ts

Lines 88 to 90 in e7ab359

	// On mobile, hardcode trackExpensesWithConcierge since the web flow already works
	// with the CompleteGuidedSetup response and side panel isn't supported on native.
	let rhpVariant: OnboardingRHPVariant | undefined = isSidePanelReportSupported ? undefined : CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE;

• On web, a fallback assigns it specifically for TRACK_PERSONAL (the backend only returns it for TRACK_WORKSPACE):

App/src/hooks/useAutoCreateTrackWorkspace.ts

Lines 104 to 112 in e7ab359

	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;
	}
	}

That variant was added by PR #88796 (commit 87130bb, titled "Navigate TRACK_PERSONAL to concierge chat in RHP on web") so TRACK_PERSONAL matches TRACK_BUSINESS by opening Concierge in the wide-screen side panel. The RHP path keeps the user on Home and merely opens the panel — handleRHPVariantNavigation does Navigation.navigate(ROUTES.HOME) + openSidePanel.

The problem is that small screens have no side panel, and navigateAfterOnboarding has an earlier branch that, for any trackExpensesWithConcierge variant on a small screen, replaces the screen with a full-screen Concierge DM:

App/src/libs/navigateAfterOnboarding.ts

Lines 73 to 81 in e7ab359

	// On mobile (small screen), Track workspace admins with the trackExpensesWithConcierge variant
	// should navigate directly to the Concierge DM (which contains onboarding tasks).
	// This check is outside shouldOpenRHPVariant because that function returns false on native
	// (Side Panel doesn't exist on native), but we still need to navigate to Concierge on mobile.
	const variant = variantOverride ?? onboardingRHPVariant;
	if (isSmallScreenWidth && variant === CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(conciergeReportID));
	return;
	}

That branch was designed for Track workspace admins (its own comment says so), but TRACK_PERSONAL now carries the same variant on small screens, so it gets caught by it. The sequence is exactly the reported symptom: navigateAfterOnboardingWithMicrotaskQueue calls dismissModal() (Home flashes), then the queued navigateAfterOnboarding hits this branch and pushes the Concierge DM. This hits both iOS App (native hardcode) and iOS mWeb Safari (web fallback fires regardless of width).

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

TRACK_PERSONAL should only receive trackExpensesWithConcierge when the side panel is actually available (wide-screen web). On small screens it should stay unset so navigateAfterOnboarding falls through to Home — without affecting Track workspace admins, who should still open Concierge on mobile.

In src/hooks/useAutoCreateTrackWorkspace.ts, exclude TRACK_PERSONAL from the native hardcode:

-            // On mobile, hardcode trackExpensesWithConcierge since the web flow already works
-            // with the CompleteGuidedSetup response and side panel isn't supported on native.
-            let rhpVariant: OnboardingRHPVariant | undefined = isSidePanelReportSupported ? undefined : CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE;
+            // TRACK_PERSONAL only surfaces Concierge in the wide-screen web side panel (RHP); on small
+            // screens it must land on Home, so it never gets the trackExpensesWithConcierge variant.
+            // Track *workspace* admins still hardcode it on native (side panel isn't supported there).
+            const isTrackPersonal = onboardingPurposeSelected === CONST.ONBOARDING_CHOICES.TRACK_PERSONAL;
+            let rhpVariant: OnboardingRHPVariant | undefined =
+                isSidePanelReportSupported || isTrackPersonal ? undefined : CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE;

And gate the web fallback to wide layout only (so it never reaches the small-screen takeover branch — shouldUseNarrowLayout is the same value passed in as isSmallScreenWidth):

-                    if (!rhpVariant && onboardingPurposeSelected === CONST.ONBOARDING_CHOICES.TRACK_PERSONAL) {
+                    if (!rhpVariant && isTrackPersonal && !shouldUseNarrowLayout) {
                         rhpVariant = CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE;
                     }

Result:

• TRACK_PERSONAL on iOS App / iOS mWeb (narrow) → variant unset → lands on Home ✅
• TRACK_PERSONAL on wide web → variant set → unchanged (Home + Concierge in side panel) ✅
• TRACK_WORKSPACE (Track business) → untouched, still navigates to Concierge on mobile ✅

What alternative solutions did you explore? (Optional)

I considered making the fix central in navigateAfterOnboarding by skipping the small-screen Concierge branch for TRACK_PERSONAL, but that helper only receives the resolved variant — TRACK_PERSONAL and TRACK_WORKSPACE share the identical trackExpensesWithConcierge value, so it can't distinguish them without threading the engagement choice through a shared helper used by several callers. Fixing it at the source (where onboardingPurposeSelected is known) is more localized and lower-risk.