[$250] Workspace - Custom approval workflow disappears after offline disable and back online

[lanitochka17]

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: undefined
Reproducible in staging?: Yes
Reproducible in production?: undefined
If this was caught during regression testing, add the test name, ID and link from BrowserStack: undefined
Email or phone of affected tester (no customers): undefined
Issue reported by: Applause Internal Team
Bug source: undefined
Device used: undefined
App Component: undefined

Action Performed:

Preconditions: Invite User B, C and D to the workspace.

Steps:

1. Go to ND
2. Go to workspace settings > Workflows.
3. Click Add approval workflows.
4. Upgrade workspace if prompted.
5. Create a new workflow where User C submits to User D.
6. Go offline.
7. Disable and enable Add approvals.
8. Go online.

Expected Result:

the workflow won't be changed

Actual Result:

Custom approval workflow disappears after offline disable and reconnect

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7140796_1777449021467.1776751806027_custom_approval.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022059310847259114353
• Upwork Job ID: 2059310847259114353
• Last Price Increase: 2026-05-26

[MelvinBot]

Proposal

What is the root cause of that problem?

When toggling "Add approvals" OFF, setWorkspaceApprovalMode optimistically resets every employee's submitsTo to the policy owner and clears forwardsTo/overLimitForwardsTo. This immediately destroys all custom approval chain data in Onyx.

When toggling "Add approvals" back ON, WorkspaceWorkflowsPage computes updateApprovalMode from the current (already-reset) employee list. Since all employees now submit to the owner, approvalWorkflows.length is 1, so isAdvanceApproval is false and the mode is set to BASIC — not ADVANCED. The re-enable call sends BASIC mode with no employee routing data, and the optimistic data for enable leaves optimisticMembersState as {} (empty), so nothing is restored.

The offline aspect compounds this: both DISABLE_POLICY_APPROVALS and SET_WORKSPACE_APPROVAL_MODE are queued and sent sequentially when connectivity returns, permanently destroying the workflows server-side too.

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

In setWorkspaceApprovalMode, before clearing the employee routing when approvalMode === OPTIONAL, save the current employee approval chain state (the submitsTo, forwardsTo, overLimitForwardsTo values) into an Onyx key (e.g., previousApprovalWorkflowEmployeeList on the policy object).

Then when re-enabling approvals (non-OPTIONAL mode), check if this saved state exists and restore the employee routing from it in the optimistic data instead of leaving optimisticMembersState empty. Also recompute the correct approvalMode (ADVANCED vs BASIC) from the saved state rather than the current (cleared) employee list. Clear the saved state on success.

What alternative solutions did you explore? (Optional)

1. Prevent offline toggle-off entirely — disabling the "Add approvals" toggle while offline would avoid the problem but degrades the offline experience unnecessarily.
2. Don't clear employee routing in optimistic data on disable — simpler, but would cause the UI to still show custom workflows momentarily after disabling, creating a confusing UX.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-26 16:32:54 UTC.

Proposal

What is the root cause of that problem?

The bug has two interacting causes in setWorkspaceApprovalMode (src/libs/actions/Policy/Policy.ts):

1. The disable step destroys the source of truth. When the user disables approvals offline, setWorkspaceApprovalMode is called with approvalMode = OPTIONAL. The optimistic data (lines 960–973) immediately merges employeeList: optimisticMembersState into Onyx, which rewrites every employee's submitsTo to the policy owner and clears forwardsTo/overLimitForwardsTo. The DISABLE_POLICY_APPROVALS request is queued but not sent (user is offline). The pre-disable employee list is only preserved in the queued request's failureData (line 988).

2. The re-enable step reads the corrupted state. On WorkspaceWorkflowsPage.tsx (line 152–153), updateApprovalMode is derived from convertPolicyEmployeesToApprovalWorkflows(policy.employeeList). Because the disable's optimistic data already wiped every custom submitsTo, the function finds only the default workflow, so isAdvanceApproval = false and updateApprovalMode = BASIC. The re-enable calls setWorkspaceApprovalMode with BASIC — which skips restoring employeeList entirely, and queues a second request (SET_WORKSPACE_APPROVAL_MODE) with mode BASIC. When the user goes online, both fire in order: disable wipes the backend, re-enable sets BASIC. The custom workflow is permanently lost.

App/src/libs/actions/Policy/Policy.ts

