[Due for payment 2026-05-11] [$250] Onboard - Onboarding tasks appear on #admins room of the new workspace

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.3.62-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-22027/folder/13176677/41237675/1363741783
Email or phone of affected tester (no customers): useronboarding@onboarding61404.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Win 11/Chrome
App Component: Other

Action Performed:

1. Open https://staging.new.expensify.com
2. Create a new account with the following format - useronboarding@onboarding[unique numer].com (E.g useronboarding@onboarding0225.com)
3. Sign up and choose "Track and Budget"
4. Create a new workspace
5. Navigate to the #admins room of the new workspace

Expected Result:

Verify you do not see onboarding tasks

Actual Result:

Onboarding tasks display on the #admins room of the new workspace

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022047734088902844373
• Upwork Job ID: 2047734088902844373
• Last Price Increase: 2026-04-24
• Automatic offers:
• wildan-m | Contributor | 111251708

[MelvinBot]

Proposal

What is the root cause of that problem?

The frontend optimistic data in prepareOnboardingOnyxData correctly targets the Concierge chat for TRACK_WORKSPACE users (since isPostingTasksInAdminsRoom only returns true for MANAGE_TEAM). However, two things cause the admins room to show onboarding content:

1. Backend chatReportID override: The CompleteGuidedSetup API receives a policyID parameter (ReportUtils.ts:5203). The backend likely sets chatReportID in the NVP_ONBOARDING response to the admins room for any request with a policyID, regardless of engagementChoice. When the backend response arrives, isChatUsedForOnboarding checks onboardingValue.chatReportID first — if the backend set it to the admins room, onboarding UI (FreeTrial badge, tasks) will appear there.

2. Desktop navigation: navigateAfterOnboarding on desktop always navigates to the admins room when onboardingAdminsChatReportID is set, regardless of engagement choice. This means the user lands directly on the admins room after onboarding.

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

This likely requires both a backend and frontend fix:

Backend (primary fix): The CompleteGuidedSetup command should only set chatReportID to the admins room when engagementChoice is newDotManageTeam. For newDotTrackWorkspace, it should set chatReportID to the Concierge chat reportID.

Frontend (navigation fix): In navigateAfterOnboarding.ts:39-43, the desktop branch unconditionally navigates to the admins room. This should also respect the engagement choice — for TRACK_WORKSPACE, it should navigate to the Concierge chat instead.

What alternative solutions did you explore? (Optional)

An alternative frontend-only approach would be to modify isChatUsedForOnboarding to ignore chatReportID from the backend and instead always use the isPostingTasksInAdminsRoom logic. However, this would be a workaround — the backend should be setting the correct chatReportID to begin with.

Investigation details

Key code paths traced:

• User selects "Track and Budget" → PERSONAL_SPEND is stored in ONBOARDING_PURPOSE_SELECTED
• Workspace is created → TRACK_WORKSPACE becomes the engagementChoice passed to completeOnboarding
• isPostingTasksInAdminsRoom('newDotTrackWorkspace') → false → tasks target Concierge chat optimistically
• But CompleteGuidedSetup receives policyID at Report/index.ts:5203
• Backend response sets chatReportID in NVP_ONBOARDING → isChatUsedForOnboarding uses this as the source of truth
• Desktop navigation always goes to admins room when onboardingAdminsChatReportID is available

Possibly related issues:

• Expensify/App#87046 — Admins room doesn't appear in LHN after creating account selecting Track option (related onboarding+admins room interaction)

---

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.

[MobileMage]

Proposal

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

When a user completes onboarding with the "Track and Budget" intent (TRACK_WORKSPACE) and then creates a new workspace, onboarding tasks appear in that workspace's #admins room instead of not appearing there at all.

What is the root cause of that problem?

In savePolicyDraftByNewWorkspace inside src/libs/actions/App.ts, the engagementChoice passed to createWorkspace is hardcoded to MANAGE_TEAM for everyone except users whose introSelected.choice is PERSONAL_SPEND:

App/src/libs/actions/App.ts

Line 726 in 4cfb6a6

engagementChoice: introSelected?.choice === CONST.ONBOARDING_CHOICES.PERSONAL_SPEND ? CONST.ONBOARDING_CHOICES.TRACK_WORKSPACE : CONST.ONBOARDING_CHOICES.MANAGE_TEAM,

