[$250] 93267 - Android - Onboarding - User is not directed to workspace admin report

[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.25-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #93267
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Android 16 / Samsung Galaxy A06
App Component: Workspace Settings

Action Performed:

1. Open Expensify App
2. Login with new account
3. In onboarding steps, choose "Manage my team's expenses" > "1-4 employees" > "QuickBooks Online" > Click "Continue"

Expected Result:

The workspace is created and you are redirected to workspace admin report

Actual Result:

User is not redirected to workspace admin report

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7195500_1782831348463.3e5be821-baf4-4c65-a39c-e80c34daf506.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7195500

Upwork Automation - Do Not Edit

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

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

[MelvinBot]

Proposal

What is the root cause of that problem?

On a small screen (Android), the post-onboarding redirect can never land the user on the brand-new workspace's #admins room.

After onboarding completes, navigateAfterOnboarding calls getReportIDAfterOnboarding. The two screen sizes behave very differently:

• Large screen returns onboardingAdminsChatReportID directly → works (navigateAfterOnboarding.ts:41-46).
• Small screen ignores onboardingAdminsChatReportID and instead derives the target from findLastAccessedReport, which cannot resolve to the new #admins room (navigateAfterOnboarding.ts:48-57):
  1. The filter lastAccessedReport.policyID !== onboardingPolicyID explicitly excludes the new workspace's #admins room, because that room's policyID is onboardingPolicyID.
  2. The intended fallback — navigate to ROUTES.HOME "to trigger guard evaluation" (L96-101) — passes the bare route 'home' with no ?openOnAdminRoom=true. The HOME-side guard (ReportsSplitNavigator → shouldOpenOnAdminRoom) only opens the #admins room when that URL param is present, and nothing in the in-app onboarding flow ever sets it.

So getReportIDAfterOnboarding returns undefined → the user is sent to Home / last-accessed report instead of the new #admins room.

Why this is not caused by PR #93267 (the "93267 -" title prefix)

The title prefix reflects that QA found this while testing PR #93267, not that the PR caused it:

• PR Remove Onyx.connect() for the key: ONYXKEYS.COLLECTION.REPORT in src/libs/ReportUtils.ts (part 5) #93267's changes are confined to prepareOnboardingOnyxData (optimistic onboarding task data) and do not touch the redirect path. The redirect uses the raw adminsChatReportID/policyID returned synchronously from createWorkspace (BaseOnboardingInterestedFeatures.tsx:255-266), not the useOnyx-derived report objects the PR added.
• For MANAGE_TEAM, targetChatReport falls back to a stub so completeOnboarding does not early-return or throw — navigation always runs.
• The issue reproduces in production, consistent with a pre-existing small-screen logic gap rather than a fresh regression.

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

In getReportIDAfterOnboarding (navigateAfterOnboarding.ts:29-58), make the small-screen branch return the onboarding workspace's #admins room when one was created during onboarding — i.e. return onboardingAdminsChatReportID (respecting shouldPreventOpenAdminRoom) before falling through to the findLastAccessedReport logic, mirroring what the large-screen branch already does. This is the most direct fix and keeps both screen sizes consistent.

What alternative solutions did you explore? (Optional)

• Navigate to ROUTES.HOME with ?openOnAdminRoom=true appended so the existing ReportsSplitNavigator guard fires and selects the #admins room.
• Adjust the policyID !== onboardingPolicyID filter so it stops excluding the just-created workspace's #admins room (riskier — that filter also guards against self-DM/Concierge, so it needs care).

Possibly related issues (from a quick scan — may be the same redirect area)

• [$250] Spend - User not redirected to #admin room after completing 'Take a test drive' flow #91144 — not redirected to #admin room after "Take a test drive"
• [Due for payment 2026-08-05] [$250] Web - Email - Member redirects to Home page instead of Workspace chat #94549 — member redirects to Home instead of Workspace chat
• [$250] After signing in with a new account, the home page appears instead of the room #85242 — home page appears instead of the room after signing in

These are not confirmed duplicates; they touch the same "redirect to the right report after onboarding/sign-in" area.

One caveat to verify: Android is a HybridApp build, so the OldDot↔NewDot native handoff (in the Mobile-Expensify submodule, not in this repo) could be involved in setting up the URL/route. The pure-App logic above does not set openOnAdminRoom=true, but it's worth confirming the native layer doesn't also play a role on Android specifically.

---

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

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-30 16:03:54 UTC.

Proposal

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

When someone signs up on Android and goes through the "Manage my team's expenses" flow, a workspace gets created but they're dropped on Home instead of the new workspace's #admins room. On web this works fine, so it only shows up on phones and other small screens.

What is the root cause of that problem?

The redirect is decided by getReportIDAfterOnboarding in src/libs/navigateAfterOnboarding.ts, and its two branches don't behave the same way. The large-screen branch returns onboardingAdminsChatReportID directly, so web lands on the #admins room (navigateAfterOnboarding.ts:41-46). The small-screen branch ignores that report ID entirely and instead asks findLastAccessedReport, then filters the result with lastAccessedReport.policyID !== onboardingPolicyID (navigateAfterOnboarding.ts:48-55).

That filter is what kills it. The #admins room we just created belongs to the onboarding policy, so its policyID is exactly onboardingPolicyID, and the guard rejects it. The comment right above the check even says the user should be taken to the #admins room, but the code filters that room out. For a brand-new account the only other candidate is Concierge or the self-DM, both of which are also rejected. So every candidate is filtered, the function returns undefined, and navigateAfterOnboarding falls into the else and pushes ROUTES.HOME (navigateAfterOnboarding.ts:96-101).

There's a second reason the small-screen path can never recover on native. The only way findLastAccessedReport would consider an admins room is if shouldOpenOnAdminRoom() returns true, but that helper reads the openOnAdminRoom query param from getCurrentUrl(), and the native implementation of getCurrentUrl is hard-coded to return '' (src/libs/Navigation/currentUrl/index.native.ts:3). So on native it's always false and that escape hatch is dead too.

This isn't from the PR in the title (#93267). That PR's changes sit in the onboarding Onyx/task data and don't touch this redirect, which is why the bug reproduces in production. The asymmetric small-screen branch has been here since the report-selection logic was reworked (regression around 237769e02b6). The QuickBooks choice in the repro steps is incidental, the team flow always creates a workspace regardless of the accounting integration picked.

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

Make getReportIDAfterOnboarding prefer the onboarding #admins room on both screen sizes before it falls back to findLastAccessedReport. We already pass onboardingAdminsChatReportID into the function and the large-screen branch already returns it, so the fix is to hoist that check above the isSmallScreenWidth split:

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

Then keep the existing findLastAccessedReport logic only for the case where there's no onboarding admins room or opening it is intentionally prevented (shouldPreventOpenAdminRoom, used by test accounts). This is the single point every onboarding-completion page routes through, so the one change covers all the entry points rather than patching each page.

This area has a test gap, tests/unit/navigateAfterOnboardingTest.ts doesn't cover the small-screen case where an admins report is provided and the last-accessed report belongs to onboardingPolicyID. I'd add a test that asserts navigation goes to ROUTES.REPORT_WITH_ID.getRoute(onboardingAdminsChatReportID) for that case, and keep the existing coverage that avoids Concierge/self-DM and honors shouldPreventOpenAdminRoom. Affects Android, iOS, mWeb, and narrow-desktop layouts.

What alternative solutions did you explore? (Optional)

One option is to loosen the small-screen filter so the policyID !== onboardingPolicyID check still allows the onboarding policy's #admins room while excluding the self-DM and Concierge. That works but leaves the two branches doing different things for no real reason, and it still depends on findLastAccessedReport resolving the right report. Another is to set ?openOnAdminRoom=true so the existing guard fires, but getCurrentUrl returns empty on native so that path can't work there anyway. Hoisting the admins-room check matches what the large screen already intends and keeps one navigation contract for every onboarding flow.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The "Manage my team's expenses" flow creates a workspace and finishes onboarding in BaseOnboardingInterestedFeatures, which then calls navigateAfterOnboardingWithMicrotaskQueue with the freshly-created adminsChatReportID:

App/src/pages/OnboardingInterestedFeatures/BaseOnboardingInterestedFeatures.tsx

Lines 255 to 266 in 0d736c7

	navigateAfterOnboardingWithMicrotaskQueue(
	isSmallScreenWidth,
	isBetaEnabled(CONST.BETAS.DEFAULT_ROOMS),
	conciergeReportID,
	reportNameValuePairs,
	policyID,
	adminsChatReportID,
	// Onboarding tasks would show in Concierge instead of admins room for testing accounts, we should open where onboarding tasks are located
	// See https://github.com/Expensify/App/issues/57167 for more details
	(session?.email ?? '').includes('+'),
	rhpVariant,
	);

That call routes into getReportIDAfterOnboarding, which decides the destination report. The function is asymmetric by design — its own JSDoc says it "navigates to the admins chat if available" only on large screens, while small screens fall back to findLastAccessedReport:

App/src/libs/navigateAfterOnboarding.ts

Lines 24 to 58 in 0d736c7

	/**
	* Determines the report ID to navigate to after onboarding for control variant or ineligible users.
	* On large screens, navigates to the admins chat if available. On small screens, finds the last
	* accessed report while avoiding self DM, Concierge chat, and reports from the onboarding policy.
	*/
	function getReportIDAfterOnboarding(
	isSmallScreenWidth: boolean,
	canUseDefaultRooms: boolean | undefined,
	conciergeReportID: string,
	reportNameValuePairs: OnyxCollection<ReportNameValuePairs>,
	onboardingPolicyID?: string,
	onboardingAdminsChatReportID?: string,
	shouldPreventOpenAdminRoom = false,
	): string | undefined {
	// When hasCompletedGuidedSetupFlow is true, OnboardingModalNavigator in AuthScreen is removed from the navigation stack.
	// On small screens, this removal redirects navigation to HOME. Dismissing the modal doesn't work properly,
	// so we need to specifically navigate to the last accessed report.
	if (!isSmallScreenWidth) {
	if (onboardingAdminsChatReportID && !shouldPreventOpenAdminRoom) {
	return onboardingAdminsChatReportID;
	}
	return undefined;
	}
	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;
	}
	return undefined;
	}

