[$250] Missing Approver field on confirm page after deleting workflow and inviting member

[nlemma]

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: 9.3.26-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #82683
Email or phone of affected tester (no customers): sdjsiodjsnodjsonjsio@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Workspace is on Control plan.
• User has invited member B to the workspace.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Workflows.
3. Open the default workflow.
4. Edit the existing workflow and make member B be the second approver.
5. Go to workspace settings > Members.
6. Enter user C email and select the user > Next.
7. On confirm page, click Approver and select User B.
8. Click Invite member.
9. Go to workspace settings > Workflows.
10. Delete the second workflow.
11. Go to workspace settings > Members.
12. Click Invite member.
13. Enter any email > select user > Next.
    → Approver field is missing on confirm page.
14. Go to Workflows and go back to Members.
15. Repeat Step 12 and 13.
    → Approver field is shown now.

Expected Result:

In Step 13, after deleting workflow and inviting member, Approver field will be shown on confirm page because the default workflow has second approver.

Actual Result:

In Step 13, after deleting workflow and inviting member, Approver field is missing on confirm page.
In Step 15, it only reappears after opening Workflows and reinviting member.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7088525_1772044210794.3.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @suneox

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022026738833522328574
• Upwork Job ID: 2026738833522328574
• Last Price Increase: 2026-02-25

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #82683

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[melvin-bot]

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

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #82683 - "feat: [CFI] Add Approver row on the member invite confirmation page" by @TaduJR (High confidence)
Related Issues: None found

Recommendation: REVERT

PR #82683 introduced logic that shows/hides the Approver field based on policy.approvalMode === ADVANCED. However, when a workflow is deleted, the removeApprovalWorkflow function in Workflow.ts changes the approval mode from ADVANCED to BASIC if only one workflow remains. This causes the Approver field to disappear incorrectly, even though the default workflow still has a second approver configured.

Labels: No changes needed. The issue correctly has DeployBlockerCash which blocks the App/mobile deploy.

📋 Detailed Analysis

Evidence

The issue states:

• Steps 1-8: User sets up a workspace with advanced approvals and two workflows
• Step 10: User deletes the second workflow
• Steps 12-13: After deletion, the Approver field is missing when inviting new members
• Step 15: After visiting Workflows page and returning, the Approver field reappears

This behavior directly correlates with PR #82683 which added the Approver field feature.

Verification

Files affected by the bug:

• src/pages/workspace/members/WorkspaceInviteMessageComponent.tsx - Contains the shouldShowApproverRow logic
• src/libs/actions/Workflow.ts - Contains the removeApprovalWorkflow function

Confirmation that PR #82683 modifies these files:

• PR feat: [CFI] Add Approver row on the member invite confirmation page #82683 added line 87 in WorkspaceInviteMessageComponent.tsx:

  const shouldShowApproverRow = isControl && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED && policy?.areWorkflowsEnabled;

PR merge timing:

• PR feat: [CFI] Add Approver row on the member invite confirmation page #82683 merged: 2026-02-25T14:25:39Z
• Issue reported: 2026-02-25T19:12:04Z (approximately 5 hours later)
• Version: 9.3.26-0 (matches the StagingDeployCash checklist)

Root Cause

When removeApprovalWorkflow is called (lines 167-219 in src/libs/actions/Workflow.ts), it updates the policy optimistically:

approvalMode: hasMoreThanOneWorkflow ? CONST.POLICY.APPROVAL_MODE.ADVANCED : CONST.POLICY.APPROVAL_MODE.BASIC,

The variable hasMoreThanOneWorkflow checks if any employee has a submitsTo different from the default approver. After deleting the second workflow, this evaluates to false, changing approvalMode to BASIC.

The shouldShowApproverRow condition in PR #82683 strictly requires approvalMode === ADVANCED, so it immediately hides the Approver field, even though:

1. The default workflow still exists
2. The default workflow has a second approver configured
3. The workspace still has areWorkflowsEnabled = true

When navigating to Workflows and back, the policy state is likely refreshed, restoring the correct approvalMode, which makes the Approver field reappear.

The bug: The PR should have used a more robust condition to determine when to show the Approver field, or should handle the case where approvalMode is temporarily set to BASIC after workflow deletion but advanced approvals are still active.