When a TRACK_WORKSPACE user creates a post-onboarding workspace, this condition evaluates to false (since TRACK_WORKSPACE !== PERSONAL_SPEND), so engagementChoice is set to MANAGE_TEAM. Inside buildPolicyData, the shouldAddOnboardingTasks flag defaults to true, introSelected is defined, and with engagementChoice === MANAGE_TEAM, isPostingTasksInAdminsRoom returns true — causing tasks to be optimistically posted into the new workspace's #admins room.

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

The condition at line 726 needs to include TRACK_WORKSPACE as an intent that should not post tasks to the #admins room. Since both PERSONAL_SPEND and TRACK_WORKSPACE route tasks to Concierge (not the admins room), the engagement choice passed downstream should reflect that. The cleanest fix is to derive the engagement choice directly from introSelected.choice when it is one of those two, and fall back to MANAGE_TEAM otherwise:

App/src/libs/actions/App.ts

Lines 721 to 741 in 4cfb6a6

	createWorkspace({
	policyOwnerEmail,
	makeMeAdmin,
	policyName,
	policyID,
	engagementChoice: introSelected?.choice === CONST.ONBOARDING_CHOICES.PERSONAL_SPEND ? CONST.ONBOARDING_CHOICES.TRACK_WORKSPACE : CONST.ONBOARDING_CHOICES.MANAGE_TEAM,
	currency,
	file,
	lastUsedPaymentMethod,
	introSelected,
	activePolicyID,
	currentUserAccountIDParam,
	currentUserEmailParam,
	allReportsParam,
	shouldCreateControlPolicy,
	type,
	isSelfTourViewed,
	betas,
	hasActiveAdminPolicies,
	isAnnualSubscription,
	});

     createWorkspace({
         policyOwnerEmail,
         makeMeAdmin,
         policyName,
         policyID,
-        engagementChoice: introSelected?.choice === CONST.ONBOARDING_CHOICES.PERSONAL_SPEND ? CONST.ONBOARDING_CHOICES.TRACK_WORKSPACE : CONST.ONBOARDING_CHOICES.MANAGE_TEAM,
+        engagementChoice:
+            introSelected?.choice === CONST.ONBOARDING_CHOICES.PERSONAL_SPEND || introSelected?.choice === CONST.ONBOARDING_CHOICES.TRACK_WORKSPACE
+                ? CONST.ONBOARDING_CHOICES.TRACK_WORKSPACE
+                : CONST.ONBOARDING_CHOICES.MANAGE_TEAM,
         currency,
         file,

This ensures that TRACK_WORKSPACE users who create a new workspace after onboarding get an engagement choice of TRACK_WORKSPACE, which causes isPostingTasksInAdminsRoom to return false and routes any onboarding tasks to Concierge instead of the #admins room.

What alternative solutions did you explore? (Optional)

N/A

[melvin-bot]

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

[wildan-m]

Proposal

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

After a user signs up, picks "Track and budget expenses" at the onboarding purpose step, and later creates a new workspace, the full set of onboarding tasks (testDriveAdminTask, createReportTask, setupCategoriesTask) is posted to that new workspace's #admins room. The expected behavior is that the #admins room stays empty of onboarding tasks — those tasks were already delivered to Concierge when the user was guided through onboarding.

What is the root cause of that problem?

The onboarding purpose "Track and budget expenses" maps to ONBOARDING_CHOICES.PERSONAL_SPEND. For that choice, BaseOnboardingPersonalDetails calls autoCreateTrackWorkspace, which in turn calls completeOnboarding with engagementChoice: TRACK_WORKSPACE.

App/src/hooks/useAutoCreateTrackWorkspace.ts

Lines 100 to 113 in 4cfb6a6

	let rhpVariant: OnboardingRHPVariant | undefined = isSidePanelReportSupported ? undefined : CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE;
	try {
	const response = await completeOnboarding({
	engagementChoice: CONST.ONBOARDING_CHOICES.TRACK_WORKSPACE,
	onboardingMessage: onboardingMessages[CONST.ONBOARDING_CHOICES.TRACK_WORKSPACE],
	firstName,
	lastName,
	adminsChatReportID: newAdminsChatReportID,
	onboardingPolicyID: newPolicyID,
	shouldWaitForRHPVariantInitialization: isSidePanelReportSupported,
	introSelected,
	isSelfTourViewed,
	betas,
	});

Inside prepareOnboardingOnyxData, the final Onyx merge overwrites introSelected.choice with the engagementChoice that was used:

App/src/libs/ReportUtils.ts

Lines 12124 to 12134 in 4cfb6a6

	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.NVP_INTRO_SELECTED,
	value: {
	choice: engagementChoice,
	createWorkspace: createWorkspaceTaskReportID,
	addExpenseApprovals: addExpenseApprovalsTaskReportID,
	setupTags: setupTagsTaskReportID,
	setupCategoriesAndTags: setupCategoriesAndTagsTaskReportID,
	},
	},

So after the "Track and budget" onboarding finishes, introSelected.choice is TRACK_WORKSPACE, not PERSONAL_SPEND. Additionally, because the TRACK_WORKSPACE onboarding message has tasks: [testDriveAdminTask, createReportTask, setupCategoriesTask] (it has no createWorkspaceTask), introSelected.createWorkspace is left undefined.

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

Lines 311 to 321 in 4cfb6a6

	const onboardingTrackWorkspaceMessage: OnboardingMessage = {
	message: translate(resolvedLocale, 'onboarding.messages.onboardingTrackWorkspaceMessage'),
	video: {
	url: `${CONST.CLOUDFRONT_URL}/videos/guided-setup-manage-team-v2.mp4`,
	thumbnailUrl: `${CONST.CLOUDFRONT_URL}/images/guided-setup-manage-team.jpg`,
	duration: 55,
	width: 1280,
	height: 960,
	},
	tasks: [testDriveAdminTask, createReportTask, setupCategoriesTask],
	};

Later, when the user creates a new workspace through the regular UI (savePolicyDraftByNewWorkspace), the engagement-choice ternary keys off introSelected?.choice === PERSONAL_SPEND. That condition is false (the stored value is now TRACK_WORKSPACE), so MANAGE_TEAM is picked:

App/src/libs/actions/App.ts

Lines 720 to 742 in 4cfb6a6

	}: SavePolicyDraftByNewWorkspaceParams) {
	createWorkspace({
	policyOwnerEmail,
	makeMeAdmin,
	policyName,
	policyID,
	engagementChoice: introSelected?.choice === CONST.ONBOARDING_CHOICES.PERSONAL_SPEND ? CONST.ONBOARDING_CHOICES.TRACK_WORKSPACE : CONST.ONBOARDING_CHOICES.MANAGE_TEAM,
	currency,
	file,
	lastUsedPaymentMethod,
	introSelected,
	activePolicyID,
	currentUserAccountIDParam,
	currentUserEmailParam,
	allReportsParam,
	shouldCreateControlPolicy,
	type,
	isSelfTourViewed,
	betas,
	hasActiveAdminPolicies,
	isAnnualSubscription,
	});
	}