On large screens it returns onboardingAdminsChatReportID directly (so web works):

App/src/libs/navigateAfterOnboarding.ts

Lines 41 to 46 in 0d736c7

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

On small screens (native) it instead asks findLastAccessedReport, gated by shouldOpenOnAdminRoom():

App/src/libs/navigateAfterOnboarding.ts

Lines 48 to 55 in 0d736c7

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

Two things make this never resolve to the new workspace's #admins room on native:

1. shouldOpenOnAdminRoom() reads the openOnAdminRoom query param from the current URL — but getCurrentUrl() is hard-coded to return '' on native, so it is always false. The admins-room branch inside findLastAccessedReport is therefore never taken on native.

App/src/libs/Navigation/currentUrl/index.native.ts

Lines 1 to 5 in 0d736c7

	import type GetCurrentUrl from './types';
	const getCurrentUrl: GetCurrentUrl = () => '';
	export default getCurrentUrl;

https://github.com/Expensify/App/blob/0d736c70946f87c7218f6a332f37e068fa4f7dd0/src/libs/Navigation/helpers/shouldOpenOnAdminRoom.ts#L1-L7

App/src/libs/ReportUtils.ts

Lines 2430 to 2438 in 0d736c7

	if (openOnAdminRoom) {
	const adminReport = reportsValues.find((report) => {
	const chatType = getChatType(report);
	return chatType === CONST.REPORT.CHAT_TYPE.POLICY_ADMINS;
	});
	if (adminReport) {
	return adminReport;
	}
	}

