[Due for payment 2026-10-23] [$175] Workflows - Members submitting to a removed approver are hidden and keep the workspace on Advanced Approval

@mallenexpensify

Problem

A member's submitsTo can point to someone who is no longer on the workspace. When that happens, NewDot hides the member on the Workflows page. If the admin then deletes every workflow, the workspace stays on Advanced Approval and the member's reports still go to the removed approver. The member can't submit, and the admin can't fix it in NewDot. A customer hit this and Support had to clean up the data manually.

Steps to reproduce

Precondition: a member's submitsTo is an email that isn't in employeeList (see "How orphans are created" below).

Go to Workspace > Workflows.
Delete all non-default workflows.

Expected: approval mode resets to Basic, and every member submits to the default approver.
Actual: the member isn't shown in any workflow. Approval mode stays Advanced. Their reports go to the removed approver.

Root cause

Hidden member: convertPolicyEmployeesToApprovalWorkflows in WorkflowUtils.ts skips any employee whose submitsTo isn't in employeeList.
Stuck on Advanced: removeApprovalWorkflow and updateApprovalWorkflow in Workflow.ts check for multiple workflows across the full employee list. That list includes the hidden member, so one hidden member keeps approvalMode on ADVANCED.
How orphans are created: removeUsers in WorkspaceMembersPage.tsx reassigns the removed approver's submitters, but it skips this step when personalDetails[accountID] has no login. removeMembers still runs, so the member is removed and submitsTo still points at them. WorkspaceMemberDetailsPage.tsx has the same check. The members table already uses a fallback identity when personal details are missing, but the removal code doesn't.

Proposed solution

Always reassign submitters when an approver is removed. In both member pages, build removedApprover as personalDetails?.[accountID] ?? {accountID, login}, using the employeeList key as the login. Fall back to policy.owner when ownerDetails.login is empty.
Show hidden members. In convertPolicyEmployeesToApprovalWorkflows, put members whose submitsTo isn't a current, non-deleted employee in the default workflow instead of dropping them.
Fix hidden members whenever a workflow is saved. In removeApprovalWorkflow and updateApprovalWorkflow, add those members to updatedEmployees with submitsTo set to the default approver. Do this before checking for multiple workflows. The fix then reaches the backend, and approval mode can reset to Basic.
Tests: cover a submitsTo that points at a non-member in WorkflowUtils and the Workflow actions. Also test removing an approver who has no personal details loaded.

Related: Auto - Workspace - Approver is not replaced by owner after default approver leaves, [Exploratory] Control Workspace - Both approvers remove in OD still remain in Workflows ND

Reported in Slack.

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~022107974207489229976
Upwork Job ID: 2107974207489229976
Last Price Increase: 2026-10-07

@ikevin127

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

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

@MelvinBot

@MelvinBot

Show hidden members. In convertPolicyEmployeesToApprovalWorkflows, put members whose submitsTo isn't a current, non-deleted employee in the default workflow instead of dropping them.

I'm not really sure I'm feeling this part of your proposal. If the member is submitting to someone not on the workspace through some crusty flow that let them get in that spot, it's misleading to display them in the default workflow when in fact that's not their workflow and the source of what's broken.

If anything, we should show who they are actually configured to submit to, and highlight that with an error to fix or something. @JmillsExpensify curious for your take here btw. This customer got into a real weird spot with submitting to people outside of the workspace, and because those broken workflows weren't shown in NewDot - they had no means to fix it in the product.

Proposal

What is the root cause of that problem?

I confirmed all three causes described in the issue body in the App code.

How orphans are created. Both member pages look up the removed approver in personalDetails. If that entry has no login, or the owner's entry has no login, they skip the step that reassigns submitters. They still call removeMembers, and that call sends only {emailList, policyID}. So other members keep submitsTo pointing at the removed email. This became reachable when Show workspace members with missing personal details instead of dropping them made these members selectable in the table.
Hidden member. convertPolicyEmployeesToApprovalWorkflows skips any member whose submitsTo isn't in employeeList. The default workflow still says "Everyone", so the admin has no way to see or fix these members.
Stuck on Advanced. removeApprovalWorkflow and updateApprovalWorkflow keep ADVANCED when any employee's submitsTo is not the default approver. The hidden member matches, but it is never part of the request, so its submitsTo is never corrected.

Code references

Skip on removal: WorkspaceMembersPage.tsx:240-270, WorkspaceMemberDetailsPage.tsx:234-242. The email-to-accountID map skips members with no personal-details login (PolicyUtils.ts:909-912), so removedApprover is always undefined for them.
updateWorkflowDataOnApproverRemoval only uses the email strings removedApprover.login and ownerDetails.login (WorkflowUtils.ts:458-463). The employeeList key and policy.owner are enough.
removeMembers never rewrites other members' submitsTo/forwardsTo (Member.ts:412-439).
Hidden member: WorkflowUtils.ts:205-207. The beta rules-based builder does the same at WorkflowUtils.ts:1627-1631.
Mode check: Workflow.ts:172-180 and Workflow.ts:236-246. The request only includes the edited workflow's members and approvers.
The submit path already sends orphans to the default approver (PolicyUtils.ts:2177, from Fix report submission failure when submitsTo points to a removed policy member). The Workflows page should match that rule.

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

