[Due for payment 2026-06-16] [$250] Workflows - Second approver becomes first approver after upgrading workspace

[applause-bot]

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.90-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: #91441
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Log in with Expensifail account.
• Create an agent on Account > Agents.

1. Go to staging.new.expensify.com
2. Create a Collect workspace.
3. Go to workspace settings > Workflows.
4. Click Add agent.
5. Click Additional approver.
6. Click Upgrade > Got it, thanks.
7. Select approver > Save.

Expected Result:

The selected approver will be the second approver, while the first approver will be agent.

Actual Result:

Second approver becomes first approver after upgrading workspace.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7168465_1780312622528.3.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7168465

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022061442740216237503
• Upwork Job ID: 2061442740216237503
• Last Price Increase: 2026-06-01

Issue Owner

Current Issue Owner: @mallenexpensify

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/cf08ff879b6f9921d2e4c88957fc7d9b333b8994b80d9677baf7ddc643e6b2ef

[melvin-bot]

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

[melvin-bot]

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

[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.

[MelvinBot]

Issue Analysis

Root Cause (structural — high confidence): The "Add agent" flow seeds the agent only into the transient APPROVAL_WORKFLOW Onyx editor key — it is never persisted to the policy (employeeList / approver). When the admin clicks Additional approver on a Collect workspace, the upgrade flow calls setWorkspaceApprovalMode(policy, defaultApprover, ADVANCED, …), which rewrites policy.approvalMode/approver but does not touch APPROVAL_WORKFLOW. The editor then re-derives its "default" workflow from the policy via convertPolicyEmployeesToApprovalWorkflows, anchored on policy.approver (the owner) — building approvers with calculateApprovers(firstEmail: defaultApprover). Since the seeded agent never made it into the policy, it is invisible to this derivation and drops out across the upgrade, leaving the newly-selected approver at index 0.

Why it's specific to Collect: on Control the agent is prepended to the existing chain ([agent, ...approvers]); on Collect the agent replaces the lone approver ([agent, ...approvers.slice(1)]) and that placement lives entirely in editor state that the upgrade discards. See WorkspaceWorkflowsApprovalsEditPage.tsx:213.

Recommended Fix: Make the in-progress seeded-agent approver chain survive the Collect→Control upgrade. Two viable directions:

1. Preserve/re-seed editor state across the upgrade — guard the edit-page seed/derive so it never clobbers a non-empty APPROVAL_WORKFLOW that already contains the seeded agent, or re-seed the agent at approver[0] once the upgrade resolves. This mirrors the existing deferred-save mechanism (queueDeferredAgentWorkflowSave / useDeferredAgentWorkflowReconciliation) that already exists to carry an in-progress agent workflow across an async boundary.
2. Persist the agent into the policy approver chain before navigating to Upgrade, so the post-upgrade re-derivation includes it.

⚠️ Deploy-blocker mitigation: if a fix can't be verified quickly, the safest immediate action is to revert PR #91441 (the github-actions bot's option 1), since this is a brand-new feature with no production exposure.

Investigation details & one item to confirm

Verified:

• Precondition created the agent, so "Add agent" uses the real-email seed path (useAddAgentToApprovalWorkflow.ts:81), not the optimistic/pending-agent path — so the deferred-save reconciliation is not involved here.
• addAdditionalApprover routes to Upgrade with backTo = approver page at index approverCount (ApprovalWorkflowEditor.tsx:139-151).
• setWorkspaceApprovalMode (ADVANCED) writes approver/approvalMode and an empty employeeList merge; grep confirms no APPROVAL_WORKFLOW write.
• withPolicyAndFullscreenLoading only unmounts the page when the policy is empty, which is not the case during an upgrade — so a remount is not forced by that HOC.

To confirm (the exact overwrite trigger): static tracing shows the editor's Onyx state should survive if the edit page stays mounted, yet the bug reproduces — so the drop happens at one of these points, worth a 2-minute console.log repro to pin down before fixing:

• the edit page remounts after the upgrade and re-runs the seed/derive at WorkspaceWorkflowsApprovalsEditPage.tsx:151-240 against the now-Control policy-derived workflow (which lacks the agent); or
• the approver selection writes at index 0 because approverCount read 0 — i.e. APPROVAL_WORKFLOW.approvers was empty when Additional approver was clicked (setApprovalWorkflowApprover, Workflow.ts:276-327).

Either way the fix is the same: don't let the upgrade boundary discard the seeded agent's position.

---

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