Then inside buildPolicyData, the guard for "should we add onboarding tasks to this new workspace?" uses !introSelected?.createWorkspace:

App/src/libs/actions/Policy/Policy.ts

Lines 2888 to 2926 in 4cfb6a6

	if (
	introSelected !== undefined &&
	(introSelected.choice === CONST.ONBOARDING_CHOICES.TEST_DRIVE_RECEIVER || !introSelected?.createWorkspace) &&
	engagementChoice &&
	shouldAddOnboardingTasks
	) {
	const {onboardingMessages} = getOnboardingMessages();
	const onboardingData = ReportUtils.prepareOnboardingOnyxData({
	introSelected,
	engagementChoice,
	onboardingMessage: onboardingMessages[engagementChoice],
	adminsChatReportID,
	onboardingPolicyID: policyID,
	onboardingPurposeSelected,
	companySize: companySize ?? (introSelected?.companySize as OnboardingCompanySize),
	isSelfTourViewed,
	betas,
	});
	if (!onboardingData) {
	return {successData, optimisticData, failureData, params};
	}
	const {
	guidedSetupData,
	optimisticData: taskOptimisticData,
	successData: taskSuccessData,
	failureData: taskFailureData,
	bespokeWelcomeMessage,
	optimisticConciergeReportActionID,
	} = onboardingData;
	params.guidedSetupData = JSON.stringify(guidedSetupData);
	params.engagementChoice = engagementChoice;
	params.bespokeWelcomeMessage = bespokeWelcomeMessage;
	params.optimisticConciergeReportActionID = optimisticConciergeReportActionID;
	optimisticData.push(...taskOptimisticData);
	successData.push(...taskSuccessData);
	failureData.push(...taskFailureData);
	}