Always reassign on approver removal. In both member pages, use the employeeList email (login / memberLogin) as removedApprover.login instead of requiring a personal-details entry. Use ownerDetails.login ?? policy.owner for the owner. On the details page, also guard on !memberLogin.
Show orphaned members. In convertPolicyEmployeesToApprovalWorkflows, treat a submitsTo that isn't in employeeList as the default approver, so the member joins the default workflow. Keep the HR manager-mode exception (hrAdvancedModeFinalApproverEmail). Apply the same rule to the beta rules-based builder for members not covered by a rule.
Fix orphans on save. Add a small helper that removeApprovalWorkflow and updateApprovalWorkflow both call before the multiple-workflow check. It adds each orphaned member to updatedEmployees with submitsTo set to the default approver. It should:
- skip policies where isAnyHRReadOnlyWorkflowMode(policy) is true;
- skip members that are themselves pending DELETE;
- count a member as orphaned only when its approver is missing from employeeList, not when the approver is pending DELETE (those approvers are shown struck through on purpose).
Also clear pendingFields in removeApprovalWorkflow success data.
Tests.
- Update WorkflowUtilsTest "Should not include users that submit to non-employee user". It should now expect the member in the default workflow.
- Keep the HR manager-mode non-member test unchanged.
- Add WorkflowTest cases: an orphan ends up in BASIC mode with submitsTo set to the default approver; HR mode leaves orphans alone.
- Add a WorkspaceMembersTest case: removing an approver with no personal details reassigns their submitters.

Notes and risks

I couldn't verify the backend side from App. The client only decides the optimistic approvalMode. Before merging, an internal engineer should confirm two things: the server resets the mode the same way, and it accepts an explicit submitsTo for employees outside the edited workflow.
After step 2, both member pages call updateApprovalWorkflow for every workflow. So removing any approver will also fix existing orphans. That is likely what we want, but it needs a test.
Open PR Skip members pending deletion when building approval workflows rewrites the same loop, so expect merge conflicts.
The same bug has a deeper form: a default approver's forwardsTo can point at a non-member. That can stay out of scope.

What alternative solutions did you explore? (Optional)

Only fix step 1. That stops new orphans, but workspaces that already have them stay stuck.

Possibly related: Auto - Workspace - Approver is not replaced by owner after default approver leaves, [Exploratory] Control Workspace - Both approvers remove in OD still remain in Workflows ND, Broken workflow disappears

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/102234#issuecomment-5823680566) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

Agreed. Putting these members in the default workflow hides the real problem. Here's the revised proposal: show each broken workflow with its real approver, flag it with an error, and let the admin fix it with the existing edit and delete flows. This also replaces my earlier step 3. We shouldn't quietly rewrite submitsTo behind the admin's back.

Revised changes

Prevent new orphans (unchanged). When an approver is removed, both member pages always reassign that approver's submitters. They use the employeeList email and policy.owner as fallbacks.
Show the broken workflow as it is configured. In convertPolicyEmployeesToApprovalWorkflows, stop skipping members whose submitsTo isn't on the workspace. Group them under that approver, as today's fallback approver builder already does. Add an isNotWorkspaceMember flag to the approver. Keep the HR-mode exception.
Show an error.
- The workflow card shows an error row under the flagged approver, for example: "This approver is no longer a workspace member. Choose a new approver or move these members to another workflow."
- Workspace > Workflows gets a red dot in Advanced mode.
- The editor blocks Save until the admin replaces the approver.
Let the admin fix it with existing flows.
- Change approver: the picker already lists only members. The update then rewrites each member's submitsTo.
- Delete the workflow: members fall back to the default approver. When no custom workflows remain, the workspace drops to Basic on its own.
Payload guard (required). In convertApprovalWorkflowToPolicyEmployees, skip flagged approvers. Otherwise every save, delete, and approver removal on the Members pages would send a fake employee entry for the non-member email.

Code references and risks