2. With openOnAdminRoom false, findLastAccessedReport returns the most-recently-visited report (Concierge / self-DM for a brand-new account), and the guard explicitly rejects any report whose policyID === onboardingPolicyID, plus Concierge and self-DM. So the new workspace's #admins room is filtered out too.

Result: getReportIDAfterOnboarding returns undefined, and navigateAfterOnboarding falls into the else branch and pushes ROUTES.HOME instead of the workspace admin report:

App/src/libs/navigateAfterOnboarding.ts

Lines 96 to 101 in 0d736c7

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

So: native onboarding → small-screen branch → shouldOpenOnAdminRoom() is always false and the policyID === onboardingPolicyID guard filters out the new #admins room → undefined → HOME → user is not taken to the workspace admin report. This is platform-specific (native only) and not introduced by the auto-linked PR #93267 (a ReportUtils Onyx-connect refactor that does not touch this navigation) — it is the pre-existing native gap surfaced during its QA, which is why it reproduces in production too. The accounting choice (QuickBooks Online) is incidental; the team flow always creates a workspace.

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

We already pass the exact destination (onboardingAdminsChatReportID) into the function, and the large-screen branch already returns it. The fix is to apply that same, already-in-scope branch on every screen size before falling back to the small-screen findLastAccessedReport heuristic — hoist it above the isSmallScreenWidth check in getReportIDAfterOnboarding:

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