For the Track-and-Budget user, introSelected.createWorkspace is undefined (no task ever stored), so the guard evaluates to truthy and the block runs. isPostingTasksInAdminsRoom(MANAGE_TEAM) returns true, so prepareOnboardingOnyxData posts the MANAGE_TEAM onboarding tasks into the newly created workspace's #admins room — the exact behavior the QA video shows.

The !introSelected?.createWorkspace check was intended to mean "the user has not completed onboarding yet," but only the MANAGE_TEAM flow ever stores that field. Every Concierge-based flow (PERSONAL_SPEND → TRACK_WORKSPACE, EMPLOYER, SUBMIT, CHAT_SPLIT, LOOKING_AROUND) leaves it undefined, so any of those users creating a workspace through the regular UI hits the same leak — the "Track and budget" path is simply the one Applause caught.

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

Replace the !introSelected?.createWorkspace half of the guard with !introSelected?.choice. The real question the block is trying to ask is "has this user ever completed a guided setup?", and introSelected.choice is the field that is actually set by every completeOnboarding call (MANAGE_TEAM, TRACK_WORKSPACE, EMPLOYER, SUBMIT, CHAT_SPLIT, LOOKING_AROUND, TEST_DRIVE_RECEIVER). So after the change, the block will only run when introSelected.choice is still undefined (brand-new user who hasn't chosen a purpose yet) or when the choice is TEST_DRIVE_RECEIVER (intentionally preserved by the first disjunct).

Concretely, in src/libs/actions/Policy/Policy.ts change the middle clause of the if from:

introSelected.choice === CONST.ONBOARDING_CHOICES.TEST_DRIVE_RECEIVER || !introSelected?.createWorkspace

to:

introSelected.choice === CONST.ONBOARDING_CHOICES.TEST_DRIVE_RECEIVER || !introSelected?.choice

With this change:

• MANAGE_TEAM users who already went through the guided flow still skip the block (they have choice = MANAGE_TEAM), preserving today's behavior for their second-or-later workspace.
• TRACK_WORKSPACE / PERSONAL_SPEND / EMPLOYER / SUBMIT / CHAT_SPLIT / LOOKING_AROUND users now also skip the block, because their choice is populated — this is what fixes the reported #admins leak and closes the same class of bug for the other Concierge-based onboarding paths.
• TEST_DRIVE_RECEIVER still falls into the block via the first disjunct, so the downstream special-case (completing the createWorkspace task in Concierge, around Policy.ts L2928) continues to work.
• A hypothetical user with introSelected.choice undefined (pre-onboarding) still enters the block, preserving the fallback branch.

No other call sites need to change: every in-product onboarding entry point (BaseOnboardingWorkspaceConfirmation, BaseOnboardingWorkspaceOptional, BaseOnboardingInterestedFeatures, useAutoCreateTrackWorkspace) already calls createWorkspace with shouldAddOnboardingTasks: false, so they were never relying on this block to add their onboarding tasks; they add them via their own completeOnboarding call. The only callers hitting this code path were the post-onboarding workspace-creation entry points (savePolicyDraftByNewWorkspace, the SettlementButton invoice upgrade path, IOURequestStepUpgrade, WorkspaceConfirmationForTravelPage), all of which should not be adding onboarding tasks — they serve users who are already onboarded.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/88689-onboarding-tasks-admins-room?expand=1

What alternative solutions did you explore? (Optional)

1. Tightening the ternary in savePolicyDraftByNewWorkspace so TRACK_WORKSPACE is treated like PERSONAL_SPEND. That flips engagementChoice to TRACK_WORKSPACE and moves the target chat from the admins room to Concierge (isPostingTasksInAdminsRoom only returns true for MANAGE_TEAM). This would stop the #admins leak, but it would re-post the TRACK_WORKSPACE tasks into Concierge every time a Track-and-Budget user creates another workspace — trading an admins-room leak for a Concierge duplication. Rejected.

2. Defaulting shouldAddOnboardingTasks to false inside savePolicyDraftByNewWorkspace. That would fix the symptom, but it only patches one of several callers that don't pass the flag (others include SettlementButton, IOURequestStepUpgrade, WorkspaceConfirmationForTravelPage). Fixing the guard in buildPolicyData is a single change that covers every post-onboarding entry point.

3. Adding hasCompletedGuidedSetupFlow (from NVP_ONBOARDING) as a new guard. This would require threading an additional Onyx value into buildPolicyData and every CreateWorkspaceDataOptions caller. The introSelected.choice check achieves the same semantics using a value that is already passed in, so the extra plumbing is unnecessary.

[melvin-bot]

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