[$250] Web - User not navigate to the Concierge chat after login new account from Concierge deep link

[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.4.27-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/63205875/folder/13176964/41237739/1539812325?sort=-identifier
Email or phone of affected tester (no customers): lekima20+62907@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Win 11/Chrome
App Component: Other

Action Performed:

1. Log out of NewDot
2. Navigate to https://staging.new.expensify.com/concierge
3. Sign-up with a new account

Expected Result:

Verify you're navigated to the concierge chat

Actual Result:

User is navigated to the homepage and the Concierge chat does not open

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7199069_1783135333405.Recording__2288.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022074045280548252083
• Upwork Job ID: 2074045280548252083
• Last Price Increase: 2026-07-06

Issue Owner

Current Issue Owner: @cristipaval

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

[MelvinBot]

Proposal

What is the root cause of that problem?

The /concierge deep-link destination is intentionally discarded for brand-new accounts, and the onboarding-completion navigation never restores it.

When a logged-out user opens /concierge, the URL is held only in memory and openReportFromDeepLink defers navigation until sign-in. After sign-up, the deferred handler runs but hits this early return because a fresh account's hasCompletedGuidedSetupFlow is false:

• src/libs/actions/Link.ts:350-354 — drops the captured deep link when initialHasCompletedGuidedSetupFlow === false, on the assumption that navigateAfterOnboarding "owns" the post-onboarding destination.

But navigateAfterOnboarding never navigates to Concierge for a normal sign-up — it only routes to an RHP variant, an onboarding-derived report, or falls back to ROUTES.HOME:

• src/libs/navigateAfterOnboarding.ts:104 — the ROUTES.HOME fallback.

So the Concierge intent is lost at Link.ts:352 and nothing restores it → the user lands on the homepage. Existing (already-onboarded) users skip that early return, their deep link is honored, and ConciergePage sends them into Concierge — which is why the bug only reproduces for new accounts.

The discard at Link.ts:350-354 was added deliberately to fix the "Not here" flash in #91437 — so this is a regression from that fix, not a random break.

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

Let a legitimate, durable deep-link destination such as /concierge survive onboarding instead of being blanket-dropped:

1. Persist the pending deep-link route (rather than only holding it in memory) so it is still available when onboarding finishes.
2. In navigateAfterOnboarding, after computing its normal destination, check for a stored pending deep-link route and navigate there instead when one exists (e.g. /concierge), clearing it afterward.
3. Keep the Link.ts:350-354 early return so the [Due for payment 2026-07-03] [$250] Onboarding - Not here page appears briefly after completing onboarding #91437 flash does not return — the deep link is now honored by navigateAfterOnboarding at the end of onboarding rather than mid-flow, so it won't flash the "Not here" page.

This keeps the #91437 fix intact while ensuring the requested destination wins for new accounts.

What alternative solutions did you explore? (Optional)

Relaxing the Link.ts:350-354 guard to allow non-HOME deep links through during onboarding was considered, but that risks reintroducing the #91437 "Not here" flash, since the route would be honored before onboarding routes settle. Threading the destination through onboarding completion is the safer path.

Investigation details & evidence chain

Reproduction path (deterministic — no logs needed):

1. Logged-out user opens /concierge; URL captured in memory only (InitialURLContextProvider.tsx:40-47). openReportFromDeepLink computes the route and waits for sign-in.
2. User signs up; NVP_ONBOARDING.hasCompletedGuidedSetupFlow is false, captured as initialHasCompletedGuidedSetupFlow (Link.ts:298-314); OnboardingGuard forces the onboarding flow.
3. The deferred deep-link handler fires after sign-in, sees initialHasCompletedGuidedSetupFlow === false, and returns without navigating (Link.ts:350-354). Concierge intent gone.
4. Onboarding finishes; completeOnboarding calls navigateAfterOnboardingWithMicrotaskQueue with only report/policy IDs — no deep-link route is threaded through (e.g. BaseOnboardingPersonalDetails.tsx).
5. navigateAfterOnboarding isn't the TRACK_EXPENSES_WITH_CONCIERGE variant, has no eligible last report, and falls to Navigation.navigate(ROUTES.HOME) → homepage.

getReportIDAfterOnboarding even explicitly excludes the Concierge chat when picking a last-accessed report (navigateAfterOnboarding.ts:52-59), so the default post-onboarding destination is never Concierge outside the one special small-screen variant.

Confidence: High — two independent code investigations converged on the same mechanism with matching file:line evidence; the path is deterministic. Logs would only confirm which onboarding branch fires in production, not the root cause.

Possibly related issues

• [Due for payment 2026-07-03] [$250] Onboarding - Not here page appears briefly after completing onboarding #91437 — the "Not here" flash fix that introduced the Link.ts discard (causal to this regression).
• [$250] After signing in with a new account, the home page appears instead of the room #85242 — "After signing in with a new account, the home page appears instead of the room" (same class: new account → home instead of intended destination).
• [$250] TabNavigator NAVIGATE action not handled during deep link login flow #91777 — "TabNavigator NAVIGATE action not handled during deep link login flow".

---

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

[kitvasyl]

Proposal

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

A logged-out web user who opens /concierge and creates an account is sent to the default post-onboarding homepage instead of the Concierge chat.

What is the root cause of that problem?

In src/libs/actions/Link.ts, openReportFromDeepLink() captures initialHasCompletedGuidedSetupFlow = false when the new account starts onboarding. Once onboarding completes, hasCompletedGuidedSetupFlowSelector(val) calls handleDeeplinkNavigation(), which disconnects the Onyx subscription and then this unconditional gate discards the pending route:

if (initialHasCompletedGuidedSetupFlow === false) {
    return;
}

Consequently, /concierge never reaches Navigation.navigate(route), which would mount ConciergePage and call navigateToConciergeChat() with the newly loaded Concierge report. The normal post-onboarding navigation therefore wins and opens Home.

This is not Concierge-specific routing failure; the gate drops every legitimate deep link opened before a first-time signup. The stale post-sign-out URL it was intended to protect against is already rejected earlier in src/DeepLinkHandler.tsx by !isCurrentlyAuthenticated && initialUrlProcessed.current.

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

Remove the initialHasCompletedGuidedSetupFlow capture and unconditional return from openReportFromDeepLink(). Keep waiting for hasCompletedGuidedSetupFlowSelector(val) before navigating. This restores the pending /concierge route after onboarding while preserving the existing stale-URL protection in DeepLinkHandler.

Add regression coverage for a logged-out initial /concierge URL followed by new-account onboarding, asserting that Navigation.navigate(ROUTES.CONCIERGE) runs once. Also retest the stale-URL scenario: refresh an inaccessible workspace route, sign out, and sign in with another account, confirming that the old route is not reopened.

What alternative solutions did you explore? (Optional)

Exempting only ROUTES.CONCIERGE from the gate would fix this reproduction, but it would leave the same regression for every other valid pre-onboarding deep link. Removing the redundant broad gate is smaller conceptually and preserves the dedicated stale-URL guard.

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 08:26:56 UTC.

Proposal

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

When you're logged out, open the /concierge deep link, and then sign up for a brand new account, you land on the Home screen after onboarding instead of the Concierge chat you originally asked for. Signing into an existing account from the same link works fine, so the break is specific to fresh sign-ups.

What is the root cause of that problem?

Two things both keyed on "this is a new account" combine here.

First, the deep link is deliberately thrown away for fresh sign-ups. When the app boots, DeepLinkHandler hands the /concierge URL to openReportFromDeepLink() in src/libs/actions/Link.ts. That function captures whether onboarding was already done (initialHasCompletedGuidedSetupFlow, set around line 312), waits for sign-in, then replays the route. But before it navigates, this guard runs (Link.ts:351):

if (initialHasCompletedGuidedSetupFlow === false) {
    return;
}

For a new account that flag is false, so the concierge navigation is dropped on the floor. That guard came in with aca74ed5021 (#91437, "Skip pre-onboarding deep link to prevent Not here flash"). Before it, a fresh-signup /concierge fell through to Navigation.navigate('/concierge') and opened the chat. The guard was added to stop the "Not here" flash for report deep links, but it's too broad and catches /concierge too, even though /concierge only ever renders a loading skeleton and never shows "Not here."

Second, nothing else picks the intent back up. The last onboarding step (BaseOnboardingPersonalDetails.tsx:113) calls navigateAfterOnboarding, and for a large screen with no admins room getReportIDAfterOnboarding returns undefined, so it runs Navigation.navigate(ROUTES.HOME) (navigateAfterOnboarding.ts:104). The original /concierge route was never stored in ONBOARDING_LAST_VISITED_PATH either (only /onboarding* paths are), so the onboarding path has no memory of it. Net result: the deep link is discarded and onboarding sends the user to Home.

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

Narrow the fresh-signup drop so it still fires for report deep links (the ones #91437 was protecting against) but lets the safe /concierge utility route through, since it can't produce the "Not here" flash:

if (initialHasCompletedGuidedSetupFlow === false && route !== ROUTES.CONCIERGE) {
    return;
}

This restores the pre-regression behavior for exactly the reported route and keeps #91437's fix intact for everything else. I'd also add a test that a /concierge deep link survives a fresh signup through onboarding and lands on Concierge, since there's no coverage for that path today.

One thing I want to flag honestly: handleDeeplinkNavigation and navigateAfterOnboarding both fire when onboarding completes, so there's an ordering race. If navigateAfterOnboarding → HOME happens to run last, it overwrites the concierge nav even with the guard relaxed. If that shows up in testing, the sturdier fix is to move the decision into navigateAfterOnboarding: when the boot URL was /concierge, navigate to the concierge report there instead of Home, so it's guaranteed to be the final navigation. I'd confirm which order actually wins before committing to that.

What alternative solutions did you explore? (Optional)

I looked at ConciergePage's isLoadingReportData guard, but that page never gains focus for a fresh signup, so it isn't the cause. I also checked the exitTo mechanism, but a direct /concierge deep link carries no exitTo, so that path never runs here.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 08:21:20 UTC.

Proposal

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

When a logged-out web user opens the /concierge deep link and then signs up with a NEW account, after onboarding completes they land on the home report list instead of the Concierge chat the deep link pointed to. Signing IN with an existing account from the same deep link correctly opens Concierge, so the regression is specific to the new-account onboarding path.

What is the root cause of that problem?

The deep link is captured by DeepLinkHandler and replayed through openReportFromDeepLink in src/libs/actions/Link.ts, which subscribes to NVP_ONBOARDING and waits for sign-in before running handleDeeplinkNavigation. On a fresh sign-up it records initialHasCompletedGuidedSetupFlow = false (the raw flag on a brand-new account), captured here:

App/src/libs/actions/Link.ts

Lines 311 to 314 in e05d40a

	// Capture once. Use the raw flag, not the selector, which returns `true` for the empty NVP a fresh sign-up briefly has.
	if (!isAuthenticated && initialHasCompletedGuidedSetupFlow === undefined && val && !isAnonymousUser()) {
	initialHasCompletedGuidedSetupFlow = val.hasCompletedGuidedSetupFlow;
	}

handleDeeplinkNavigation runs once, on the first NVP_ONBOARDING update that passes the hasCompletedGuidedSetupFlowSelector gate, and disconnects the subscription on entry. For an account that onboarded during this session, it hits an early-return that discards the captured route:

App/src/libs/actions/Link.ts

Lines 350 to 354 in e05d40a

	// Drop a deep link captured before onboarding finished: navigateAfterOnboarding owns the
	// post-onboarding destination and overrides it anyway, so honoring it only risks the flash (#91437).
	if (initialHasCompletedGuidedSetupFlow === false) {
	return;
	}

#91437 added that drop on the assumption that navigateAfterOnboarding "owns the post-onboarding destination and overrides it anyway." But navigateAfterOnboarding only ever routes to the admins chat, the last accessed report, or ROUTES.HOME. It has no knowledge of the pending /concierge deep link:

App/src/libs/navigateAfterOnboarding.ts

Lines 100 to 105 in e05d40a

	if (reportID) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(reportID));
	} else {
	// Navigate to home to trigger guard evaluation
	Navigation.navigate(ROUTES.HOME);
	}

So the two mechanisms cancel each other out: the deep-link replay drops /concierge because it trusts onboarding to handle the destination, while onboarding sends the user to HOME because it never knew a /concierge link was pending. The sign-IN path behaves differently because an existing account already has hasCompletedGuidedSetupFlow === true, so initialHasCompletedGuidedSetupFlow is captured as true, the === false guard is skipped, and handleDeeplinkNavigation navigates to route === 'concierge', mounting ConciergePage which resolves and opens the Concierge report.

I reproduced this by opening the /concierge deep link while logged out, then signing up for a brand-new account and completing onboarding end to end. Once onboarding finished, the app landed on the Home report list at /home instead of opening Concierge, with zero console errors along the way. Checking the underlying state afterward showed nvp_onboarding had already flipped to hasCompletedGuidedSetupFlow: true with a valid chatReportID pointing at a real, reachable Concierge report, so the data was written correctly and the report existed. The deep link was still dropped anyway, which shows the bug isn't a missing or broken Concierge report, it's the routing decision. That points squarely at the early-return in handleDeeplinkNavigation (src/libs/actions/Link.ts, around L350-354), which discards the captured /concierge route whenever initialHasCompletedGuidedSetupFlow was captured as false at signup (L312-314). From there navigateAfterOnboarding.ts (L91-105) has no knowledge of the pending deep link and falls back to routing the new account to ROUTES.HOME, matching exactly what I observed on screen.

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

Exempt the Concierge route from the pre-onboarding drop in handleDeeplinkNavigation. Change the guard at src/libs/actions/Link.ts line 352 to:

// navigateAfterOnboarding routes to HOME/last report and never to Concierge, so a pending
// /concierge deep link must still be resumed. It resolves via ConciergePage and can't flash NotFound.
const deepLinkPath = normalizePath(route).split(/[?#]/).at(0)?.replace(/\/+$/, '') ?? '';
if (initialHasCompletedGuidedSetupFlow === false && deepLinkPath !== `/${ROUTES.CONCIERGE}`) {
    return;
}

Both normalizePath and ROUTES are already imported in this file. Comparing the path segment alone keeps the exemption working when the link carries query params, a hash, or a trailing slash, since getRouteFromLink preserves search and hash.

Concierge is safe to exempt because ConciergePage is a resolver rather than a content page: it renders a skeleton and finds-or-creates the Concierge chat via navigateToConciergeChat in a focus effect, so it cannot produce the "Not here" flash that #91437 guards against. The resolver design also covers both possible execution times of the replayed navigation. If it executes after onboarding completes, it opens Concierge. If it executes earlier and the Concierge route mounts beneath the onboarding modal (the placement the #91437 investigation observed for pre-onboarding deep links), ConciergePage re-resolves to the Concierge chat when it regains focus after the modal is removed, instead of leaving a stale page behind. getReportIDFromLink('concierge') is empty, so navigateHandler goes straight to Navigation.navigate(route, {forceReplace, waitForTransition: true}), and waitForTransition keeps that navigate from cutting into an in-flight dismissModal or HOME transition.

Existing-account sign-in never enters the === false branch, so it is unaffected. The exemption is an exact path match, so every report, workspace, and settings deep link keeps the full #91437 protection.

What alternative solutions did you explore? (Optional)

Reverting the #91437 drop for all routes: rejected, it reintroduces the NotFound flash for stale non-report URLs. Teaching navigateAfterOnboarding to read the pending initial URL and route to it instead of HOME: rejected because that helper is shared by many onboarding exit points, and threading the deep link through all of them is more invasive than a targeted exemption at the single spot where the route is dropped.

[aswin-s]

Proposal

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

On Web, when a signed-out user visits https://staging.new.expensify.com/concierge and signs up with a new account, they land on the home page instead of the Concierge chat. Expected: after sign-up completes, navigation should open the Concierge report the deep link pointed at.

What is the root cause of that problem?

PR #92839 added an unconditional early-return in openReportFromDeepLink at src/libs/actions/Link.ts:352-354: if (initialHasCompletedGuidedSetupFlow === false) return;. The value is captured at Link.ts:312-313 while the user is still unauthenticated, so for every fresh sign-up it is false, and the deep-link navigation is dropped. The comment justifies this by claiming navigateAfterOnboarding "owns the post-onboarding destination and overrides it anyway", but navigateAfterOnboarding (src/libs/navigateAfterOnboarding.ts:64-106) chooses a destination from the onboarding RHP variant / getReportIDAfterOnboarding and never inspects the captured deep-link URL — so a /concierge deep link is silently discarded and the user is routed to home.

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

1. src/libs/actions/Link.ts:350-354 — make the drop conditional: allow the /concierge route (and ROUTES.CONCIERGE) through the early-return, since navigating to the Concierge report is safe regardless of onboarding state and matches the fresh-user default destination anyway. Concretely, skip the early-return when route === ROUTES.CONCIERGE (or the resolved reportID equals conciergeReportID).
2. Alternatively, in src/libs/navigateAfterOnboarding.ts (navigateAfterOnboarding, lines 64-106) pass the captured deep-link URL/reportID through navigateAfterOnboardingWithMicrotaskQueue and let it take precedence over getReportIDAfterOnboarding when the captured route is the Concierge chat, so the "drop-then-navigateAfterOnboarding-owns-it" contract in the PR Guard DeepLinkHandler against stale post-sign-out initial URL #92839 comment actually holds.
3. Confirm the [Due for payment 2026-07-03] [$250] Onboarding - Not here page appears briefly after completing onboarding #91437 flash regression that Guard DeepLinkHandler against stale post-sign-out initial URL #92839 was fixing does not re-appear for /concierge — since the destination navigateAfterOnboarding picks for a new user is Concierge in the majority path, honoring /concierge explicitly cannot cause a "Not here" flash.
4. Add/adjust a test covering: signed-out user → /concierge deep link → sign-up → lands on Concierge chat (not home).

What alternative solutions did you explore? (Optional)

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 08:25:24 UTC.

Proposal

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

On web, a logged-out user who opens the /concierge deep link and signs up with a new account lands on the homepage instead of the Concierge chat. Logging in with an existing account from the same link works.

What is the root cause of that problem?

The /concierge deep link is captured before sign-up, deliberately dropped by a stale-URL guard added in PR #92839, and the layer that guard delegates to (navigateAfterOnboarding) never learns the deep link existed.

1. While logged out at /concierge, DeepLinkHandler processes the initial URL and calls openReportFromDeepLink(url, ..., isAuthenticated = false, ...) —

   App/src/DeepLinkHandler.tsx

   Lines 84 to 91 in e05d40a

   	if (url) {
   	if (conciergeReportID === undefined) {
   	Log.info('[Deep link] conciergeReportID is undefined when processing initial URL', false, {url});
   	}
   	if (introSelected === undefined) {
   	Log.info('[Deep link] introSelected is undefined when processing initial URL', false, {url});
   	}
   	openReportFromDeepLink(url, allReports, isCurrentlyAuthenticated, conciergeReportID, introSelected, isSelfTourViewed, betas);

2. openReportFromDeepLink defers navigation until after sign-in via waitForUserSignIn() plus an Onyx subscription on NVP_ONBOARDING. For a fresh sign-up the first real NVP has hasCompletedGuidedSetupFlow: false, captured once into initialHasCompletedGuidedSetupFlow —

   App/src/libs/actions/Link.ts

   Lines 299 to 316 in e05d40a

   	waitForUserSignIn().then(() => {
   	// `false` when the user still had to onboard as this deep link was captured (fresh sign-up, or a
   	// stale react-native-web URL); honoring it after onboarding flashes the "Not here" page (#91437).
   	let initialHasCompletedGuidedSetupFlow: boolean | undefined;
   	// Subscribe to onboarding data using connectWithoutView to determine if user has completed the onboarding flow without affecting UI
   	const connection = Onyx.connectWithoutView({
   	key: ONYXKEYS.NVP_ONBOARDING,
   	callback: (val) => {
   	if (!val && !isAnonymousUser()) {
   	return;
   	}
   	// Capture once. Use the raw flag, not the selector, which returns `true` for the empty NVP a fresh sign-up briefly has.
   	if (!isAuthenticated && initialHasCompletedGuidedSetupFlow === undefined && val && !isAnonymousUser()) {
   	initialHasCompletedGuidedSetupFlow = val.hasCompletedGuidedSetupFlow;
   	}
   	Navigation.waitForProtectedRoutes().then(() => {

3. The deferred handleDeeplinkNavigation only runs once onboarding completes —

   App/src/libs/actions/Link.ts

   Lines 398 to 400 in e05d40a

   	if (hasCompletedGuidedSetupFlowSelector(val) || isAnonymousUser()) {
   	handleDeeplinkNavigation();
   	}

4. When it runs, this guard discards the link for every fresh sign-up: if (initialHasCompletedGuidedSetupFlow === false) { return; } —

   App/src/libs/actions/Link.ts

   Lines 349 to 354 in e05d40a

   	// Drop a deep link captured before onboarding finished: navigateAfterOnboarding owns the
   	// post-onboarding destination and overrides it anyway, so honoring it only risks the flash (#91437).
   	if (initialHasCompletedGuidedSetupFlow === false) {
   	return;
   	}

   . Added in PR #92839 (merged 2026-06-17, fixing the #91437 "Not here" flash), its comment assumes "navigateAfterOnboarding owns the post-onboarding destination and overrides it anyway".
5. That assumption is the structural bug: navigateAfterOnboarding has no knowledge of the deep link. On wide screens getReportIDAfterOnboarding returns the admins chat or undefined (

   App/src/libs/navigateAfterOnboarding.ts

   Lines 45 to 50 in e05d40a

   	if (!isSmallScreenWidth) {
   	if (onboardingAdminsChatReportID && !shouldPreventOpenAdminRoom) {
   	return onboardingAdminsChatReportID;
   	}
   	return undefined;
   	}

   ) and the undefined case falls through to Navigation.navigate(ROUTES.HOME) (

   App/src/libs/navigateAfterOnboarding.ts

   Lines 100 to 105 in e05d40a

   	if (reportID) {
   	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(reportID));
   	} else {
   	// Navigate to home to trigger guard evaluation
   	Navigation.navigate(ROUTES.HOME);
   	}

   ). On narrow screens the fallback explicitly excludes Concierge via !isConciergeChatReport(...) (

   App/src/libs/navigateAfterOnboarding.ts

   Lines 52 to 58 in e05d40a

   	const lastAccessedReport = findLastAccessedReport(!canUseDefaultRooms, shouldOpenOnAdminRoom() && !shouldPreventOpenAdminRoom, undefined, reportNameValuePairs);
   	const lastAccessedReportID = lastAccessedReport?.reportID;
   	// When the user goes through the onboarding flow, a workspace can be created if the user selects specific options. The user should be taken to the #admins room for that workspace because it is the most natural place for them to start their experience in the app.
   	// The user should never go to the self DM or the Concierge chat if a workspace was created during the onboarding flow.
   	if (lastAccessedReportID && lastAccessedReport.policyID !== onboardingPolicyID && !isConciergeChatReport(lastAccessedReport, conciergeReportID) && !isSelfDM(lastAccessedReport)) {
   	return lastAccessedReportID;

   ). No branch can land on Concierge.
6. ConciergePage (mounted from the URL) can't rescue it: its useFocusEffect bails while isLoadingReportData is true (

   App/src/pages/ConciergePage.tsx

   Lines 36 to 50 in e05d40a

   	useFocusEffect(
   	useCallback(() => {
   	if (session && 'authToken' in session) {
   	Navigation.isNavigationReady().then(() => {
   	if (isUnmounted.current || isLoadingReportData === undefined || !!isLoadingReportData) {
   	return;
   	}
   	navigateToConciergeChat(conciergeReportID, introSelected, session.accountID ?? CONST.DEFAULT_NUMBER_ID, isSelfTourViewed, betas, true, () => !isUnmounted.current);
   	});
   	} else {
   	Navigation.navigate(ROUTES.INBOX);
   	}
   	}, [session, isLoadingReportData, conciergeReportID, introSelected, isSelfTourViewed, betas]),
   	);

   ), startOnboardingFlow's resetRoot covers it with the onboarding modal before data loads (

   App/src/libs/actions/Welcome/OnboardingFlow.ts

   Lines 89 to 104 in e05d40a

   	function startOnboardingFlow(startOnboardingFlowParams: GetOnboardingInitialPathParamsType) {
   	const currentRoute = navigationRef.getCurrentRoute();
   	const adaptedState = getAdaptedStateFromPath(getOnboardingInitialPath(startOnboardingFlowParams) as Route, undefined, false);
   	const focusedRoute = findFocusedRoute(adaptedState as PartialState<NavigationState<RootNavigatorParamList>>);
   	if (focusedRoute?.name === currentRoute?.name) {
   	return;
   	}
   	const rootState = navigationRef.getRootState();
   	const rootStateRouteNamesSet = new Set(rootState.routes.map((route) => route.name));
   	navigationRef.resetRoot({
   	...rootState,
   	...adaptedState,
   	stale: true,
   	routes: [...rootState.routes, ...(adaptedState?.routes.filter((route) => !rootStateRouteNamesSet.has(route.name)) ?? [])],
   	} as PartialState<NavigationState>);
   	}

   ), and after onboarding the dismissModal + HOME navigation are batched (

   App/src/libs/navigateAfterOnboarding.ts

   Lines 118 to 130 in e05d40a

   	Navigation.dismissModal();
   	Navigation.setNavigationActionToMicrotaskQueue(() => {
   	navigateAfterOnboarding(
   	isSmallScreenWidth,
   	canUseDefaultRooms,
   	conciergeReportID,
   	reportNameValuePairs,
   	onboardingPolicyID,
   	onboardingAdminsChatReportID,
   	shouldPreventOpenAdminRoom,
   	variantOverride,
   	);
   	});

   ), so the page never refocuses.

This explains every detail: homepage = the ROUTES.HOME fallback; new-account-only = existing logins capture initialHasCompletedGuidedSetupFlow = true and pass the guard; reproducible in staging and production = PR #92839 shipped in mid-June, before v9.4.27-1.

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

Honor the concierge deep-link intent at the single post-onboarding convergence point, src/libs/navigateAfterOnboarding.ts — which already reads a URL hint via shouldOpenOnAdminRoom() (

App/src/libs/navigateAfterOnboarding.ts

Line 52 in e05d40a

const lastAccessedReport = findLastAccessedReport(!canUseDefaultRooms, shouldOpenOnAdminRoom() && !shouldPreventOpenAdminRoom, undefined, reportNameValuePairs);

). Cache the initial URL at module scope (mirroring the module-scope Onyx connect at L20-L26) and branch before getReportIDAfterOnboarding:

let initialURLPathname: string | undefined;
Linking.getInitialURL().then((url) => (initialURLPathname = url ? new URL(url).pathname : undefined));

// inside navigateAfterOnboarding(), after the variant checks:
if (initialURLPathname?.endsWith(`/${ROUTES.CONCIERGE}`) && conciergeReportID) {
    Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(conciergeReportID));
    return;
}

conciergeReportID is already a parameter (L67), so all three callers (BaseOnboardingPersonalDetails, BaseOnboardingWorkspaces, BaseOnboardingInterestedFeatures) are covered with no signature change, and the branch fixes both wide and narrow layouts. On web, react-native-web caches getInitialURL() at bundle load (DeepLinkHandler's own comment, L72-L75), so it resolves long before onboarding completes; native cold-starts resolve it the same way. Regression safety: this only adds an early return taken when the app was opened at /concierge and a concierge report exists — all other sign-ups keep the admins/last-report/HOME behavior, and the #92839 guard stays untouched so stale report deep links are still dropped.

Why the obvious spot fix fails: exempting /concierge from the drop guard at Link.ts#L352 does not work. (a) A fresh sign-up briefly has an empty NVP_ONBOARDING, for which the selector returns true (the code's own comment at L311), so handleDeeplinkNavigation can fire early, disconnect its Onyx connection, and get consumed by the isOnboardingFlowName bail-out (L337-L340) while the onboarding modal is focused — it can never re-fire. (b) Even when it does navigate, navigateAfterOnboarding issues the last navigation at onboarding completion, overwriting it. The final writer is navigateAfterOnboarding, so the fix must live there.

One flow is intentionally out of scope: sign-ups creating a Submit workspace go through navigateToSubmitWorkspaceAfterOnboarding (L138-L153) to Workspace > Categories by design; that deliberate destination keeps precedence.

What alternative solutions did you explore? (Optional)

1. Exempt /concierge in the Link.ts drop guard — incomplete: loses the early-consume race and is overridden by navigateAfterOnboarding's final navigation (proof above).
2. Detect the surviving SCREENS.CONCIERGE route in the root nav state — works today because startOnboardingFlow's resetRoot merge preserves prior routes, but couples the fix to that merge behavior; the initial-URL check has no such dependency.
3. Revert the PR #92839 guard — regresses the #91437 fix (fresh accounts sent to a stale previous-session route); its intent must be preserved.

[samranahm]

Proposal

What is the root cause of that problem?

When a user navigates to the /concierge deep link and then proceeds to sign up for a new account, the application fails to redirect them to the Concierge chat after successful login. Instead, the user is navigated to the homepage. This occurs because the deep link's target path is not correctly preserved or re-evaluated during the authentication flow for new accounts.

Specifically, the initial deep link URL is processed by the application's root component (likely App.tsx) or a navigation handler (e.g., Navigation/Navigation.ts). However, during the new account sign-up and subsequent login, the system performs a default navigation, overriding the original deep link. This suggests a gap in how the deep link is stored (e.g., in Onyx) and retrieved after Session.setAuthToken or similar authentication completion logic (likely in actions/Session.ts). The relevant code for deep link parsing, storage, and post-authentication redirection is not present in the provided codebase investigation snippets, so specific line numbers cannot be cited.

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

The solution involves capturing the deep link before authentication and using it for redirection after a successful new account sign-up.

1. Capture Deep Link on App Load:
   When the application loads and detects a deep link (e.g., /concierge), the target path should be extracted and stored in a temporary, persistent state, such as an Onyx key. This logic would typically reside in the main application entry point, like App.tsx, or a dedicated deep link handler in Navigation/Navigation.ts.

   • Note: The specific lines of code for this are not available in the provided snippets.

2. Conditional Redirect After New Account Login:
   Upon successful completion of the new account sign-up and login process, the authentication success handler (likely within actions/Session.ts or actions/SignInRedirect.ts) should check for the presence of the stored deep link. If a deep link target is found, the application should navigate to that path using Navigation.navigate() instead of performing a default redirect to the homepage.

   • Note: The specific lines of code for this are not available in the provided snippets.

3. Clear Stored Deep Link:
   After successfully navigating to the deep link target, the stored path in Onyx should be cleared to ensure it is not used for subsequent, unintended redirects.

   • Note: The specific lines of code for this are not available in the provided snippets.

This approach ensures that the user's original intent from the deep link is honored after the new account creation and login flow.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.