Workspace members not showing the full list in ND

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number:
Reproducible in staging?: Needs reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
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: @DGephart
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Log in to new.expensify.com
2. Select Workspaces
3. Click on any workspace
4. Navigate to Members section

Expected Result:

The admin should be able to see a list of all members part of the workspace in ND

Actual Result:

The admin only sees half of the users in ND, but show the full list in Classic

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

The video for the issue is in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

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

[MelvinBot]

Proposal

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

Workspace admins see only a subset (~half) of members on the NewDot Members page, while Classic/OldDot shows the full list.

What is the root cause of that problem?

NewDot's Members page renders policy.employeeList joined against the global personal-details list, and silently drops any member whose personal details aren't present in Onyx. There are two drop points:

• In filteredMembers, each employeeList entry is skipped when personalDetails?.[accountID] is falsy — WorkspaceMembersPage.tsx:347-351.
• The email → accountID map is built by getMemberAccountIDsForWorkspace, which skips any email whose cached personal detail has no login — PolicyUtils.ts:828-832.

So the rendered count = employeeList ∩ loaded-personalDetails. Compounding it, the loading guard clears as soon as any personal detail is present (isPersonalDetailsReady uses .some(...)), so the page happily renders a partial list rather than waiting — WorkspaceMembersPage.tsx:135-137. Classic doesn't gate on personal details, which is why it shows everyone. This also explains why it's intermittent / "unable to reproduce" — it depends on which members' details happen to be loaded.

The members' details are expected to come from the OpenWorkspaceMembersPage read command (Member.ts:1241-1253). If that backend response returns personal details for only some employeeList members (or omits closed/merged accounts and accounts with no login), those members never appear.

Investigation details & how to confirm

• App has no client-side pagination/batching here — a single API.read(OPEN_WORKSPACE_MEMBERS_PAGE) fires on mount, iterating the full employeeList. So this is not a client loop-limit bug; it's the personal-details join.
• clientMemberEmails sent to the backend is itself pre-filtered by loaded personal details (getWorkspaceMembers, WorkspaceMembersPage.tsx:197-200) — worth confirming the backend delta logic doesn't rely on that in a way that under-fetches.
• To confirm root cause with production logs (need a policyID from an affected admin): pull the OpenWorkspaceMembersPage response for that request and compare policy.employeeList size vs. the number of personalDetailsList entries returned. If details ≈ half of employeeList, the backend (Web-Expensify/Auth) is under-returning personal details and the fix belongs there. The issue currently has no reproduction IDs, so this couldn't be verified from logs yet.

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

Two independent angles:

1. App-side robustness (matches Classic): don't silently drop members with missing personal details. In filteredMembers, instead of continue when !details, render the member with a fallback identity (email as display name), so the count always matches employeeList. Same for the getMemberAccountIDsForWorkspace join used to build the row.
2. Backend (if confirmed): if OpenWorkspaceMembersPage returns personal details for only a subset of employeeList (e.g. omits accounts lacking a login, or applies an incorrect clientMemberEmails delta), fix it so every employeeList member's details are returned. This lives outside the App repo (Web-Expensify/Auth) and needs an internal engineer.

What alternative solutions did you explore?

Blocking render until all members' personal details load (stricter isPersonalDetailsReady) would avoid the partial list but could stall the page indefinitely if some details never arrive — the fallback-render approach is safer.

Confidence: Medium. The App-side drop mechanism is confirmed in code; whether the underlying cause is the backend under-returning details vs. purely the App gating needs a log check against an affected policyID.

---

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

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

@gijoe0295 Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

@gijoe0295 Eep! 4 days overdue now. Issues have feelings too...