Lines 887 to 908 in 6a3c808

	const optimisticMembersState: OnyxCollectionInputValue<PolicyEmployee> = {};
	if (approvalMode === CONST.POLICY.APPROVAL_MODE.OPTIONAL) {
	for (const employeeEmail of Object.keys(policy?.employeeList ?? {})) {
	const employee = policy?.employeeList?.[employeeEmail];
	const updates: Partial<PolicyEmployee> = {};
	if (employee?.submitsTo) {
	updates.submitsTo = policy?.owner;
	}
	if (employee?.forwardsTo) {
	updates.forwardsTo = '';
	}
	if (employee?.overLimitForwardsTo) {
	updates.overLimitForwardsTo = '';
	}
	if (Object.keys(updates).length > 0) {
	optimisticMembersState[employeeEmail] = updates;
	}
	}
	}

App/src/libs/actions/Policy/Policy.ts

Lines 960 to 974 in 6a3c808

	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.POLICY | typeof ONYXKEYS.COLLECTION.NEXT_STEP>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policyID}`,
	value: {
	...value,
	pendingFields: {
	approvalMode: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	...(shouldResetPreventSelfApproval && {preventSelfApproval: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE}),
	},
	employeeList: optimisticMembersState,
	...(shouldResetPreventSelfApproval && {preventSelfApproval: false}),
	},
	},
	];

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

Treat an offline disable-then-enable as a cancellation: detect the queued disable, restore the original state from its failureData, and drop both requests.

In setWorkspaceApprovalMode (Policy.ts), before the API.write call in the re-enable branch (approvalMode !== OPTIONAL), check the persisted request queue for a queued DISABLE_POLICY_APPROVALS with the same policyID. If found:

1. Extract the queued disable's failureData (which already contains the full original employeeList, approver, and approvalMode — line 988).
2. Apply it via Onyx.update(), stripping errorFields and pendingFields (those are meant for actual API failures, not conflict cancellation).
3. Delete the queued disable from the persisted request queue via deleteRequestsByIndices.
4. Return without calling API.write — no re-enable request is queued either.

This restores the policy to its pre-disable state entirely on the client. No requests reach the server, so there is nothing to undo.

For the symmetric case (user disables while a queued enable exists), add a conflict resolver to the disable's API.write call that finds and removes the queued SET_WORKSPACE_APPROVAL_MODE, then lets the new disable proceed normally. This uses the existing checkAndFixConflictingRequest pattern from resolveEnableFeatureConflicts in RequestConflictUtils.ts.

The fix only triggers when both legs are queued offline against the same policyID, so the normal online path and single toggles are completely unaffected.

What alternative solutions did you explore? (Optional)

1. Using checkAndFixConflictingRequest for both directions — This was attempted first but fails because prepareRequest applies the re-enable's optimistic data before the conflict resolver in SequentialQueue.push can roll back the disable. The re-enable's optimistic approvalMode: BASIC overwrites the restored state. Moving the conflict check into setWorkspaceApprovalMode itself (before API.write) avoids this ordering issue entirely.

2. Storing previousApprovalMode in a scratch Onyx field — The disable optimistic data would persist the pre-disable mode, and the re-enable would read it instead of recomputing from the wiped employee list. Rejected because it leaks transient state into the policy schema, requires cleanup on every success/failure path, and still sends both redundant API requests to the server.

3. Not wiping submitsTo in the disable optimistic data — This would keep the employee list intact so re-enable can read it. Rejected because the optimistic wipe is intentional: it makes the UI immediately reflect the disabled state. Removing it would show stale approval routing while the disable is pending.

[Abdulloh0109]

Proposal

What is the root cause of that problem?

The bug is a two-step optimistic-update corruption that happens when the user disables approvals offline, then re-enables them before going back online.

Step 1 — Toggle OFF (offline) corrupts the Onyx employee list.
When the user disables "Add approvals," setWorkspaceApprovalMode in src/libs/actions/Policy/Policy.ts:880-898 builds an optimistic update that destructively clears the entire employeeList in Onyx: every employee's submitsTo is set to policy.owner (line 886), forwardsTo is set to '' (line 889), and overLimitForwardsTo is set to '' (line 892). This optimistic patch is written to ONYXKEYS.COLLECTION.POLICY immediately (line 960-962). Because the user is offline, no API call fires yet — the call is queued.

Step 2 — Toggle ON (still offline or while reconnecting) reads the already-corrupted list.
Back in src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx, approvalWorkflows is a live derived value computed on every render from convertPolicyEmployeesToApprovalWorkflows({policy, ...}) (line 139), which reads policy.employeeList from Onyx. isAdvanceApproval at line 148 checks whether there is more than one workflow or more than one approver in the first workflow. updateApprovalMode at line 149 is ADVANCED when that is true, BASIC otherwise. Because Step 1 zeroed out all submitsTo chains, approvalWorkflows now contains only the default/empty workflow, so isAdvanceApproval is false and updateApprovalMode becomes CONST.POLICY.APPROVAL_MODE.BASIC.

When the user re-enables approvals (line 383), setWorkspaceApprovalMode is called with this stale BASIC mode instead of ADVANCED, and a second API call is queued.

Step 3 — Both queued calls fire when reconnecting.
Call 1 sets OPTIONAL on the server (disabling approvals — correct). Call 2 sets BASIC on the server (re-enabling — but with no custom workflow data). The server now has the policy in BASIC mode with all submitsTo chains cleared. The custom approval workflow is gone permanently. The failureData at line 979 — which would restore employeeList: policy?.employeeList — only runs if an API call fails; since both calls succeed, the rollback never triggers.

---

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

The fix layer is data/optimistic update in src/libs/actions/Policy/Policy.ts.

The optimistic update for OPTIONAL mode at lines 880–898 and 960–962 should not modify the employeeList in the Onyx store. The employee-chain clearing is a server-side concern; the client only needs to change approvalMode to OPTIONAL so the UI reflects the disabled state. The actual submitsTo/forwardsTo values should remain intact in the local Onyx store until the server confirms the change (via the successData response).

Concretely: remove employeeList: optimisticMembersState from the optimistic data object built at lines 951–964. The optimisticMembersState object (built at lines 878–898) can be removed entirely from the optimistic path; it should remain in successData so the local store is updated once the server confirms the clearing.

With this fix, policy.employeeList in Onyx retains the custom workflow data while offline. When the user re-enables approvals, convertPolicyEmployeesToApprovalWorkflows still finds the original custom workflow, isAdvanceApproval is true, updateApprovalMode becomes ADVANCED, and the second queued API call correctly restores the advanced workflow on the server.

Scope:

• File touched: src/libs/actions/Policy/Policy.ts (remove employeeList from optimistic data, move employeeList: optimisticMembersState to successData)
• File NOT touched: WorkspaceWorkflowsPage.tsx, convertPolicyEmployeesToApprovalWorkflows, navigation, failure/rollback logic
• Platforms: web (Chrome) confirmed by the issue; the same code path runs on iOS/Android so the fix covers all platforms

Edge cases:

• Offline only, no re-enable: The UI correctly shows OPTIONAL mode via the approvalMode field; no visual regression because the approval submenu is gated on approvalMode, not on individual employee fields.
• Re-enable while still offline: The queued calls remain ordered; when reconnecting, Call 1 (OPTIONAL) and Call 2 (ADVANCED + original employee chain) both succeed, restoring the custom workflow correctly.
• API failure rollback: The existing failureData at line 979 already restores employeeList: policy?.employeeList, which is still the original (uncorrupted) value under the fix. No change needed there.

---

What alternative solutions did you explore? (Optional)

Alternative 1 — Fix the updateApprovalMode calculation in WorkspaceWorkflowsPage.tsx:148-149.
Instead of recalculating from the (potentially stale) approvalWorkflows, store the approval mode before it is set to OPTIONAL and restore it on re-enable. Rejected: requires adding new state or a new Onyx key to track the "pre-disable" mode, which is more invasive and duplicates data that the server already holds. The root cause is the optimistic corruption; fixing the symptom in the UI layer leaves the corrupted store intact.

Alternative 2 — Block the toggle-ON action while offline.
If the user cannot re-enable while offline, the second API call is never queued with BASIC mode. Rejected: this degrades UX for a valid offline use case and conflicts with the app's offline-first architecture.

Alternative 3 — Server-side guard.
Have the server refuse to transition from OPTIONAL to BASIC/ADVANCED without receiving explicit approver data. Rejected: requires backend changes, is slower to ship, and does not fix the client-side Onyx corruption that would still affect derived UI state while offline.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

When the user toggles Add approvals OFF while offline, setWorkspaceApprovalMode optimistically clears submitsTo / forwardsTo / overLimitForwardsTo on every employee in the policy and queues a DISABLE_POLICY_APPROVALS request:

https://github.com/Expensify/App/blob/main/src/libs/actions/Policy/Policy.ts#L889-L908
https://github.com/Expensify/App/blob/main/src/libs/actions/Policy/Policy.ts#L960-L974

When the user immediately toggles it back ON (still offline), setWorkspaceApprovalMode is called again, this time with BASIC / ADVANCED. Because the OFF branch above already cleared the approval fields in Onyx, the policy reference passed here no longer carries the original chain — the only thing optimistically written this time is the new approvalMode, and a second SET_WORKSPACE_APPROVAL_MODE request gets queued behind the disable:

https://github.com/Expensify/App/blob/main/src/libs/actions/Policy/Policy.ts#L1010-L1026
https://github.com/Expensify/App/blob/main/src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx#L391-L415

Once the device reconnects, the queue drains in order:

1. DISABLE_POLICY_APPROVALS — the backend wipes submitsTo / forwardsTo for all employees.
2. SET_WORKSPACE_APPROVAL_MODE — sets the mode back to BASIC / ADVANCED, but only the mode field travels in the payload, so the workflows are gone server-side.

So a quick OFF→ON while offline is functionally equivalent to a permanent disable. Pre-existing custom workflows (User C → User D in the repro) are destroyed.

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

I think the cleanest fix is to make the two API calls self-cancel when paired offline. Before queuing the re-enable in setWorkspaceApprovalMode, look for a still-pending DISABLE_POLICY_APPROVALS for the same policy in PersistedRequests. If one is found, this is a no-op round-trip: drop the queued disable, skip the new request entirely, and restore Onyx to the pre-disable state (which is conveniently already stored in that pending request's failureData).

     if (approvalMode === CONST.POLICY.APPROVAL_MODE.OPTIONAL) {
         const params: DisablePolicyApprovalsParams = {
             policyID,
         };
         API.write(WRITE_COMMANDS.DISABLE_POLICY_APPROVALS, params, {optimisticData, failureData, successData});
     } else {
+        const persistedRequests = PersistedRequests.getAll();
+        const pendingDisableIndex = persistedRequests.findIndex(
+            (request) => request.command === WRITE_COMMANDS.DISABLE_POLICY_APPROVALS && request.data?.policyID === policyID,
+        );
+        if (pendingDisableIndex !== -1) {
+            // The user toggled OFF then ON while offline — cancel the paired requests
+            // and restore the pre-disable state captured in the disable's failureData.
+            const pendingDisable = persistedRequests.at(pendingDisableIndex);
+            const rollback = pendingDisable?.failureData?.find((u) => u.key === `${ONYXKEYS.COLLECTION.POLICY}${policyID}`)?.value;
+            PersistedRequests.deleteRequestsByIndices([pendingDisableIndex]);
+            Onyx.merge(`${ONYXKEYS.COLLECTION.POLICY}${policyID}`, {
+                ...(rollback ?? {}),
+                pendingFields: {approvalMode: null},
+                errorFields: {approvalMode: null},
+            });
+            return;
+        }
         const params: SetWorkspaceApprovalModeParams = {
             policyID,
             value: JSON.stringify({
                 ...value,
                 // This property should now be set to false for all Collect policies
                 isAutoApprovalEnabled: false,
             }),
         };
         // eslint-disable-next-line rulesdir/no-multiple-api-calls
         API.write(WRITE_COMMANDS.SET_WORKSPACE_APPROVAL_MODE, params, {optimisticData, failureData, successData});
     }

This leans on a pattern already used in this file (updateWorkspaceGeneralSettings rewrites a queued CREATE_WORKSPACE request the same way at src/libs/actions/Policy/Policy.ts around the PersistedRequests.update call), so it stays consistent with the existing offline-queue conventions.

A small supporting tweak: extend the early-return guard at the top of setWorkspaceApprovalMode so it also bails out when approvalMode matches policy.approvalMode and there's no pending disable to undo. That prevents accidental no-op API writes and is safe because the toggle handler already checks isHRConnected.

I'd also add Jest coverage in tests/actions/PolicyTest.ts for the offline OFF→ON sequence (queue both writes, then assert the queue is empty and employeeList is intact).

What alternative solutions did you explore? (Optional)

1. Stop clearing employee approval fields optimistically when disabling. Only flip approvalMode in the optimistic data. Rejected because it only masks the Onyx side — the backend DISABLE_POLICY_APPROVALS still wipes the chain when the queue drains, so the workflows would still be lost on reconnect. It also makes the UI look out-of-sync (Workflows page would still render the old chain while approvalMode === OPTIONAL).

2. Re-send the workflows after re-enabling. When toggling ON while a disable is still pending, also queue an UPDATE_WORKSPACE_APPROVAL carrying the original employeeList. Rejected because it triples the round-trip (DISABLE → SET → UPDATE) for a state the user never actually wanted to change, and the backend would briefly broadcast cleared workflows to other clients between calls 1 and 3.

3. Block the toggle while a pendingFields.approvalMode is set. Simpler, but a regression in UX — users can legitimately toggle offline, and the current pattern allows it for every other workspace setting.

[melvin-bot]

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

[lxyct825-ops]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022059310847259114353

[lxyct825-ops]

Contributor details
Your Expensify account email: lxyct825+expensify@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01174eaf71ab8fc150