This is minimal and regression-safe:

• Team flow (native): onboardingAdminsChatReportID is the just-created admins chat report ID → user is navigated straight to the workspace #admins room.
• The shouldPreventOpenAdminRoom guard (set for + test accounts whose onboarding tasks live in Concierge) is preserved, so those still skip to the findLastAccessedReport fallback.
• For the Personal/Track sibling flows, the 6th argument is mergedAccountConciergeReportID, which is undefined for normal new-account onboarding (here and here), so they keep falling through to findLastAccessedReport exactly as today; in the niche merged-account-validation case where it is set, native simply becomes consistent with the existing large-screen behavior.

Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Make findLastAccessedReport resolve the admins room on native by both forcing openOnAdminRoom true (independent of getCurrentUrl()) and relaxing the policyID !== onboardingPolicyID guard to allow the onboarding workspace's #admins room. This touches the shared findLastAccessedReport/guard logic used by many other call sites and carries real regression risk, whereas the main solution reuses the destination we already computed and pass in, with a far smaller blast radius.

[abbasifaizan70]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-30 16:20:55 UTC.

Proposal

What is the root cause of that problem?

The manage-team onboarding flow stores the selected QuickBooks integration, then the interested-features step creates or reuses the workspace and has the new policy ID plus adminsChatReportID available for post-onboarding navigation.

App/src/pages/OnboardingAccounting/BaseOnboardingAccounting.tsx

