[$250] #Admin room not displayed for Track expenses for my business onboarding

[m-natarajan]

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

---

Version Number: 9.3.92-1
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause Internal Team
Slack conversation (hyperlinked to channel name): More context here

Action Performed:

1. Go to Staging.new.expensify.com
2. Signup for a new account without +
3. Choose Track expenses for my business onboarding purpose
4. Observe the LHN

Expected Result:

#Admin room displayed in LHN

Actual Result:

#Admin room displayed only after searching, Same after creating a second workspace as well

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Recording.2944.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022061914342799802566
• Upwork Job ID: 2061914342799802566
• Last Price Increase: 2026-06-02

[MelvinBot]

⚠️ Correction (2026-06-02): This analysis is wrong — the "needs a backend fix" conclusion below does not hold. This is an App-side regression introduced by PR #82804, and the fix is in App. See my corrected analysis here. Leaving the original below for transparency.

---

Issue Analysis

Root cause: The "Track expenses for my business" workspace #admin room is created empty (no messages), and an empty room only appears in the default LHN when it's pinned. App code does pin the admin room, and the normal "create workspace" flow shows it correctly — but in this onboarding flow the pin is not in effect by the time the LHN renders, so the empty‑chat filter hides it from the default list while LHN search still finds it (search doesn't filter out empty chats). That's why it "only shows after searching."

Why the room is empty: For the TRACK_WORKSPACE intent (what "Track expenses for my business" maps to), the onboarding welcome message and setup tasks are posted to Concierge, not the #admin room — only MANAGE_TEAM posts them into #admin (ReportUtils.ts:11693-11700, isPostingTasksInAdminsRoom ReportUtils.ts:12350-12352). So the new #admin room has only a CREATED action and stays empty.

Where the pin is lost (needs internal verification): App optimistically pins the admin room (ReportUtils.ts:8621), and I verified the standard create‑workspace flow shows it correctly (Onyx: isPinned: true, lastMessageText: "", room visible in LHN without searching). The onboarding flow runs the same createWorkspace, then additionally calls CompleteGuidedSetup (useAutoCreateTrackWorkspace.ts:92). App code never writes the admin room during onboarding (everything goes to Concierge), so the pin must be getting cleared by the CompleteGuidedSetup server response.

This appears to be a backend/internal issue — the CompleteGuidedSetup onboarding response not preserving the #admin room's pinned state (the standard CreateWorkspace flow does preserve it). A separate internal investigation by an engineer with backend access is needed; this is not an App‑only fix. The fix should ensure the Track‑business onboarding response keeps the admin room pinned by default, matching the regular workspace‑creation flow.

Investigation details & evidence

Verified via browser repro (standard flow works): Created a new workspace from an existing account; the #admins room appeared in the LHN immediately. Onyx report (chatType: "policyAdmins"): isPinned: true, lastMessageText: "", lastVisibleActionCreated set. So the generic createWorkspace path and the LHN filter are both behaving correctly — the empty room shows because it's pinned.

LHN default vs. search filter (explains "only after searching"):

• A pinned report short‑circuits the LHN filter and is always shown: reasonForReportToBeInOptionList ReportUtils.ts:9672.
• An empty, unpinned chat is dropped by the empty‑chat exclusion (note there is no admin‑room carve‑out here): ReportUtils.ts:9711-9723.
• Default LHN calls the filter with excludeEmptyChats: true (SidebarUtils.ts:341); LHN search calls the same filter with excludeEmptyChats: false (OptionsListUtils/index.ts:2102-2117). Hence an empty + unpinned admin room is missing from the default LHN but found via search.

Data flow:

1. User picks "Track expenses for my business" → useAutoCreateTrackWorkspace → createWorkspace creates the workspace and an admin room pinned via shouldPinAdminRoomByDefault() (true for non‑Expensify users).
2. completeOnboarding sends CompleteGuidedSetup; for TRACK_WORKSPACE the welcome message/tasks go to Concierge, so the admin room stays empty.
3. The admin room's only LHN safeguard is the pin. After the CompleteGuidedSetup server response, the pin is no longer in effect → the empty room is filtered out of the default LHN but remains discoverable in search.

Alternative considered: A frontend regression in the LHN filter itself — ruled out, because the same filter correctly shows the (empty, pinned) admin room for the standard create‑workspace flow in the repro. The differentiator between the working flow and the broken flow is the extra CompleteGuidedSetup step.

