[Due for payment 2026-05-12] [$250] Fix freeze when opening "Add approval workflow" on workspaces with many members

[MelvinBot]

This issue tracks the fix for a performance freeze when opening "Add approval workflow" on workspaces with many members.

Problem: getMemberAccountIDsForWorkspace(policy?.employeeList) was being called inside two separate .map() callbacks, creating O(N²) work. On workspaces with a few hundred members, pressing "Add approval workflow" froze the app for roughly a minute.

Fix PR: #89268

The fix hoists the call to the component body so it runs once per render instead of once per member.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022049848884144386257
• Upwork Job ID: 2049848884144386257
• Last Price Increase: 2026-04-30

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

Problem

Opening "Add approval workflow" on workspaces with many members freezes the app because getMemberAccountIDsForWorkspace() is called inside .map() callbacks, creating O(N²) work.

Solution

Hoist getMemberAccountIDsForWorkspace(policy?.employeeList) out of the .map() callbacks so it runs once per render instead of once per member.

Primary fix — WorkspaceWorkflowsApprovalsExpensesFromPage.tsx:

• Line 78: Called inside useEffect's .map() — hoist above the .map()
• Line 106: Called inside an un-memoized .map() on every render — hoist to the component body. This is the worst offender since it re-runs on every render

Additional instance — WorkspaceWorkflowsApprovalsApproverPage.tsx:97: Same pattern inside a useMemo's .map(). Mitigated by memoization but still O(N²) when deps change.

Investigation details

Why it's O(N²): getMemberAccountIDsForWorkspace iterates all E employees via Object.keys(members). When called inside .map() over N members, total work is O(N×E). Since N ≈ E for workspace members, this is effectively O(N²). For a 1,000-member workspace, that's ~1,000,000 iterations per render.

Correct pattern already exists in the codebase:

• WorkspaceWorkflowsApprovalsOverLimitApproverPage.tsx:55 — hoisted before .map()
• WorkspaceWorkflowsPayerPage.tsx:87 — hoisted at component body level

Alternative explanations considered: Could this be a React re-render issue rather than algorithmic? No — even a single render is O(N²), and the line 106 block isn't memoized, compounding the problem on re-renders.

---

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]

Current assignee @abzokhattab is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

Pressing “Add approval workflow” navigates from the Workflows page to WORKSPACE_WORKFLOWS_APPROVALS_EXPENSES_FROM.

On that page, getMemberAccountIDsForWorkspace(policy?.employeeList) is called inside two per-member callbacks:

• Inside the selected-members sync effect:

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

  Line 78 in 7014cd9

  const policyMemberEmailsToAccountIDs = getMemberAccountIDsForWorkspace(policy?.employeeList);

• Inside the available-members render map:

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

  Line 106 in 7014cd9

  const policyMemberEmailsToAccountIDs = getMemberAccountIDsForWorkspace(policy?.employeeList);

getMemberAccountIDsForWorkspace() itself loops through the full workspace employee list:

App/src/libs/PolicyUtils.ts

Lines 517 to 540 in 7014cd9

	function getMemberAccountIDsForWorkspace(employeeList: PolicyEmployeeList | undefined, includeMemberWithErrors = false, includeMemberWithPendingDelete = true): MemberEmailsToAccountIDs {
	const members = employeeList ?? {};
	const memberEmailsToAccountIDs: MemberEmailsToAccountIDs = {};
	for (const email of Object.keys(members)) {
	if (!includeMemberWithErrors) {
	const member = members?.[email];
	if (Object.keys(member?.errors ?? {})?.length > 0) {
	continue;
	}
	}
	if (!includeMemberWithPendingDelete) {
	const member = members?.[email];
	if (member.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	continue;
	}
	}
	const personalDetail = getPersonalDetailByEmail(email);
	if (!personalDetail?.login) {
	continue;
	}
	memberEmailsToAccountIDs[email] = Number(personalDetail.accountID);
	}
	return memberEmailsToAccountIDs;
	}

That makes the screen do O(N²) work for large workspaces: for each visible member, it rebuilds the full email-to-accountID map. The same pattern also exists on the next approver-selection step:

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

Line 97 in 7014cd9

const policyMemberEmailsToAccountIDs = getMemberAccountIDsForWorkspace(employeeList);

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

Compute the workspace member email-to-accountID map once at the nearest stable scope before each member loop, then reuse it inside the callback.

Required changes:

• In WorkspaceWorkflowsApprovalsExpensesFromPage.tsx, compute policyMemberEmailsToAccountIDs once inside the useEffect, before approvalWorkflow.members.map(...).
• In the same file, compute policyMemberEmailsToAccountIDs once before approvalWorkflow.availableMembers.map(...).
• In WorkspaceWorkflowsApprovalsApproverPage.tsx, compute policyMemberEmailsToAccountIDs once inside the existing useMemo, before Object.values(employeeList).map(...).

Tests that should be added:

• A focused render test for WorkspaceWorkflowsApprovalsExpensesFromPage with many availableMembers, verifying the page builds the list without calling getMemberAccountIDsForWorkspace() once per member.
• A similar test for WorkspaceWorkflowsApprovalsApproverPage, verifying the approver options path reuses one computed member map.
• Manual validation on web with a large workspace: open Workflows, enable Approvals, press “Add approval workflow”, verify the member picker opens without freezing, then select members and continue to the approver picker.

What alternative solutions did you explore? (Optional)

[github-actions]

⚠️ @nabi-ebrahimi Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).