[$250] Reports - Both current and previous account managers are appearing in the managed customers accounts when using filters

[izarutskaya]

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.27-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
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: @VictoriaExpensify
Slack conversation (hyperlinked to channel name): #expensify_migrate

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Navigate to the Reports page > click filter From

Expected Result:

We should remove AMs from these filters, especially once the AM has been unassigned.

Actual Result:

Account Managers get added as "hidden" members of their managed customer workspaces so they can better support the customer. They should be completely invisible but, when using filters in the Reports tab, the AM is appearing. This is confusing for the customer.

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

Check details in the OP

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mavrickdeveloper

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022028449180043588430
• Upwork Job ID: 2028449180043588430
• Last Price Increase: 2026-03-02

[melvin-bot]

Triggered auto assignment to @heyjennahay (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MelvinBot]

Proposal

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

Account Managers (AMs) are added as "hidden" members of their managed customer workspaces (with notificationPreference: 'hidden'). They should be completely invisible to the customer. However, when a customer uses the "From" filter on the Reports/Search page, both current and previous Account Managers appear as selectable options. This is confusing for customers who don't recognize these people.

What is the root cause of that problem?

The search filter participant selection has two code paths that both fail to filter out hidden workspace members:

Path 1 — Advanced Filter page (SearchFiltersFromPage → SearchFiltersParticipantsSelector): The component calls getValidOptions at SearchFiltersParticipantsSelector.tsx:111-132 with only excludeLogins: CONST.EXPENSIFY_EMAILS_OBJECT (system emails like concierge@expensify.com). It does not pass excludeFromSuggestionsOnly for Guide/AM logins, even though this mechanism already exists and is used by WorkspaceInvitePage (WorkspaceInvitePage.tsx:77-80).

Path 2 — Inline search autocomplete (typing from: in the search bar): useAutocompleteSuggestions at useAutocompleteSuggestions.ts:208-234 calls getSearchOptions, which also lacks any Guide/AM exclusion logic.

Additionally, the option list itself is built from ALL entries in the personalDetails Onyx store (OptionsListUtils/index.ts:1427-1448) without filtering for hidden notification preferences, and processReport at OptionsListUtils/index.ts:1370 calls getParticipantsAccountIDsForDisplay(report) without shouldExcludeHidden=true, so hidden participants from workspace reports also leak into the options.

The infrastructure to filter hidden members exists — getValidOptions accepts excludeFromSuggestionsOnly (line 2380), and getSoftExclusionsForGuideAndAccountManager in PolicyUtils.ts:571-577 builds the right exclusion map — but neither search filter path uses it.

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

1. In SearchFiltersParticipantsSelector: Aggregate getSoftExclusionsForGuideAndAccountManager across all of the user's policies to build a combined exclusion set for all current Guides/AMs. Pass this as excludeFromSuggestionsOnly to getValidOptions, following the same pattern already used in WorkspaceInvitePage.

2. For previous/unassigned AMs: Since getSoftExclusionsForGuideAndAccountManager only captures the current AM/Guide per policy, we also need to handle former AMs. We should collect accountIDs whose notificationPreference is 'hidden' across workspace report participants and include those logins in the excludeFromSuggestionsOnly set. This can be done by iterating options.reports (which are already available from useOptionsList) and checking report.participants for hidden entries.

3. For the inline search autocomplete path: Extend getSearchOptions (OptionsListUtils/index.ts:2672-2722) to accept and forward excludeFromSuggestionsOnly, and pass the same exclusion set from step 1-2 when calling it from useAutocompleteSuggestions.

What alternative solutions did you explore? (Optional)

• Passing shouldExcludeHidden=true in processReport (line 1370): This would prevent hidden members from appearing in report-based options, but personal details options are built independently from ALL Onyx personalDetails entries, so this alone is insufficient.
• Backend fix (stop syncing personalDetails for hidden members): This would break message rendering in workspace chats where the AM has sent messages, so it's not viable.
• Filtering at createOptionList level: Would require cross-referencing personal details with report participants to determine if someone is only a hidden member, which is more invasive than the excludeFromSuggestionsOnly approach.

Detailed Investigation

Evidence Chain