Skip today: WorkflowUtils.ts:205-207. Existing fallback approver builder: WorkflowUtils.ts:213-224. Beta builder: WorkflowUtils.ts:1627-1631.
Card error row: ApprovalWorkflowSection.tsx:166-171. Editor errors follow the circular-reference pattern: Workflow.ts:575-594 and Workflow.ts:663-681.
Red dot on Workflows: getWorkspaceMenuItems.ts:332-342 only checks errorFields.reimburser today.
Payload guard: WorkflowUtils.ts:381-410. The Members pages call updateApprovalWorkflow for every workflow (WorkspaceMembersPage.tsx:252-265).
Risks:
- The client already sends reports to the default approver when the configured approver isn't a member (PolicyUtils.ts:2176-2179). If the backend does the same, the error copy should say where reports actually go. I couldn't verify backend routing from App.
- A removed Expensify team approver could leave a workflow with zero approvers after the Expensify-team filter. That case needs a guard.
- New copy is needed in all locale files.
- This test needs updating: WorkflowUtilsTest.ts:578-607.

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/102234#issuecomment-5823831441) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

@trjExpensify

Detailed proposals review

Proposal 1 (MelvinBot)

Root cause ✅ All three causes check out against current main. None of the files it references have changed since the commit it linked.

removeUsers / removeUser skip updateWorkflowDataOnApproverRemoval when personalDetails[accountID]?.login is missing, but still call removeMembers. For these members accountID is always undefined, because getMemberAccountIDsForWorkspace skips anyone without a personal-details login (PolicyUtils.ts:909-912). So the step that reassigns submitters can never run for them.
convertPolicyEmployeesToApprovalWorkflows drops members whose submitsTo isn't in employeeList (WorkflowUtils.ts:205).
The hasMoreThanOneWorkflow / hasMultipleWorkflows checks in Workflow.ts scan the whole employee list, so a hidden orphan keeps the workspace on ADVANCED.

Solution ✅ The revised version follows trjExpensify's direction: show the workflow as it is really configured, flag it, and let the admin fix it with the existing edit and delete flows, without rewriting submitsTo behind their back. I traced the delete path: once the orphan workflow is visible and deleted, its members go to submitsTo: '', the mode check finds no other workflows, and the workspace drops to BASIC. So the "stuck on Advanced" symptom is fixed without special handling. The payload guard in step 5 is a good catch. Without it, the approver loop in convertApprovalWorkflowToPolicyEmployees sees previousEmployeeList[nonMember] as undefined, marks forwardsTo as changed, and sends a fake employee entry. That would happen on every save and on every approver removal from the Members pages.

Things to address before or during the PR:

🟠 Zero-approver workflow is listed as a risk but has no fix. findFirstNonExpensifyApprover only runs when employees[submitsTo] exists. So if the orphaned submitsTo is an Expensify team email and shouldFilterOutExpensifyTeam is true, the filter at WorkflowUtils.ts:226 leaves approvers empty. That workflow then renders with no approver, gets silently dropped by updateWorkflowDataOnApproverRemoval, and throws in convertApprovalWorkflowToPolicyEmployees (WorkflowUtils.ts:376). I'd suggest not filtering out the flagged approver, so the admin can still see and fix it.

🟡 Beta rules-based builder was left out of the revised step 2. The original proposal applied the same change at WorkflowUtils.ts:1628, but the revised one only links to it. If the beta is on, orphans stay hidden there, and so does the new error. Both builders need the same change.

🟡 Step 1: narrow the helper params instead of building a fake PersonalDetails. updateWorkflowDataOnApproverRemoval only reads removedApprover.login, but the param is typed as PersonalDetails, which requires accountID. accountID is undefined for exactly these members, so building {accountID, login} means filling in a placeholder ID. Changing the helper to take removedApproverEmail: string, with ownerDetails.login ?? policy.owner for the owner, is cleaner.

🟡 Keep the orphan check in one pure helper. The approver flag, the Workflows menu red dot (getWorkspaceMenuItems.ts:337), and the editor Save block all need the same check: submitsTo isn't in employeeList and this isn't HR advanced mode. Put it in PolicyUtils once and reuse it. Also consider using it in getPolicyBrickRoadIndicatorStatus. Otherwise the admin only sees the red dot after opening the workspace, and the workspace list shows nothing.

🟡 The error text depends on backend routing that hasn't been confirmed. The issue says reports go to the removed approver, but getSubmitToEmail in the client falls back to the default approver (PolicyUtils.ts:2176-2179). The error text has to match what the backend really does. That needs an internal engineer to confirm, along with the product input trjExpensify asked JmillsExpensify for. The new strings also need to go into every locale file.

🟢 Tests. Update Should not include users that submit to non-employee user (WorkflowUtilsTest.ts:337) and Should include members with orphaned submitsTo in availableMembers (WorkflowUtilsTest.ts:578). Add WorkflowTest cases for the delete flow dropping to BASIC and for the payload guard not sending the non-member. Add a Members page case for removing an approver with no personal details.

@MelvinBot's proposal + revision LGTM, see Detailed proposals review above for details on why.

It's the only proposal, the root cause is correct and I checked it against the code, and the revised approach matches the direction trjExpensify gave. Step 1 (stop new orphans from being created) is independent and could ship first.

