New workflow is created after copying Workflows settings with edited default workflow

[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.91-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: #91241
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 two workspaces - A and B.
• Invite User B to Workspace A.
• Edit default workflow in Workspace A where User B is the first approver and owner is the second approver.

1. Go to staging.new.expensify.com
2. Go to Workspaces.
3. Click 3-dot menu on Workspace A > Copy settings.
4. Select Workspace B > Next.
5. Select Members and Workflows > Next.
6. Click Copy settings.
7. Open the workspace which has the settings copied > Workflows.

Expected Result:

No new workflow will be created after copying Workflows settings with edited default workflow.

Actual Result:

A new workflow is created where owner submits to owner after copying Workflows settings with edited default workflow.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7169339_1780384550322.10.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7169339

Issue Owner

Current Issue Owner: @ishpaul777

[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/3163436f1b0327d568da68d87968f99a953ef8f5143751b42d05cb217c1fb356

[melvin-bot]

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

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

Proposal

Root cause (high confidence): The Copy Settings flow copies the source's approval chains but not its default approver, so the target's derived workflow list gains a spurious "owner → owner" entry.

What is the root cause of that problem?

When copying Members + Workflows, CopyPolicySettings.ts copies employeeList (under members, which holds each member's submitsTo/forwardsTo approval chains) and the workflow fields (approvalMode, etc.) — but approver (the policy's default/first approver email) is in no part and is never copied (workflows fields list, L25).

The Workflows page derives its list with convertPolicyEmployeesToApprovalWorkflows, which identifies the default workflow by matching each group's submitsTo against getDefaultApprover(policy) = policy.approver || policy.owner. If no member submits to that default approver, it synthesizes and prepends an extra default workflow rooted at that approver (WorkflowUtils.ts:265-273).

After the copy, target B has A's employeeList (everyone submits to User B) but keeps its own approver (the owner). Since no one submits to the owner, the synthetic-default branch fires and injects the extra "owner → owner" workflow. The existing duplicate workspace flow does not hit this because it spreads ...sourcePolicy, carrying approver along (Policy.ts:3310).

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

Copy approver so it stays consistent with the copied approval chains. Because the chains live in employeeList (copied under members), the safest place is to copy approver whenever members is copied (so the default-approver root matches submitsTo/forwardsTo). Concretely, set the target's approver to the source's approver (falling back to the source owner) in the patch built by buildPolicyFieldPatch/buildCopyPolicySettingsData.

⚠️ Backend dependency: PARTS_TO_POLICY_FIELDS only drives the App's optimistic Onyx update. The actual server copy is driven by the parts string sent to the CopyPolicySettings command. Unless the backend command also copies approver, the server response will overwrite the optimistic value and the bug will return after refresh. An internal engineer should confirm/fix the backend CopyPolicySettings command (Auth/Web-Expensify) to copy approver as well — I can't access those repos to verify.

Investigation details, data flow, and edge cases

Repro data flow:

1. Workspace A: default workflow edited → A.approver = userB, and A.employeeList[*].submitsTo = userB, userB.forwardsTo = owner.
2. Copy Members + Workflows A → B. The per-target SET spreads {...targetPolicy, ...patch}; patch includes employeeList + workflow fields but not approver, so B.approver stays = owner.
3. Workflows page runs convertPolicyEmployeesToApprovalWorkflows. The only submitsTo group is userB; defaultApprover = B.approver || B.owner = owner, so that group's isDefault is false.
4. WorkflowUtils.ts:265-273 sees the first workflow isn't default → prepends a synthetic default rooted at owner → the visible "owner submits to owner" workflow.

Edge cases for the fix:

• Copying Members only (no Workflows) still triggers the bug (employeeList copied, approver not) — so tying the approver copy to members covers the reported case and this one.
• If source approver is empty (defaults to source owner), copy source.approver || source.owner so the chain root resolves to a real email rather than blanking B's value.

Alternatives considered: different owner emails between A and B — ruled out; the repro uses the same Expensifail account for both, and the mechanism holds regardless because the synthetic default is keyed on approver, not owner identity.

No related/duplicate open issues were found in a quick scan.

---

This is a DeployBlockerCash on PR #91241. If a durable fix (App and backend) can't land quickly, reverting the copy-settings change is the safe fallback to unblock the deploy.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92332) to create a draft PR (note the backend dependency above — the App fix alone may not fully resolve it).
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.