1. SearchFiltersFromPage renders SearchFiltersParticipantsSelector with account IDs from the search form
2. SearchFiltersParticipantsSelector uses useOptionsList() → OptionListContextProvider → createOptionList()
3. createOptionList builds options.personalDetails from ALL entries in PERSONAL_DETAILS_LIST Onyx store without filtering
4. processReport (line 1370) calls getParticipantsAccountIDsForDisplay(report) without shouldExcludeHidden, so hidden AMs are included in report-to-accountID mappings
5. getValidOptions filters only by system emails (EXPENSIFY_EMAILS_OBJECT) and restricted logins — no hidden member check
6. Result: AMs in personalDetails appear as filter suggestions

Relevant Code

• App/src/components/Search/SearchFiltersParticipantsSelector.tsx:111-132 — Missing excludeFromSuggestionsOnly
• App/src/hooks/useAutocompleteSuggestions.ts:208-234 — Inline autocomplete for from: also lacks exclusions
• App/src/libs/OptionsListUtils/index.ts:1370 — processReport missing shouldExcludeHidden
• App/src/libs/OptionsListUtils/index.ts:1427-1448 — createOptionList iterates all personalDetails
• App/src/libs/OptionsListUtils/index.ts:2380-2416 — getValidOptions has excludeFromSuggestionsOnly support (unused by search)
• App/src/libs/PolicyUtils.ts:571-577 — getSoftExclusionsForGuideAndAccountManager (only used in invite pages)
• App/src/libs/ReportUtils.ts:3447 — shouldExcludeHidden check exists but not invoked in search paths
• App/src/pages/workspace/WorkspaceInvitePage.tsx:77-80 — Reference implementation that correctly uses soft exclusions

Confidence: High

Code-level evidence clearly shows the filtering mechanism exists but is not wired into the search filter paths. The pattern for the fix is already established in WorkspaceInvitePage.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[yuvrajangadsingh]

🚨 Edited by proposal-police: This proposal was edited at 2026-03-04 21:28:42 UTC.

Proposal (updated to align with Classic parity per @heyjennahay)

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

When customers use the "From" filter on the Reports/Search page, Account Managers (current and previous) show up as selectable options. AMs are hidden workspace members and should be invisible. Per @heyjennahay, the fix should match Classic: only show workspace members in the From filter and allow free text input for arbitrary emails.

What is the root cause of that problem?

Two things:

1. SearchFiltersParticipantsSelector calls getValidOptions with the full personalDetails Onyx store and only excludes system emails (CONST.EXPENSIFY_EMAILS_OBJECT). Everyone the user has ever interacted with shows up, including hidden AMs.

2. createOptionList in OptionsListUtils/index.ts calls getParticipantsAccountIDsForDisplay(report) at line 1370 without shouldExcludeHidden=true, so hidden AM participants leak into the report-to-accountID mappings. The same function is called with true at lines 1118 and 1179, so this call site is the odd one out.

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

Three changes to match Classic behavior:

1. Scope the From filter to workspace members only

In SearchFiltersParticipantsSelector, when rendering the "From" filter, scope options to workspace members instead of all personalDetails. Collect member accountIDs from the user's policies via getPolicyMembersByIdWithoutCurrentUser and filter options.personalDetails to only those accountIDs.

This is a fundamentally different approach from just adding AM exclusions. Excluding AMs still shows every person the user has ever chatted with (DMs, group chats, random contacts), which is not how Classic works. Classic only shows workspace members. Scoping to workspace members solves the AM problem as a side effect (AMs aren't workspace members visible to the customer) and matches the actual Classic behavior @heyjennahay described.

2. Fix processReport to exclude hidden participants

Line 1370 of OptionsListUtils/index.ts is missing shouldExcludeHidden=true:

- const accountIDs = getParticipantsAccountIDsForDisplay(report);
+ const accountIDs = getParticipantsAccountIDsForDisplay(report, true);

This is consistent with lines 1118 and 1179 in the same file which already pass true. This fix benefits all consumers, including the inline search autocomplete path (from: typed in the search bar via useAutocompleteSuggestions), since both the filter page and inline autocomplete build their options from createOptionList.

3. Allow free text input in the From field

The shouldAllowNameOnlyOptions pattern already exists in this component for the attendee filter. Extend it to the "from" filter so users can type any email address that doesn't match an existing option and still use it as a filter value. This matches Classic where you can type arbitrary emails.

All changes are in SearchFiltersParticipantsSelector.tsx and OptionsListUtils/index.ts.

@DylanDylann let me know if anything needs clarification.