[Due for payment 2026-04-30] Assigned SRAM Displayed in Workflows Table

[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: @muttmuure
Slack conversation (hyperlinked to channel name): #Migrate

Action Performed:

1. Navigate to Workspace → Workflows.
2. Click Add Approval Workflow
3. See SRAM displayed in menu

Expected Result:

Only customer-relevant roles and users should appear in the workflows table.
Internal Expensify roles (e.g., SRAM) should be hidden from customer-facing views.

Actual Result:

The customer’s assigned SRAM appears in the workflows table.

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 is in slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @stephanieelliott (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]

🚨 Edited by proposal-police: This proposal was edited at 2026-01-28 15:33:04 UTC.

Proposal

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

When a customer opens their Workspace Workflows page, they're seeing their assigned SRAM (Strategic Relationship Account Manager) listed in the approval workflows table. These are internal Expensify employees—people with @expensify.com or @team.expensify.com email addresses—who help customers get set up but shouldn't be visible in customer-facing views. Their appearance creates confusion, as customers wonder why random people have been added to their workspace.

What is the root cause of that problem?

The root cause lives in the convertPolicyEmployeesToApprovalWorkflows function within src/libs/WorkflowUtils.ts. This function iterates over all employees in policy.employeeList and builds the approval workflow data displayed in the UI—but it does so without any consideration for whether employees or approvers are internal Expensify team members.

The workflow table in ApprovalWorkflowSection.tsx displays two distinct pieces of information: the members (employees whose expenses flow through the workflow) and the approvers (the chain of people who approve those expenses). An SRAM could appear in either section depending on how they're configured in the workspace.

The most likely scenario is that the SRAM is appearing as an approver. When employees are configured to submit expenses to an SRAM (i.e., the SRAM's email is set as someone's submitsTo value), the function calls calculateApprovers starting from the SRAM's email, which places them prominently in the approvers list:

App/src/libs/WorkflowUtils.ts

Lines 132 to 138 in eb7e7d8

	if (!approvalWorkflows[submitsTo]) {
	const approvers = calculateApprovers({employees, firstEmail: submitsTo, personalDetailsByEmail});
	if (submitsTo !== firstApprover) {
	for (const approver of approvers) {
	usedApproverEmails.add(approver.email);
	}
	}

The codebase already handles this exact filtering scenario in WorkspaceMembersPage, where Expensify team members are hidden from customers who aren't themselves Expensify employees:

App/src/pages/workspace/WorkspaceMembersPage.tsx

Lines 392 to 399 in eb7e7d8

	// 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 comment there explains the reasoning clearly: guides need access to policies to help set them up, but customers get confused when they see these random people appear. The Workflows page needs the same treatment, but the filtering must happen at the data transformation layer in WorkflowUtils to cover both members and approvers.

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

The fix requires filtering Expensify team members from both the members list and the approvers chain. This involves several coordinated changes to src/libs/WorkflowUtils.ts.

First, we need to import the isExpensifyTeam helper and extend the PolicyConversionParams type to accept the current user's login:

 import {isBankAccountPartiallySetup} from './BankAccountUtils';
 import {convertToDisplayString} from './CurrencyUtils';
-import {getDefaultApprover} from './PolicyUtils';
+import {getDefaultApprover, isExpensifyTeam} from './PolicyUtils';

 // ... existing code ...

 type PolicyConversionParams = {
     /** Policy data containing employees and approver information */
     policy: OnyxEntry<Policy>;

     /** Personal details of the employees */
     personalDetails: PersonalDetailsList;

     /** Email of the first approver in current edited workflow */
     firstApprover?: string;

     /** Locale comparison function */
     localeCompare: LocaleContextProps['localeCompare'];
+
+    /** Current user's login email, used to determine if Expensify team members should be shown */
+    currentUserLogin?: string;
 };

Second, we add a helper function that finds the first non-Expensify approver in an approval chain. This handles the case where an employee submits to an SRAM who then forwards to a real manager—we want to skip the SRAM and show the workflow as if the employee submits directly to the manager:

+/**
+ * Find the first non-Expensify team member in the approval chain.
+ * Used to skip internal Expensify approvers when displaying workflows to customers.
+ * Returns undefined if no non-Expensify approver is found in the chain.
+ */
+function findFirstNonExpensifyApprover(
+    employees: PolicyEmployeeList,
+    startEmail: string,
+    policyOwner: string | undefined,
+    currentUserLogin: string | undefined,
+): string | undefined {
+    // Don't filter if the viewer or owner is an Expensify team member
+    if (!policyOwner || !currentUserLogin || isExpensifyTeam(policyOwner) || isExpensifyTeam(currentUserLogin)) {
+        return startEmail;
+    }
+
+    let email: string | undefined = startEmail;
+    const visited = new Set<string>();
+
+    while (email && !visited.has(email)) {
+        if (!isExpensifyTeam(email)) {
+            return email;
+        }
+        visited.add(email);
+        email = employees[email]?.forwardsTo;
+    }
+
+    return undefined;
+}

Third, we modify convertPolicyEmployeesToApprovalWorkflows to use this filtering logic. The key insight is that we need to filter at two levels: skip Expensify employees from appearing as members, and redirect workflows that submit to Expensify approvers to the next non-Expensify person in the chain:

-function convertPolicyEmployeesToApprovalWorkflows({policy, personalDetails, firstApprover, localeCompare}: PolicyConversionParams): PolicyConversionResult {
+function convertPolicyEmployeesToApprovalWorkflows({policy, personalDetails, firstApprover, localeCompare, currentUserLogin}: PolicyConversionParams): PolicyConversionResult {
     const employees = policy?.employeeList ?? {};
     const defaultApprover = getDefaultApprover(policy);
     const approvalWorkflows: Record<string, ApprovalWorkflow> = {};
+    const policyOwner = policy?.owner;
+
+    // Determine if we should filter Expensify team members (only for non-Expensify customers)
+    const shouldFilterExpensifyTeam = policyOwner && currentUserLogin && 
+        !isExpensifyTeam(policyOwner) && !isExpensifyTeam(currentUserLogin);

     // Keep track of used approver emails to display hints in the UI
     const usedApproverEmails = new Set<string>();
     const personalDetailsByEmail = lodashMapKeys(personalDetails, (value, key) => value?.login ?? key);

     // Add each employee to the appropriate workflow
     for (const employee of Object.values(employees)) {
         const {email, submitsTo, pendingAction} = employee;
         if (!email || !submitsTo || !employees[submitsTo]) {
             continue;
         }

+        // Filter out Expensify team members from appearing as workflow members
+        if (shouldFilterExpensifyTeam && isExpensifyTeam(email)) {
+            continue;
+        }
+
+        // If submitsTo is an Expensify team member, find the first non-Expensify approver in the chain
+        const effectiveSubmitsTo = shouldFilterExpensifyTeam
+            ? findFirstNonExpensifyApprover(employees, submitsTo, policyOwner, currentUserLogin)
+            : submitsTo;
+
+        // Skip if no valid non-Expensify approver exists in the chain
+        if (!effectiveSubmitsTo || !employees[effectiveSubmitsTo]) {
+            continue;
+        }

         const member: Member = {
             email,
             avatar: personalDetailsByEmail[email]?.avatar,
             displayName: personalDetailsByEmail[email]?.displayName ?? email,
             pendingFields: employee.pendingFields,
         };

-        if (!approvalWorkflows[submitsTo]) {
-            const approvers = calculateApprovers({employees, firstEmail: submitsTo, personalDetailsByEmail});
-            if (submitsTo !== firstApprover) {
+        if (!approvalWorkflows[effectiveSubmitsTo]) {
+            const approvers = calculateApprovers({employees, firstEmail: effectiveSubmitsTo, personalDetailsByEmail});
+            if (effectiveSubmitsTo !== firstApprover) {
                 for (const approver of approvers) {
                     usedApproverEmails.add(approver.email);
                 }
             }

             // ... rest of workflow creation logic, replacing submitsTo with effectiveSubmitsTo ...
         }

-        approvalWorkflows[submitsTo].members.push(member);
+        approvalWorkflows[effectiveSubmitsTo].members.push(member);

Finally, we need to pass currentUserLogin when calling this function. In WorkspaceWorkflowsPage.tsx, we add access to the session and pass the email:

+const [session] = useOnyx(ONYXKEYS.SESSION, {canBeMissing: false});

 const {approvalWorkflows, availableMembers, usedApproverEmails} = useMemo(
     () =>
         convertPolicyEmployeesToApprovalWorkflows({
             policy,
             personalDetails: personalDetails ?? {},
             localeCompare,
+            currentUserLogin: session?.email,
         }),
-    [personalDetails, policy, localeCompare],
+    [personalDetails, policy, localeCompare, session?.email],
 );

The same change applies to the other call sites in WorkspaceMembersPage.tsx (which already has currentUserPersonalDetails.login available) and WorkspaceWorkflowsApprovalsEditPage.tsx.

This approach handles all the edge cases:

Scenario	Behavior
SRAM appears as a member	Filtered out, won't appear in "Expenses from" list
SRAM is the first approver	Workflow redirects to next non-Expensify approver
SRAM is in middle of approval chain	Chain starts from first non-Expensify approver
Entire approval chain is Expensify team	Employee hidden from workflows (graceful degradation)
Policy owned by Expensify	No filtering applied (internal use case)
Current user is Expensify team	No filtering applied (guides can see everything)

What alternative solutions did you explore? (Optional)

[github-actions]

⚠️ @yatin-italy Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[eh2077]

I can take over as C+

[dominictb]

@stephanieelliott I'm off-boarding so please reassign this to whoever volunteered first. Seems like it's @eh2077. Thank you.