Steps 2 to 5 add new UI: an error row, a red dot, and a blocked Save. Before running the implement command, I'd get a quick 👍 on those from @trjExpensify and @JmillsExpensify, then fold in the 🟠 and 🟡 notes above.

🎀👀🎀 C+ reviewed

@tylerkaraszewski

Triggered auto assignment to @tylerkaraszewski, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

@ikevin127

@ikevin127 This is regarding the Regression test proposal
Test: 1, Step 5 fails. New workflow created (Approver updated and the workflow remains), Can you please check the video?

Recording.3724.mp4

@m-natarajan

@m-natarajan thanks for the video! Could you check if this account has the multipleApprovers beta enabled ? With that beta, workflows are saved as approval rules, and removing an approver from the Members page only updates the legacy workflow data, so the rule-based Asdf → App Test workflow stays as its own card.

That flow wasn't changed by #102815. Test 1 assumes the beta is OFF, so I updated the regression test precondition, and we can open a separate issue for member removal not cleaning up rule-based workflows.

Why it probably passed earlier during post-merge QA:

The rules path landed on Sep 9, before Show workflows whose approver left the workspace, and stop creating them #102815 merged on Oct 9.
The removal logic (updateWorkflowDataOnApproverRemoval and removeUsers) is identical on current main. Skip members pending deletion when building approval workflows #99988, Skip null employeeList entries in the Workspaces tab red-dot check #103811 and Guard against null workspace member entries in employeeList #103793 only touch pending-delete and null-entry handling. Offer the workspace members bulk actions in the floating bar #102380 (bulk action bar) merged after QA's comment.
So it most likely comes down to the account configuration: post-merge QA ran without the multipleApprovers beta, and this regression test run had it on. I can't see QA's active betas, so they should be confirmed.

This is an existing gap, not a regression from #102815: approver removal from the Members page never handled rule-based workflows.

@mallenexpensify

Triggered auto assignment to @mallenexpensify (Awaiting Payment)

@ikevin127

Payment Summary

Resolving PRs:

Show workflows whose approver left the workspace, and stop creating them #102815
Skip null employeeList entries in the Workspaces tab red-dot check #103811
Reviewer: @ikevin127 owed $175 via NewDot

BugZero Checklist (@mallenexpensify)

I have confirmed assignees, roles, and Upwork contracts look correct
I have paid out Upwork contracts / manual NewDot requests
[BugZero Assignee] I have created a GH issue for creating/updating the regression test once above steps have been agreed upon

@tylerkaraszewski

⌛ Still pending a response from @tylerkaraszewski on the payment increase request with this addition regarding regression talk.

@ikevin127

Payment Summary

Contributor+: @ikevin127 due $175 via NewDot

Paying $175 cuz that's the standard job price, not taking into account regression because of 'should have caught' post above as well as the regression PR was fixed by @ikevin127 and didn't involve additional payments

Note

I messaged Tyler on Slack sometime yesterday (before Matt's payment summary landed on $175) regarding the price increase request - to offer his take when he gets a chance.

In the meantime I went with the $175 summary on thr ND request, but in case Tyler will comment - I wanted to mention this so it doesn't look like I overwritten Matt's decision on the price.

I think we're settled on $175.

@ikevin127

Approved $175 to @ikevin127

Navigation Menu

Repository navigation

[Due for payment 2026-10-23] [$175] Workflows - Members submitting to a removed approver are hidden and keep the workspace on Advanced Approval #102234

Problem

Steps to reproduce

Root cause

Proposed solution

Proposal

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

Revised changes

Proposal 1 (MelvinBot)

38 remaining items

Payment Summary

BugZero Checklist (@mallenexpensify)

Payment Summary

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Due for payment 2026-10-23] [$175] Workflows - Members submitting to a removed approver are hidden and keep the workspace on Advanced Approval #102234

Description

Problem

Steps to reproduce

Root cause

Proposed solution

Activity

melvin-bot commented on Sep 24, 2026

melvin-bot commented on Sep 24, 2026

trjExpensify commented on Sep 24, 2026

MelvinBot commented on Sep 24, 2026

Proposal

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

MelvinBot commented on Sep 24, 2026

Revised changes

ikevin127 commented on Sep 25, 2026

Proposal 1 (MelvinBot)

melvin-bot commented on Sep 25, 2026

38 remaining items

m-natarajan commented on Oct 21, 2026

ikevin127 commented on Oct 21, 2026

melvin-bot commented on Oct 22, 2026

melvin-bot commented on Oct 22, 2026

Payment Summary

BugZero Checklist (@mallenexpensify)

ikevin127 commented on Oct 23, 2026

mallenexpensify commented on Oct 26, 2026

Payment Summary

ikevin127 commented on Oct 26, 2026

tylerkaraszewski commented on Oct 26, 2026

quinthar commented on Oct 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions