[$250] Category and Tag Approvers Do Not Exclude Expensify Members Like Members List Does

[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:
Reproducible in staging?: Needs Reproduction (Reproduction blocked)
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: @twisterdotcom
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Open a workspace with:
   Members configured
   Category or tag approval rules enabled
2. Compare:
   Workspace Members list filtering
   Category approver selection list
   Tag approver selection list
3. Observe available users in each selector

Expected Result:

Category and tag approver selectors should:
Apply the same member filtering/exclusion logic as the Members list
Only eligible workspace members should appear as selectable approvers

Actual Result:

Category/tag approver selectors:
Include Expensify members that are excluded elsewhere
Filtering behavior is inconsistent across workflows

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 screenshot for the issue are in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022058328338920832877
• Upwork Job ID: 2058328338920832877
• Last Price Increase: 2026-05-23

[MelvinBot]

Proposal

What is the root cause of that problem?

The WorkspaceMembersSelectionList component (used by both the category approver and tag approver pages) iterates policy.employeeList but only filters out deleted members. It never calls isExpensifyTeam() / shouldFilterExpensifyTeam() to exclude Expensify team members (expensify.com and team.expensify.com domains).

In contrast, the Members list and the workflow payer selector both apply this filtering.

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

Add the Expensify team filter inside WorkspaceMembersSelectionList's employee loop (around line 52):

1. Import isExpensifyTeam and shouldFilterExpensifyTeam from PolicyUtils
2. Get the current user's login via useCurrentUserPersonalDetails
3. Compute shouldFilterExpensifyTeam(policy?.owner, currentUserLogin) once before the loop
4. Inside the loop, continue if the employee's email is an Expensify team member and filtering is enabled — with an exception for the currently selected approver (so an already-assigned Expensify approver remains visible)

This centralizes the fix in the shared component, automatically covering category approvers, tag approvers, and the HR final approver page.

What alternative solutions did you explore?

Patching each consumer page (DynamicCategoryApproverPage, TagApproverPage, HRFinalApproverPageBase) individually — rejected because the shared component is the right place for this filtering and prevents the same omission in future consumers.

---

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.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The Members list and the Category/Tag approver selectors build their member lists from policy.employeeList independently, and only the Members list strips out Expensify support/guide accounts.

The Members list filters them out in WorkspaceMembersPage — when the policy isn't owned by Expensify and the current user isn't on the Expensify team, any member whose email is on expensify.com/team.expensify.com is skipped:

App/src/pages/workspace/WorkspaceMembersPage.tsx

Lines 432 to 439 in a9c3c31

	// If this policy is owned by Expensify then show all support (expensify.com or team.expensify.com) emails
	// We don't want to show guides as policy members unless the user is a guide. Some customers get confused when they
	// see random people added to their policy, but guides having access to the policies help set them up.
	if (isExpensifyTeam(details?.login ?? details?.displayName)) {
	if (policyOwner && currentUserLogin && !isExpensifyTeam(policyOwner) && !isExpensifyTeam(currentUserLogin)) {
	continue;
	}
	}

The approval-workflow approver selectors already do the same thing, via the shared shouldFilterExpensifyTeam + isExpensifyTeam helpers:

App/src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsApproverPage.tsx

Lines 57 to 80 in a9c3c31

	const shouldFilterOutExpensifyTeam = shouldFilterExpensifyTeam(policy?.owner, currentUserPersonalDetails?.login);
	const allApprovers: SelectionListApprover[] = useMemo(() => {
	if (isApprovalWorkflowLoading || !employeeList) {
	return [];
	}
	const membersEmail = approvalWorkflow?.members?.map((member) => member.email);
	return Object.values(employeeList)
	.map((employee): SelectionListApprover | null => {
	const email = employee.email;
	if (!email) {
	return null;
	}
	if (employee.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	return null;
	}
	if (shouldFilterOutExpensifyTeam && isExpensifyTeam(email) && visibleSelectedApproverEmail !== email) {
	return null;
	}

But the Category and Tag approver pages (DynamicCategoryApproverPage, TagApproverPage) both render WorkspaceMembersSelectionList, and that component only skips members with no email or a pending DELETE — it never applies the Expensify-team exclusion:

App/src/components/WorkspaceMembersSelectionList.tsx

Lines 48 to 76 in a9c3c31

	if (policy?.employeeList) {
	for (const employee of Object.values(policy.employeeList)) {
	const email = employee.email;
	if (!email || employee.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	continue;
	}
	const policyMemberEmailsToAccountIDs = getMemberAccountIDsForWorkspace(policy?.employeeList);
	const accountID = Number(policyMemberEmailsToAccountIDs[email] ?? '');
	const {avatar, displayName = email, login} = personalDetails?.[accountID] ?? {};
	approvers.push({
	text: displayName,
	alternateText: email,
	keyForList: email,
	isSelected: selectedApprover === email,
	login: email,
	icons: [{source: avatar ?? icons.FallbackAvatar, type: CONST.ICON_TYPE_AVATAR, name: displayName, id: accountID}],
	rightElement: (
	<MemberRightIcon
	role={employee.role}
	owner={policy?.owner}
	login={login}
	/>
	),
	});
	}
	}

So for a normal customer workspace, Expensify guides/support that are hidden in the Members list (and in the workflow approver pickers) still show up as selectable category/tag approvers — exactly the inconsistency reported.

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

Apply the same Expensify-team filter inside WorkspaceMembersSelectionList so every consumer (category + tag approvers) gets parity with the Members list and the workflow approver pickers. I'd mirror the workflow page exactly, including keeping an already-selected Expensify approver visible so editing an existing rule doesn't drop the current value.

In src/components/WorkspaceMembersSelectionList.tsx:

+    const currentUserPersonalDetails = useCurrentUserPersonalDetails();
+    const shouldFilterOutExpensifyTeam = shouldFilterExpensifyTeam(policy?.owner, currentUserPersonalDetails?.login);

     const approvers: SelectionListApprover[] = [];

     if (policy?.employeeList) {
         for (const employee of Object.values(policy.employeeList)) {
             const email = employee.email;

             if (!email || employee.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
                 continue;
             }
+
+            if (shouldFilterOutExpensifyTeam && isExpensifyTeam(email) && selectedApprover !== email) {
+                continue;
+            }

Supporting changes: import useCurrentUserPersonalDetails from @hooks/useCurrentUserPersonalDetails, and extend the existing @libs/PolicyUtils import to include isExpensifyTeam and shouldFilterExpensifyTeam (both already exported there).

What alternative solutions did you explore? (Optional)

• Filter in each page (DynamicCategoryApproverPage/TagApproverPage) before passing data in — rejected; the list is constructed inside the shared WorkspaceMembersSelectionList, so fixing it at the source dedupes the logic and guarantees any future consumer of the component inherits the correct behavior.
• Hard-exclude all Expensify-team emails unconditionally — rejected; that would hide an already-configured Expensify approver when re-opening the selector to edit it. The selectedApprover !== email exception matches the workflow approver page's visibleSelectedApproverEmail !== email guard.

[KJ21-ENG]

Proposal

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

Category and tag approver selectors can show Expensify/team-expensify support members to customer admins even though the main workspace Members list hides those same members for the same workspace/user combination.

What is the root cause of that problem?

The category and tag approver pages both render the shared WorkspaceMembersSelectionList.

App/src/pages/workspace/categories/DynamicCategoryApproverPage.tsx

Lines 49 to 56 in a9c3c31

	<WorkspaceMembersSelectionList
	policyID={policyID}
	selectedApprover={selectedApprover}
	setApprover={(email) => {
	setPolicyCategoryApprover(policyID, categoryName, email, policy?.rules?.approvalRules ?? []);
	Navigation.setNavigationActionToMicrotaskQueue(() => Navigation.goBack(categorySettingsBackPath));
	}}
	/>

App/src/pages/workspace/tags/TagApproverPage.tsx

Lines 54 to 61 in a9c3c31

	<WorkspaceMembersSelectionList
	policyID={policyID}
	selectedApprover={tagApprover ?? ''}
	setApprover={(email) => {
	setPolicyTagApprover(policy, tagName, email);
	Navigation.setNavigationActionToMicrotaskQueue(goBack);
	}}
	/>

That shared list builds approver options directly from policy.employeeList. It only skips missing emails and pending deletes before pushing every remaining employee into the selectable list, and it also recomputes the workspace email-to-accountID map inside the loop.

App/src/components/WorkspaceMembersSelectionList.tsx

Lines 48 to 75 in a9c3c31

	if (policy?.employeeList) {
	for (const employee of Object.values(policy.employeeList)) {
	const email = employee.email;
	if (!email || employee.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	continue;
	}
	const policyMemberEmailsToAccountIDs = getMemberAccountIDsForWorkspace(policy?.employeeList);
	const accountID = Number(policyMemberEmailsToAccountIDs[email] ?? '');
	const {avatar, displayName = email, login} = personalDetails?.[accountID] ?? {};
	approvers.push({
	text: displayName,
	alternateText: email,
	keyForList: email,
	isSelected: selectedApprover === email,
	login: email,
	icons: [{source: avatar ?? icons.FallbackAvatar, type: CONST.ICON_TYPE_AVATAR, name: displayName, id: accountID}],
	rightElement: (
	<MemberRightIcon
	role={employee.role}
	owner={policy?.owner}
	login={login}
	/>
	),
	});
	}

The workspace Members page has an extra visibility rule for customer-owned workspaces: when both the policy owner and current viewer are not Expensify team members, expensify.com and team.expensify.com members are skipped.

App/src/pages/workspace/WorkspaceMembersPage.tsx

Lines 432 to 439 in a9c3c31

	// If this policy is owned by Expensify then show all support (expensify.com or team.expensify.com) emails
	// We don't want to show guides as policy members unless the user is a guide. Some customers get confused when they
	// see random people added to their policy, but guides having access to the policies help set them up.
	if (isExpensifyTeam(details?.login ?? details?.displayName)) {
	if (policyOwner && currentUserLogin && !isExpensifyTeam(policyOwner) && !isExpensifyTeam(currentUserLogin)) {
	continue;
	}
	}

The shared helpers for that rule already exist in PolicyUtils, and the workflow approver picker already uses them before adding approver options.

App/src/libs/PolicyUtils.ts

Lines 611 to 619 in a9c3c31

	function isExpensifyTeam(email: string | undefined): boolean {
	const emailDomain = Str.extractEmailDomain(email ?? '');
	return emailDomain === CONST.EXPENSIFY_PARTNER_NAME || emailDomain === CONST.EMAIL.GUIDES_DOMAIN;
	}
	/** Whether Expensify team members should be hidden from the given policy/user combination. */
	function shouldFilterExpensifyTeam(policyOwner: string | undefined, currentUserLogin: string | undefined): boolean {
	return !!policyOwner && !!currentUserLogin && !isExpensifyTeam(policyOwner) && !isExpensifyTeam(currentUserLogin);
	}

App/src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsApproverPage.tsx

Lines 57 to 80 in a9c3c31

	const shouldFilterOutExpensifyTeam = shouldFilterExpensifyTeam(policy?.owner, currentUserPersonalDetails?.login);
	const allApprovers: SelectionListApprover[] = useMemo(() => {
	if (isApprovalWorkflowLoading || !employeeList) {
	return [];
	}
	const membersEmail = approvalWorkflow?.members?.map((member) => member.email);
	return Object.values(employeeList)
	.map((employee): SelectionListApprover | null => {
	const email = employee.email;
	if (!email) {
	return null;
	}
	if (employee.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	return null;
	}
	if (shouldFilterOutExpensifyTeam && isExpensifyTeam(email) && visibleSelectedApproverEmail !== email) {
	return null;
	}

Because WorkspaceMembersSelectionList does not apply the same shouldFilterExpensifyTeam() / isExpensifyTeam() check, category and tag rules expose support members that the workspace Members list hides.

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

Apply the same Expensify-team visibility filter inside WorkspaceMembersSelectionList, where the category, tag, and HR final approver pickers build their options.

1. Import useCurrentUserPersonalDetails().
2. Import isExpensifyTeam and shouldFilterExpensifyTeam from PolicyUtils.
3. Compute shouldFilterOutExpensifyTeam = shouldFilterExpensifyTeam(policy?.owner, currentUserPersonalDetails?.login) once.
4. Compute getMemberAccountIDsForWorkspace(policy.employeeList) once before iterating employees.
5. In the employee loop, keep the existing missing-email and pending-delete guards, then skip Expensify/team emails when shouldFilterOutExpensifyTeam && isExpensifyTeam(email) && selectedApprover !== email.

The selectedApprover !== email exception matches the workflow approver picker pattern. It prevents hidden Expensify support accounts from being offered as new choices while still showing an already configured value when a rule is reopened for editing.

Add focused regression coverage around WorkspaceMembersSelectionList or the category/tag approver screens:

1. Customer-owned policy, non-Expensify admin, normal member plus an @expensify.com or @team.expensify.com member: only the normal member is listed.
2. Same data with the Expensify/team email as selectedApprover: the current selection remains visible.
3. Expensify-owned policy or Expensify current user: the Expensify/team member remains visible, preserving the existing support/admin exception.
4. Pending-delete members are still excluded.

Scope boundaries: this change belongs in src/components/WorkspaceMembersSelectionList.tsx plus tests. It affects the category approver, tag approver, and HR final approver selectors that already consume this shared component. It should not change workspace membership storage, the Members page implementation, workflow approval rules, backend policy APIs, or unrelated policy member selectors.

What alternative solutions did you explore? (Optional)

Filtering separately in DynamicCategoryApproverPage and TagApproverPage would fix the two reported screens, but it would duplicate eligibility logic and leave the HR final approver caller inconsistent. The shared list is the source of the duplicated behavior.

Hard-excluding every Expensify/team email, including the current selection, would be simpler but would diverge from the existing workflow approver picker and could make an already configured approver disappear while editing a rule.

Changing policy.employeeList or backend membership data is broader than needed. The inconsistency is client-side option filtering: the Members page and workflow approver picker already know how to hide these accounts for customer admins.

[melvin-bot]

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

[melvin-bot]

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

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[lxyct825-ops]

Proposal

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

[$250] Category and Tag Approvers Do Not Exclude Expensify Members Like Members List Does

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

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

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.

[lxyct825-ops]

Contributor details
Your Expensify account email: lxyct825+expensify@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01174eaf71ab8fc150