Possibly related (different mechanism): #91320 — also "only visible via search" in the LHN, but for an unread DM rather than an empty admin room.

---

Next Steps: This needs an internal engineer with backend access to confirm and fix the CompleteGuidedSetup onboarding response. Reply with @MelvinBot <your feedback> to refine this analysis.

[abbasifaizan70]

Proposal

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

After signing up for a new account (without +) and selecting the "Track expenses for my business" onboarding intent, the workspace #admin room is not shown in the LHN. It only appears once the user searches for it, and the same behavior persists even after creating a second workspace. The expected behavior is that the #admin room is displayed in the LHN by default.

What is the root cause of that problem?

This is an App-side regression introduced by PR #82804 (merged 2026-02-23), which changed isPostingTasksInAdminsRoom so that the TRACK_WORKSPACE intent now routes its onboarding welcome message and tasks to Concierge instead of the #admins room. Previously both MANAGE_TEAM and TRACK_WORKSPACE posted into #admins, so the Track admin room always had content and stayed visible in the LHN; after the change the room is empty.

When the LHN builds its list of reports to display, it calls shouldReportBeInOptionList with excludeEmptyChats: true, which tells the option-list logic to drop empty chats.

App/src/libs/SidebarUtils.ts

Lines 341 to 355 in 8c54205

	const shouldDisplay = shouldReportBeInOptionList({
	report,
	chatReport,
	currentReportId,
	isInFocusMode,
	betas,
	excludeEmptyChats: true,
	doesReportHaveViolations,
	draftComment,
	includeSelfDM: true,
	isReportArchived,
	requiresAttention,
	currentUserLogin,
	currentUserAccountID,
	});

Inside reasonForReportToBeInOptionList, the empty-chat filter hides any empty chat report that isn't one of the explicitly exempted types (policy expense chat, trip room, concierge, system chat, self DM). Admin rooms are not in that exemption list, so the now-empty #admin room falls through and returns null (hidden). It still appears in search because that path builds the option list with excludeEmptyChats: false, which is the smoking gun confirming this filter is the gate.

App/src/libs/ReportUtils.ts

Lines 9711 to 9723 in 8c54205

	if (
	excludeEmptyChats &&
	isEmptyChat &&
	isChatReport(report) &&
	!isPolicyExpenseChat(report) &&
	!isTripRoom(report) &&
	!isConciergeChatReport(report) &&
	!isSystemChatReport &&
	!isSelfDMWithVisiblePreference &&
	canHideReport
	) {
	return null;
	}

A manually-created workspace's #admin room is pinned, so it short-circuits earlier at the isPinned check and shows regardless of emptiness — this is why manual repro looks fine while the Track onboarding flow does not. PR #82804 did not touch pinning; it removed the content that was previously keeping the room visible, which exposed the filter.

App/src/libs/ReportUtils.ts

Line 9672 in 8c54205

