[$250] Workflow - Members with existing approval workflow appear in new approval flow

[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.32-0
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-7762/folder/13176709/41236912/1232117774?sort=%2Bidentifier
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11/ Chrome
App Component: Workspace Settings

Action Performed:

Pre-requisite:
User has a control workspace with 3 or more member in the workspace.

Steps:

1. sign in to staging.new.expensify.com with an account that fulfils the pre-requisite above
2. Navigate to Workspace > Workspace settings > Workflows
3. Enable approvals (If not enabled)
4. Click on add approvals
5. Select 1 or 2 members in the "Expenses from" RHP and click Next
6. Add approver and finish the flow
7. Click on add approvals again

Expected Result:

Members from step 5 should not be displayed as a workflow already exists for the members.

Actual Result:

Members with an existing approvals flow are displayed in the "Expenses from" RHP when adding a new approval.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @eVoloshchak

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022029848713770960608
• Upwork Job ID: 2029848713770960608
• Last Price Increase: 2026-03-06

[melvin-bot]

Triggered auto assignment to @brianlee-expensify (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.

[MobileMage]

Proposal

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

When a user clicks "Add approval" a second time, the "Expenses from" picker shows members who already belong to an existing custom approval workflow, even though those members should not be selectable since they are already assigned.

What is the root cause of that problem?

In convertPolicyEmployeesToApprovalWorkflows, every non-deleted employee is unconditionally added to availableMembers, including those who already have a submitsTo pointing to an existing workflow. This availableMembers list is then passed directly into the new APPROVAL_WORKFLOW Onyx entry when "Add approval" is tapped:

App/src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx

Lines 158 to 163 in 04b333d

	const addApprovalAction = useCallback(() => {
	setApprovalWorkflow({
	...INITIAL_APPROVAL_WORKFLOW,
	availableMembers,
	usedApproverEmails,
	});

Members already assigned to an existing workflow have a valid submitsTo set, so they should be excluded from availableMembers for a new workflow. The current code never filters them out — it only excludes members with a pending DELETE action.

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

In convertPolicyEmployeesToApprovalWorkflows inside WorkflowUtils.ts, skip pushing a member onto availableMembers when that member already has a non-default submitsTo (i.e. they belong to an existing custom workflow). Members whose submitsTo resolves to the default approver are still available because the default workflow is the catch-all.

App/src/libs/WorkflowUtils.ts

Lines 130 to 140 in 04b333d

	for (const employee of Object.values(employees)) {
	const {email, submitsTo, pendingAction} = employee;
	if (!email) {
	continue;
	}
	const member = buildMemberFromEmployee(employee, personalDetailsByEmail, email);
	if (pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	availableMembers.push(member);
	}

     for (const employee of Object.values(employees)) {
         const {email, submitsTo, pendingAction} = employee;
         if (!email) {
             continue;
         }

         const member = buildMemberFromEmployee(employee, personalDetailsByEmail, email);

-        if (pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
+        const isAlreadyInCustomWorkflow = !!submitsTo && submitsTo !== defaultApprover && !!employees[submitsTo];
+        if (pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE && !isAlreadyInCustomWorkflow) {
             availableMembers.push(member);
         }

This ensures that when the admin opens the "Expenses from" picker for a brand-new workflow, members already assigned to a custom workflow are not listed. Members who have no submitsTo, or whose submitsTo is the default approver, remain available. The existing edit flow is unaffected because during edit the workflow's own members are loaded from approvalWorkflow.members (already-selected) rather than from availableMembers.

What alternative solutions did you explore? (Optional)

N/A

[MelvinBot]

Proposal

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

When adding a new approval workflow (Workspace > Workflows > Add approval), the "Expenses from" member picker shows all workspace members, including those who are already assigned to an existing non-default approval workflow. Members with an existing workflow should be excluded from this picker so they aren't accidentally reassigned.

What is the root cause of that problem?

The availableMembers list is built in convertPolicyEmployeesToApprovalWorkflows() at src/libs/WorkflowUtils.ts:128-140. It includes every employee who has an email and is not pending deletion — there is no check on the submitsTo field to exclude members already assigned to a non-default approval workflow.

This unfiltered list is then passed directly to the Onyx store when the user clicks "Add approval" in WorkspaceWorkflowsPage.tsx:158-163, and the "Expenses from" page at WorkspaceWorkflowsApprovalsExpensesFromPage.tsx:100-102 only filters for self-approval prevention and already-selected members — it never checks whether a member belongs to another workflow.

A comment at WorkflowUtils.ts:199-201 explains this was intentional for the edit flow (so admins can fix orphaned approval chains), but the same unfiltered list is also used for the create flow where it causes this bug.

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

In the addApprovalAction callback in WorkspaceWorkflowsPage.tsx (line 158), filter availableMembers before passing it to setApprovalWorkflow(). Exclude members who already appear as a member of any non-default workflow in approvalWorkflows (which is already available in scope at line 97). Specifically:

1. Collect the emails of all members who belong to a non-default approvalWorkflow (i.e., workflows where isDefault is false).
2. Filter availableMembers to exclude those emails before passing the list to setApprovalWorkflow().

This keeps the edit flow unchanged (it still gets the full unfiltered list via mergeWorkflowMembersWithAvailableMembers in WorkspaceWorkflowsApprovalsEditPage.tsx), preserving the ability to fix orphaned chains. Only the create flow gets the filtered list.

What alternative solutions did you explore? (Optional)

• Filtering in convertPolicyEmployeesToApprovalWorkflows: This would also affect the edit flow, breaking the orphaned-chain fix referenced in issue #598876.
• Filtering in WorkspaceWorkflowsApprovalsExpensesFromPage.tsx: This page doesn't have access to the list of existing workflows without additional Onyx data, making WorkspaceWorkflowsPage.tsx the cleaner location since both approvalWorkflows and availableMembers are already in scope.

---

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.

[melvin-bot]

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

[melvin-bot]

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

[d-wwei]

I’m looking into this and plan to submit a PR shortly.

Initial read:

• The issue appears to be in the member filtering for the "Expenses from" flow when creating a new approval workflow.
• I’ll verify the exact workflow-selection behavior and follow up if I find any blocker or overlap with existing work.

[melvin-bot]

📣 @d-wwei! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>