Lines 176 to 185 in cd30fa1

	const handleContinue = () => {
	if (userReportedIntegration === undefined) {
	setError(translate('onboarding.errorSelection'));
	return;
	}
	setOnboardingUserReportedIntegration(userReportedIntegration);
	// Navigate to the next onboarding step interested features with the selected integration
	Navigation.navigate(ROUTES.ONBOARDING_INTERESTED_FEATURES.getRoute());

App/src/pages/OnboardingInterestedFeatures/BaseOnboardingInterestedFeatures.tsx

Lines 188 to 242 in cd30fa1

	const shouldCreateWorkspace = !onboardingPolicyID && !paidGroupPolicy;
	const newUserReportedIntegration = selectedFeatures.some((feature) => feature === CONST.POLICY.MORE_FEATURES.ARE_CONNECTIONS_ENABLED) ? userReportedIntegration : undefined;
	const featuresMap = features.map((feature) => ({
	...feature,
	enabled: selectedFeatures.includes(feature.id),
	}));
	const email = currentUserPersonalDetails.email ?? '';
	// We need `adminsChatReportID` for `completeOnboarding`, but at the same time, we don't want to call `createWorkspace` more than once.
	// If we have already created a workspace, we want to reuse the `onboardingAdminsChatReportID` and `onboardingPolicyID`.
	const {adminsChatReportID, policyID} = shouldCreateWorkspace
	? createWorkspace({
	policyOwnerEmail: undefined,
	makeMeAdmin: true,
	policyName: generateDefaultWorkspaceName(email, lastWorkspaceNumber, translate),
	policyID: generatePolicyID(),
	engagementChoice: CONST.ONBOARDING_CHOICES.MANAGE_TEAM,
	currency: currentUserPersonalDetails?.localCurrencyCode ?? '',
	file: undefined,
	shouldAddOnboardingTasks: false,
	companySize: onboardingCompanySize,
	userReportedIntegration: newUserReportedIntegration,
	featuresMap,
	introSelected,
	activePolicy,
	currentUserAccountIDParam: currentUserPersonalDetails.accountID,
	currentUserEmailParam: email,
	shouldAddGuideWelcomeMessage: false,
	betas,
	isSelfTourViewed,
	hasActiveAdminPolicies,
	})
	: {adminsChatReportID: onboardingAdminsChatReportID, policyID: onboardingPolicyID};
	if (shouldCreateWorkspace) {
	setOnboardingAdminsChatReportID(adminsChatReportID);
	setOnboardingPolicyID(policyID);
	}
	const response = await completeOnboarding({
	engagementChoice: onboardingPurposeSelected,
	onboardingMessage: onboardingMessages[onboardingPurposeSelected],
	adminsChatReportID,
	onboardingPolicyID: policyID,
	companySize: onboardingCompanySize,
	userReportedIntegration: newUserReportedIntegration,
	firstName: currentUserPersonalDetails?.firstName,
	lastName: currentUserPersonalDetails?.lastName,
	selectedInterestedFeatures: featuresMap.filter((feature) => feature.enabled).map((feature) => feature.id),
	shouldWaitForRHPVariantInitialization: isSidePanelReportSupported,
	introSelected,
	isSelfTourViewed,
	conciergeChat,
	adminsChatReport,
	});

After completing onboarding, this flow passes (session?.email ?? '').includes('+') as shouldPreventOpenAdminRoom. The reported Android QA account is a plus-address account, so the code explicitly suppresses opening the workspace #admins report even though this flow just created it and passes its report ID.

App/src/pages/OnboardingInterestedFeatures/BaseOnboardingInterestedFeatures.tsx

Lines 254 to 265 in cd30fa1

	// We need to wait the policy is created before navigating out the onboarding flow
	navigateAfterOnboardingWithMicrotaskQueue(
	isSmallScreenWidth,
	isBetaEnabled(CONST.BETAS.DEFAULT_ROOMS),
	conciergeReportID,
	reportNameValuePairs,
	policyID,
	adminsChatReportID,
	// Onboarding tasks would show in Concierge instead of admins room for testing accounts, we should open where onboarding tasks are located
	// See https://github.com/Expensify/App/issues/57167 for more details
	(session?.email ?? '').includes('+'),
	rhpVariant,

On Android/small layouts, getReportIDAfterOnboarding also does not directly return onboardingAdminsChatReportID; it only does that on wide layouts. The small-layout fallback asks for the last accessed report, rejects reports from the onboarding policy, and returns undefined, so navigateAfterOnboarding falls back to Home instead of opening the new workspace admin report.

App/src/libs/navigateAfterOnboarding.ts

Lines 29 to 57 in cd30fa1

	function getReportIDAfterOnboarding(
	isSmallScreenWidth: boolean,
	canUseDefaultRooms: boolean | undefined,
	conciergeReportID: string,
	reportNameValuePairs: OnyxCollection<ReportNameValuePairs>,
	onboardingPolicyID?: string,
	onboardingAdminsChatReportID?: string,
	shouldPreventOpenAdminRoom = false,
	): string | undefined {
	// When hasCompletedGuidedSetupFlow is true, OnboardingModalNavigator in AuthScreen is removed from the navigation stack.
	// On small screens, this removal redirects navigation to HOME. Dismissing the modal doesn't work properly,
	// so we need to specifically navigate to the last accessed report.
	if (!isSmallScreenWidth) {
	if (onboardingAdminsChatReportID && !shouldPreventOpenAdminRoom) {
	return onboardingAdminsChatReportID;
	}
	return undefined;
	}
	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;
	}
	return undefined;

App/src/libs/navigateAfterOnboarding.ts

Lines 87 to 100 in cd30fa1

	const reportID = getReportIDAfterOnboarding(
	isSmallScreenWidth,
	canUseDefaultRooms,
	conciergeReportID,
	reportNameValuePairs,
	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);

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

Update the manage-team interested-features navigation so it no longer uses the presence of + in the email address as the reason to prevent opening the workspace admin report. That path should pass false, or derive the prevention from an explicit Concierge target such as the trackExpensesWithConcierge variant, because the manage-team QuickBooks flow already has an adminsChatReportID and should land there.

App/src/pages/OnboardingInterestedFeatures/BaseOnboardingInterestedFeatures.tsx

Lines 254 to 265 in cd30fa1

	// We need to wait the policy is created before navigating out the onboarding flow
	navigateAfterOnboardingWithMicrotaskQueue(
	isSmallScreenWidth,
	isBetaEnabled(CONST.BETAS.DEFAULT_ROOMS),
	conciergeReportID,
	reportNameValuePairs,
	policyID,
	adminsChatReportID,
	// Onboarding tasks would show in Concierge instead of admins room for testing accounts, we should open where onboarding tasks are located
	// See https://github.com/Expensify/App/issues/57167 for more details
	(session?.email ?? '').includes('+'),
	rhpVariant,

Also update getReportIDAfterOnboarding so small layouts prefer onboardingAdminsChatReportID when it is present and opening the admin room is not explicitly prevented. Keep the existing last-accessed-report fallback for cases without an onboarding admin room, and keep the existing Concierge variant handling before this helper.

App/src/libs/navigateAfterOnboarding.ts

Lines 29 to 57 in cd30fa1

	function getReportIDAfterOnboarding(
	isSmallScreenWidth: boolean,
	canUseDefaultRooms: boolean | undefined,
	conciergeReportID: string,
	reportNameValuePairs: OnyxCollection<ReportNameValuePairs>,
	onboardingPolicyID?: string,
	onboardingAdminsChatReportID?: string,
	shouldPreventOpenAdminRoom = false,
	): string | undefined {
	// When hasCompletedGuidedSetupFlow is true, OnboardingModalNavigator in AuthScreen is removed from the navigation stack.
	// On small screens, this removal redirects navigation to HOME. Dismissing the modal doesn't work properly,
	// so we need to specifically navigate to the last accessed report.
	if (!isSmallScreenWidth) {
	if (onboardingAdminsChatReportID && !shouldPreventOpenAdminRoom) {
	return onboardingAdminsChatReportID;
	}
	return undefined;
	}
	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;
	}
	return undefined;

Test coverage:

• Add a unit test for small-screen manage-team onboarding where onboardingAdminsChatReportID is present and the last accessed report belongs to onboardingPolicyID; assert navigation goes to ROUTES.REPORT_WITH_ID.getRoute(onboardingAdminsChatReportID).
• Update the plus-address test-account coverage so the manage-team path no longer suppresses the admin report just because the email contains +.
• Keep coverage for the explicit Concierge/track variant and for avoiding Concierge/self-DM fallback reports.
• Manually verify on Android that choosing Manage my team's expenses > 1-4 employees > QuickBooks Online lands in the new workspace #admins report.

What alternative solutions did you explore? (Optional)

Only changing the small-screen helper would fix non-test accounts, but the reported plus-address account would still pass shouldPreventOpenAdminRoom=true. Only removing the plus-address guard would still leave the Android helper dependent on a last-accessed-report fallback that can return Home. Updating both keeps the flow aligned with the expected workspace admin report destination.

[melvin-bot]

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

[kitvasyl]

Proposal

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

After creating a workspace through the “Manage my team's expenses” onboarding flow on Android, the user is sent home instead of to the workspace’s #admins report.

What is the root cause of that problem?

In src/pages/OnboardingAccounting/BaseOnboardingAccounting.tsx, the useEffect that derives onboarding navigation metadata returns whenever onboardingPolicyID already exists. If the policy ID arrives before paidGroupPolicy.chatReportIDAdmins, the effect never calls setOnboardingAdminsChatReportID().

Consequently, getReportIDAfterOnboarding() in src/libs/navigateAfterOnboarding.ts receives no admins report ID. On small screens it can reject the last-accessed report because it belongs to the onboarding policy, then falls back to ROUTES.HOME.

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

Update the effect in BaseOnboardingAccounting to initialize the two values independently: only set onboardingPolicyID when it is missing, and set onboardingAdminsChatReportID whenever paidGroupPolicy.chatReportIDAdmins becomes available. Do not use an existing policy ID as a reason to skip initializing the admins report ID.

This allows navigateAfterOnboarding() to navigate directly to the newly created workspace’s admins report on Android.

What alternative solutions did you explore? (Optional)

We could make navigateAfterOnboarding() rediscover the admins report from the policy, but fixing the incomplete onboarding metadata at its source is smaller and preserves the navigation helper’s existing contract.

[oqildev]

Proposal

What is the root cause of that problem?

On Android the redirect target is computed in getReportIDAfterOnboarding, and its small-screen branch can never return the workspace's #admins room.

When MANAGE_TEAM onboarding finishes, BaseOnboardingInterestedFeatures.handleContinue calls navigateAfterOnboardingWithMicrotaskQueue(isSmallScreenWidth, …, policyID, adminsChatReportID, shouldPreventOpenAdminRoom, rhpVariant). On native isSidePanelReportSupported is false so rhpVariant is undefined (

App/src/pages/OnboardingInterestedFeatures/BaseOnboardingInterestedFeatures.tsx

Lines 243 to 266 in cd30fa1

	const rhpVariant = isSidePanelReportSupported ? extractRHPVariantFromResponse(response) : undefined;
	// Avoid creating new WS because onboardingPolicyID is cleared before unmounting
	TransitionTracker.runAfterTransitions({
	callback: () => {
	setOnboardingAdminsChatReportID();
	setOnboardingPolicyID();
	},
	waitForUpcomingTransition: true,
	});
	// We need to wait the policy is created before navigating out the onboarding flow
	navigateAfterOnboardingWithMicrotaskQueue(
	isSmallScreenWidth,
	isBetaEnabled(CONST.BETAS.DEFAULT_ROOMS),
	conciergeReportID,
	reportNameValuePairs,
	policyID,
	adminsChatReportID,
	// Onboarding tasks would show in Concierge instead of admins room for testing accounts, we should open where onboarding tasks are located
	// See https://github.com/Expensify/App/issues/57167 for more details
	(session?.email ?? '').includes('+'),
	rhpVariant,
	);

).

Inside navigateAfterOnboarding, shouldOpenRHPVariant is the native no-op that always returns false (

App/src/components/SidePanel/RHPVariantTest/index.native.ts

Lines 1 to 13 in cd30fa1

	import type {HandleRHPVariantNavigation, ShouldOpenRHPVariant} from './types';
	/**
	* Side Panel is not supported on native platforms, so we always return false.
	*/
	const shouldOpenRHPVariant: ShouldOpenRHPVariant = () => false;
	/**
	* No-op on native platforms since Side Panel is not supported.
	*/
	const handleRHPVariantNavigation: HandleRHPVariantNavigation = () => {};
	export {shouldOpenRHPVariant, handleRHPVariantNavigation};

), so the RHP-variant path is skipped and we fall to getReportIDAfterOnboarding.

There the two screen sizes diverge. On a wide screen it returns onboardingAdminsChatReportID directly, so desktop web lands on the admin report. On a narrow screen (Android) it ignores onboardingAdminsChatReportID entirely and instead derives a report through findLastAccessedReport, then filters that result out whenever it belongs to the onboarding policy:

App/src/libs/navigateAfterOnboarding.ts

Lines 41 to 57 in cd30fa1

	if (!isSmallScreenWidth) {
	if (onboardingAdminsChatReportID && !shouldPreventOpenAdminRoom) {
	return onboardingAdminsChatReportID;
	}
	return undefined;
	}
	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;
	}
	return undefined;

For a brand-new workspace, every recently-touched report (the #admins room, the expense chat) belongs to onboardingPolicyID, so lastAccessedReport.policyID !== onboardingPolicyID is false and the function returns undefined. navigateAfterOnboarding then falls back to Navigation.navigate(ROUTES.HOME) (

App/src/libs/navigateAfterOnboarding.ts

Lines 96 to 101 in cd30fa1

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

). Nothing afterwards re-opens the admin room on native, so the user is left on the LHN/Home instead of the workspace admin report. The bug is Android-only purely because Android is a small-screen layout while the QA web platforms hit the wide-screen onboardingAdminsChatReportID branch.

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

Fix the data/navigation layer in getReportIDAfterOnboarding. The small-screen branch should honor the onboardingAdminsChatReportID it is already handed, the same way the wide-screen branch does, before falling back to findLastAccessedReport.

Concretely, at the top of the small-screen path in getReportIDAfterOnboarding (

App/src/libs/navigateAfterOnboarding.ts

Lines 48 to 57 in cd30fa1

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

): if onboardingAdminsChatReportID is present and !shouldPreventOpenAdminRoom, return it directly. Only when there is no admins chat (e.g. join-existing flows that pass it as undefined) should we drop into the existing findLastAccessedReport logic. That keeps the +-test-account behavior (shouldPreventOpenAdminRoom) intact and keeps the HOME-guard fallback for flows that genuinely have no workspace.

This touches the "workspace created during onboarding" case only; the empty/undefined admins-chat path and the offline path are unchanged.

What alternative solutions did you explore? (Optional)

• Navigate to the admin room inside BaseOnboardingInterestedFeatures.handleContinue directly instead of going through getReportIDAfterOnboarding. Rejected because the same wide-vs-narrow asymmetry exists for the other callers of navigateAfterOnboardingWithMicrotaskQueue (BaseOnboardingPersonalDetails, BaseOnboardingPurpose), so the fix belongs in the shared helper, not one screen.

• Relying on the Navigation.navigate(ROUTES.HOME) "trigger guard evaluation" fallback to open the admin room. Rejected: on native the RHP-variant handler is a no-op and onboardingPolicyID/onboardingAdminsChatReportID are cleared right after navigation (setOnboardingPolicyID()), so there is no surviving signal for a Home-side guard to reopen the correct admins room.