if (report.isPinned) {

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

App/src/libs/ReportUtils.ts

Lines 9711 to 9723 in 21afc57

	if (
	excludeEmptyChats &&
	isEmptyChat &&
	isChatReport(report) &&
	!isPolicyExpenseChat(report) &&
	!isTripRoom(report) &&
	!isConciergeChatReport(report) &&
	!isSystemChatReport &&
	!isSelfDMWithVisiblePreference &&
	canHideReport
	) {
	return null;
	}

Add an admin-room exemption to the empty-chat filter so the #admin room is not hidden while empty (isAdminRoom is already defined in ReportUtils.ts). This restores the pre-#82804 "admin room always visible" behavior without reverting the routing change:

if (
    excludeEmptyChats &&
    isEmptyChat &&
    isChatReport(report) &&
    !isPolicyExpenseChat(report) &&
    !isTripRoom(report) &&
    !isConciergeChatReport(report) &&
    !isSystemChatReport &&
    !isSelfDMWithVisiblePreference &&
    !isAdminRoom(report) &&
    canHideReport
) {
    return null;
}

[abbasifaizan70]

As mentioned in my Merged PR here, I added a proposal for this regression.

@Krishna2323 @mollfpr @m-natarajan
CC @dylanexpensify

[MelvinBot]

Correction to my earlier analysis

My earlier comment concluded this was a backend issue — that was wrong, I apologize. abbasifaizan70's proposal is correct: this is an App‑side regression with an App‑side fix.

Root cause: PR #82804 (merged 2026‑02‑23) changed isPostingTasksInAdminsRoom so the TRACK_WORKSPACE ("Track expenses for my business") intent now routes its onboarding welcome message + tasks to Concierge instead of the #admins room — previously both MANAGE_TEAM and TRACK_WORKSPACE posted into #admins. Before that PR the Track admin room had content and always showed in the LHN; after it the room is empty, and empty chat rooms are dropped from the default LHN by the empty‑chat filter in reasonForReportToBeInOptionList (ReportUtils.ts:9711-9723), which has no admin‑room exemption. The room still appears in search because that path builds the option list with excludeEmptyChats: false — which is the smoking gun confirming the empty‑chat filter is the gate.

Why my repro looked fine (and what I got wrong): A manually‑created workspace's #admin room is pinned, so it short‑circuits the filter at ReportUtils.ts:9672 and shows regardless of emptiness — that's what I observed and mis‑extrapolated to the onboarding flow. In the Track onboarding flow the room is not surfaced by the pin, so it reaches the empty‑chat filter (proven by the search‑vs‑default behavior) and is dropped. PR #82804 didn't touch pinning — it removed the content that was previously keeping the room visible, which is what exposed the filter.

Recommended fix: Endorse abbasifaizan70's proposal — add !isAdminRoom(report) to the empty‑chat exclusion (ReportUtils.ts:9711-9723; isAdminRoom is already defined in that file). This restores the pre‑#82804 "admin room always visible" behavior without reverting the routing change (a revert would reintroduce the guide‑assignment issue that #82804 fixed).

Evidence

• PR 82244: Sign up - Still assign guide for Track users after created workspace #82804 diff narrowed the admins‑room routing from [MANAGE_TEAM, TRACK_WORKSPACE] to MANAGE_TEAM only:

// before
[CONST.ONBOARDING_CHOICES.MANAGE_TEAM, CONST.ONBOARDING_CHOICES.TRACK_WORKSPACE].includes(engagementChoice ...)
// after (current)
engagementChoice === CONST.ONBOARDING_CHOICES.MANAGE_TEAM && (!currentUserEmail?.includes('+') || userHasPhonePrimaryEmail)

Current state: isPostingTasksInAdminsRoom (ReportUtils.ts:12350-12352) and the Concierge routing it drives in prepareOnboardingOnyxData (ReportUtils.ts:11693-11700).

• Default LHN filters with excludeEmptyChats: true (SidebarUtils.ts:341); LHN search filters with excludeEmptyChats: false (OptionsListUtils/index.ts:2102-2117). This is why the empty admin room is hidden by default but found via search.

---

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

[MobileMage]

Proposal

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

When a brand-new user signs up and selects "Track expenses for my business" as their onboarding purpose, the #admins room for the auto-created workspace is missing from the LHN. The room exists in Onyx (it can be found by searching), but the chat list never renders it. The same problem reproduces for any subsequent workspace created from this account — neither the first nor the second admin room appears in the LHN until something forces the underlying check to re-evaluate.

What is the root cause of that problem?

The trigger is a combination of the Track Business onboarding path producing an empty admin room and the LHN's empty-chat exclusion in reasonForReportToBeInOptionList not exempting admin rooms.

WRITE PATH — useAutoCreateTrackWorkspace → createWorkspace → buildPolicyData. The hook calls createWorkspace with shouldAddOnboardingTasks: false and then awaits a separate completeOnboarding call. Inside completeOnboarding → prepareOnboardingOnyxData, the post target is selected via shouldPostTasksInAdminsRoom = shouldUseFollowupsInsteadOfTasks || isPostingTasksInAdminsRoom(engagementChoice). For TRACK_WORKSPACE (the engagement choice used by Track Business), isPostingTasksInAdminsRoom returns false because it only allows MANAGE_TEAM, so every onboarding task and the welcome message are posted to the Concierge chat, not the #admins room:

App/src/libs/ReportUtils.ts

Lines 12350 to 12353 in 8c54205

	function isPostingTasksInAdminsRoom(engagementChoice?: OnboardingPurpose): boolean {
	const userHasPhonePrimaryEmail = Str.endsWith(deprecatedCurrentUserEmail ?? '', CONST.SMS.DOMAIN);
	return engagementChoice !== undefined && engagementChoice === CONST.ONBOARDING_CHOICES.MANAGE_TEAM && (!deprecatedCurrentUserEmail?.includes('+') || userHasPhonePrimaryEmail);
	}

This is the structural difference vs MANAGE_TEAM: the admin room is created and pinned by buildOptimisticWorkspaceChats with isPinned: shouldPinAdminRoomByDefault(), but it never receives any user-visible report action. getLastVisibleMessage returns {lastMessageText: ''} for a chat whose only action is CREATED (ReportActionsUtils.ts L1479-L1483), so generateIsEmptyReport evaluates to true and isEmptyChat is true in the LHN filter for this room.

READ PATH — reasonForReportToBeInOptionList. The pin guard at L9672 (if (report.isPinned) return PINNED_BY_USER) is the only thing keeping a brand-new admin room visible. The optimistic write does set isPinned: true, but the value isn't asserted again in successData — the success block only clears pendingFields.addWorkspaceRoom and pendingAction. When the CreateWorkspace (and subsequent CompleteGuidedSetup) server responses come back with the admin report in their onyxData and that payload doesn't carry isPinned: true, the merged Onyx record ends up with isPinned unset/false. Once that happens, the pin guard is bypassed and the function falls through to the empty-chat exclusion at L9711-L9723:

if (
    excludeEmptyChats && isEmptyChat && isChatReport(report) &&
    !isPolicyExpenseChat(report) && !isTripRoom(report) &&
    !isConciergeChatReport(report) && !isSystemChatReport &&
    !isSelfDMWithVisiblePreference && canHideReport
) {
    return null;
}

App/src/libs/ReportUtils.ts

Lines 9711 to 9723 in 8c54205

	if (
	excludeEmptyChats &&
	isEmptyChat &&
	isChatReport(report) &&
	!isPolicyExpenseChat(report) &&
	!isTripRoom(report) &&
	!isConciergeChatReport(report) &&
	!isSystemChatReport &&
	!isSelfDMWithVisiblePreference &&
	canHideReport
	) {
	return null;
	}

Every condition is satisfied for the admin room (it is an empty chat, it is a chat report, and none of the existing exemptions apply to POLICY_ADMINS), so reasonForReportToBeInOptionList returns null and shouldDisplayReportInLHN excludes the room. The room reappears after a search/tab switch because that flow triggers an API read (e.g. OpenSearchPage) whose response re-merges the admin report with its server-side isPinned: true, which then lets the pin guard at L9672 fire on the next LHN re-evaluation.

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

Add !isAdminRoom(report) to the empty-chat exclusion in reasonForReportToBeInOptionList, alongside the existing !isPolicyExpenseChat/!isTripRoom/!isConciergeChatReport/!isSystemChatReport exemptions. Admin rooms are the workspace settings entry point for policy admins and should always be reachable from the LHN regardless of whether they currently have a lastVisibleAction or whether the isPinned flag survived the latest server merge. This matches the pattern already used for the other workspace/system chats in the same condition, and isAdminRoom is already imported and used multiple times in ReportUtils.ts. The change:

if (
    excludeEmptyChats && isEmptyChat && isChatReport(report) &&
    !isPolicyExpenseChat(report) && !isTripRoom(report) &&
    !isConciergeChatReport(report) && !isSystemChatReport &&
    !isSelfDMWithVisiblePreference && !isAdminRoom(report) &&
    canHideReport
) {
    return null;
}

This is safe across edge cases. Inaccessible admin rooms (user not on the workspace) are already filtered earlier by canAccessReport/canSeeDefaultRoom at L9624, archived workspace admin rooms are caught by the archived-non-expense return at L9704 before reaching this block, and admin rooms with chatType cleared on the server still match isAdminRoom because the optimistic chatType: POLICY_ADMINS survives any subsequent MERGE. The fix addresses the second-workspace repro for free since the gate is the same code path for every admin room.

What alternative solutions did you explore? (Optional)

Re-asserting isPinned: adminsChatData.isPinned inside the successData block of buildPolicyData would also paper over this specific case by ensuring the server response can't silently un-pin the room. It's a narrower change, but it leaves the underlying read-path bug intact: if a user manually unpins the admin room (or any future code path momentarily clears isPinned), the LHN would hide it again the moment it goes empty. Fixing the LHN filter to always exempt admin rooms aligns with how Concierge/system/policy-expense chats are already handled and is the more durable fix.