[Due for payment 2026-09-09] [$250] Migrated user's reports follow Classic approval workflow instead of New Expensify workflow

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4017-3
Reproducible in staging?: Needs Reproduction (Reproduction blocked)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @AnaFlavia-Oliveira
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Migrate a user to New Expensify.
2. Configure the approval workflow in New Expensify.
3. As the migrated user, create a test report.
4. Submit the report.
5. Observe the approval workflow that is applied.

Expected Result:

Reports submitted by migrated users should follow the approval workflow configured in New Expensify.
The report should be routed according to the current New Expensify approval settings.

Actual Result:

Reports follow the approval workflow configured in Expensify Classic instead of the workflow configured in New Expensify.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The screenshots for the issue are in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072760701795396019
• Upwork Job ID: 2072760701795396019
• Last Price Increase: 2026-07-30

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Issue Analysis

Root Cause (Medium confidence): This is a backend / server-side issue, not an App bug. New Expensify's approval-workflow settings (approval mode, per-employee submitsTo chain, default approver, approval rules) all live on the policy object that the server syncs down to the App. The App only mirrors that data — it does not independently decide "Classic vs New Expensify" routing. So if a migrated user's report follows the Classic workflow, it's because the server-synced policy still carries Classic routing data (or the authoritative submit-time routing on the server ignores the New Expensify config for migrated policies).

Why the fix is outside this repo: When a report is submitted, the App computes only an optimistic managerAccountID from the policy data it already has, and the authoritative approval routing is recomputed server-side, which overwrites the App's value. The App faithfully reads whatever the backend supplies, so there is no App-side code change that can correct the workflow. This requires an internal engineer with backend access to investigate the Classic→New Expensify migration and the submit-time approval routing.

Investigation details (App code evidence)

The App reads the approval workflow entirely from backend-synced policy fields (approvalMode, approver, employeeList[login].submitsTo/forwardsTo, rules.approvalRules):

• src/libs/PolicyUtils.ts:1620 — getApprovalWorkflow() reads policy.approvalMode verbatim (defaults to ADVANCED when absent).
• src/libs/PolicyUtils.ts:1722-1735 — getManagerAccountEmail() branches on approval mode: OPTIONAL/BASIC → default approver; ADVANCED → employee.submitsTo.
• src/libs/PolicyUtils.ts:1759-1781 — getSubmitReportManagerAccountID() has a notable edge case: if the submitter is not present in policy.employeeList and the mode is ADVANCED, the App falls back to the report's existing managerID (which can carry a Classic value). A migrated user missing from the New Expensify employeeList would hit this path — but the underlying cause (employeeList not populated / wrong approvalMode for the migrated policy) is still backend data.

Data flow: backend syncs policy → App computes optimistic managerAccountID on submit → App sends SUBMIT_REPORT → backend authoritatively recomputes routing and overwrites the optimistic value. The Classic-vs-New-Expensify decision is not made in the App.

Suggested backend checks (for the internal engineer): For a migrated user's submitted report, compare (1) the policy's approvalMode / approver / employeeList submitsTo values the server holds at submit time — is it the New Expensify config or stale Classic config?, and (2) the managerAccountID the App sent vs. the manager the backend actually assigned. That will pinpoint whether the migration failed to write the New Expensify workflow, or whether submit-time routing ignores it for migrated policies.

Alternative explanation considered: A pure App display/edit bug (e.g., the workflow editor not saving). Ruled out as the primary cause because the symptom is about routing at submit time, which is server-authoritative — even a correct App-side workflow edit is overridden by the backend's recomputation.

Note: Not yet reproduced (issue is marked "Needs Reproduction"), so confidence is Medium pending production logs.

---

Next Steps: This needs an internal engineer to investigate the backend migration + submit-time approval routing. Reply with @MelvinBot <feedback> to refine this analysis.

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-02 19:17:23 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

A user who was migrated from Expensify Classic to New Expensify has an approval workflow configured in New Expensify, but when they submit a report it still routes according to the old Classic workflow. The report ends up going to the wrong approver.

What is the root cause of that problem?

I traced the submit path to see where NewDot decides the approval chain, and the App never actually makes that decision. When you tap Submit, submitReport() in src/libs/actions/IOU/ReportWorkflow.ts computes a manager account ID and sends it to the server:

const submitReportManagerAccountID = getSubmitReportManagerAccountID(policy, expenseReport, submitterLogin);
...
managerAccountID: managerID,   // -> API.write(SUBMIT_REPORT, parameters)

That value comes from getSubmitReportManagerAccountID -> getSubmitToAccountID -> getManagerAccountEmail in src/libs/PolicyUtils.ts (around lines 1722-1770). Every input those helpers read (policy.approvalMode, policy.employeeList[login].submitsTo/forwardsTo, policy.rules.approvalRules) is server-provided Onyx data from OpenApp/policy Pusher payloads. The App uses it only to build the optimistic submitted action and next-step preview. The managerAccountID we send is a hint; the backend re-derives the authoritative approval chain during SubmitReport using the policy's server-side approval config plus, for migrated accounts, OldDot's approval tables.

So the workflow that a submitted report actually follows is decided server-side. If a migrated user's report routes per Classic rules, the authoritative approval config for that migrated account is still Classic on the server. I grepped src/libs and src/libs/actions for any migrated/Classic-vs-NewDot workflow branch (migrat*, isMigrated, approvalWorkflow toggles) and there is none, so the App has no code path that forces the old workflow either. Nothing in this repo's history around the submit-manager helpers changed this behavior (recent touches like d32fe8a2042 and 291615979a2 are refactors passing the owner login through, not routing changes).

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

I don't think there's an App-side change that fixes this. Patching getSubmitToAccountID/getManagerAccountEmail would only change the optimistic managerAccountID hint, which the server overwrites when it re-derives the chain. The reported symptom is the applied workflow, which is a backend/migration decision.

Before anyone builds a NewDot fix, it's worth confirming where the wrong routing is decided: submit a report as the migrated user and inspect the SubmitReport response and the resulting nextStep/managerID the server returns. If the server returns the Classic approver even though the New Expensify workflow is configured, this is a migration data-consistency / Auth issue (the migrated account's server-side approval config wasn't updated to the NewDot workflow) and belongs in Auth/Web-Expensify, not Expensify/App.

What alternative solutions did you explore? (Optional)

I looked at overriding the manager ID we send from submitReport() so the optimistic hint always matches the NewDot config. Rejected it because the server ignores the hint and routes on its own config, so it would only make the optimistic UI briefly disagree with the real result. I also checked for a "migrated user" branch to gate on, but no such state exists in the App.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-02 19:19:04 UTC.

Proposal

What is the root cause of that problem?

On submit, the App decides the approver on the client, writes it optimistically, and sends it to the backend as the report's manager. In submitReport it computes managerID = getSubmitReportManagerAccountID(...), writes it optimistically to the report, and sends it as managerAccountID: managerID in the SUBMIT_REPORT request. So whatever the client resolves becomes the manager the report routes to.

The problem is that every branch of that resolution reads a policy/report field that migration mutates in place — the fields still hold the Classic (OldDot) approval chain, and nothing anchors the resolution to a New Expensify-authoritative signal. Walking getSubmitReportManagerAccountID → getSubmitToAccountID → getManagerAccountID → getManagerAccountEmail:

• Advanced branch → returns employeeList[submitter].submitsTo — the per-employee chain imported from Classic.
• Optional/Basic branch → returns getDefaultApprover = policy.approver || policy.owner — the Classic default approver.
• Rule branch → returns an approver from policy.rules.approvalRules — the Classic category/tag rules.
• Missing-member fallback → when the migrated submitter isn't in employeeList yet, hasReliablePolicyRoute is false and it returns the report's own managerID (L1776-L1777) — the stale Classic manager stamped on the report.

The mode that selects between these comes from getApprovalWorkflow, which defaults an unset approvalMode to ADVANCED:

return policy?.approvalMode ?? CONST.POLICY.APPROVAL_MODE.ADVANCED;

This is the pivot: it collapses "no mode set" and "explicitly Advanced" into the same ADVANCED result, so the resolver cannot tell a real New Expensify advanced workflow from a migration artifact and trusts the Classic submitsTo in the ambiguous case. A freshly migrated policy typically carries the Classic submitsTo chain in employeeList and no explicit approvalMode, so the resolver infers ADVANCED and routes by that old submitsTo — even when the New Expensify workflow was configured as a basic/default-approver flow.

The same stale-sourced value is reused everywhere, which is why the symptom is consistent: getApprovalChain also builds the chain from the very same getManagerAccountEmail, so the next-step preview and the submitted manager agree on the wrong (Classic) approver.

Net: the submit-time approver is derived entirely from migration-mutable fields with no New Expensify-authoritative anchor, and the App transmits it as the authoritative managerAccountID. Every resolution path lands on Classic-origin data, so the report follows the Classic workflow regardless of which mode the migrated policy ends up in.

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

Give the resolver an unambiguous signal instead of an inferred one. Only trust the per-employee submitsTo branch when the policy is explicitly in Advanced mode, not when Advanced was merely defaulted from an unset approvalMode. When approvalMode is unset on a migrated policy, resolve the approver from the configured default approver (policy.approver, the value the New Expensify workflow editor writes for basic/default flows) rather than a per-employee submitsTo that predates the migration. Concretely, gate the employee?.submitsTo branch in getManagerAccountEmail on policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED before falling back to defaultApprover.

Also guard the report.managerID fallback in getSubmitReportManagerAccountID so a stale Classic manager isn't returned when the policy already has a configured default approver to route to. Together these keep the optimistic managerAccountID (and the getApprovalChain preview) aligned with the New Expensify workflow, so migrated policies submit to the configured approver instead of the Classic one.

For the case where the migrated policy is genuinely stored as Advanced but its submitsTo still holds the Classic chain (i.e. the New Expensify edit didn't overwrite it), the reconciliation belongs on save/migration — saving a workflow should rewrite submitsTo/approver/approvalMode to the configured values — since routing at submit is server-authoritative and would otherwise re-apply the Classic chain regardless of the client.

What alternative solutions did you explore? (Optional)

Gating hasReliablePolicyRoute on !!policy?.approvalMode so a submitter missing from employeeList no longer drops the route to the report's stale managerID. That closes the missing-member fallback, but it still trusts submitsTo whenever the submitter is present in employeeList — which is the more common migrated case — so it doesn't address the inferred-Advanced path above. Purely reconciling the stored fields on the backend was also considered, but a client that keeps sending a stale managerAccountID would still momentarily misroute the optimistic route, so the client resolver should read an unambiguous mode too.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The report's approver on submit is decided by the backend SubmitReport command, not by NewDot. NewDot only computes an optimistic prediction of the manager and passes it along as a hint — and it derives that prediction purely from the policy's approval config that already lives in Onyx.

The submit path is:

1. NewDot computes the manager from the policy config and sends it as managerAccountID:

App/src/libs/actions/IOU/ReportWorkflow.ts

Lines 1386 to 1387 in a9e6aed

	const submitReportManagerAccountID = getSubmitReportManagerAccountID(policy, expenseReport, submitterLogin);
	const managerID = trimmedManagerEmail ? (resolvedManagerAccountIDFromEmail ?? managerIDFromChain ?? expenseReport.managerID) : submitReportManagerAccountID;

App/src/libs/actions/IOU/ReportWorkflow.ts

Lines 1634 to 1636 in a9e6aed

	const parameters: SubmitReportParams = {
	reportID: expenseReport.reportID,
	managerAccountID: managerID,

2. getSubmitReportManagerAccountID resolves that value entirely from policy.rules.approvalRules, policy.employeeList[submitter].submitsTo, policy.approvalMode and the default approver:

App/src/libs/PolicyUtils.ts

Lines 1758 to 1780 in a9e6aed

	function getSubmitReportManagerAccountID(policy: OnyxEntry<Policy>, expenseReport: OnyxEntry<Report>, submitterLogin: string | undefined): number | undefined {
	const ownerAccountID = expenseReport?.ownerAccountID ?? CONST.DEFAULT_NUMBER_ID;
	const existingManagerID = expenseReport?.managerID;
	const approvalRules = policy?.rules?.approvalRules;
	const ruleApprover = !isSubmitAndClose(policy) && approvalRules?.length ? getFirstRuleApprover(approvalRules, expenseReport, submitterLogin) : '';
	const submitToAccountID = getSubmitToAccountID(policy, expenseReport, submitterLogin);
	const isValidSubmitToAccountID = isValidAccountRoute(submitToAccountID);
	const isValidExistingManagerID = isValidAccountRoute(existingManagerID ?? CONST.DEFAULT_NUMBER_ID) && existingManagerID !== ownerAccountID;
	const hasReliablePolicyRoute =
	([CONST.POLICY.APPROVAL_MODE.OPTIONAL, CONST.POLICY.APPROVAL_MODE.BASIC] as Array<ValueOf<typeof CONST.POLICY.APPROVAL_MODE>>).includes(getApprovalWorkflow(policy)) ||
	!!ruleApprover ||
	!!policy?.employeeList?.[submitterLogin ?? ''];
	if (hasReliablePolicyRoute && isValidSubmitToAccountID) {
	return submitToAccountID;
	}
	if (!hasReliablePolicyRoute && isValidExistingManagerID) {
	return existingManagerID;
	}
	return isValidSubmitToAccountID ? submitToAccountID : existingManagerID;
	}

App/src/libs/PolicyUtils.ts

Lines 1721 to 1740 in a9e6aed

	function getManagerAccountEmail(policy: OnyxEntry<Policy>, ownerLogin: string | undefined): string {
	const defaultApprover = getDefaultApprover(policy);
	// For policy using the optional or basic workflow, the manager is the policy default approver.
	if (([CONST.POLICY.APPROVAL_MODE.OPTIONAL, CONST.POLICY.APPROVAL_MODE.BASIC] as Array<ValueOf<typeof CONST.POLICY.APPROVAL_MODE>>).includes(getApprovalWorkflow(policy))) {
	return defaultApprover;
	}
	const employee = policy?.employeeList?.[ownerLogin ?? ''];
	if (!employee && !defaultApprover) {
	return '';
	}
	return employee?.submitsTo ?? defaultApprover ?? '';
	}
	function getManagerAccountID(policy: OnyxEntry<Policy>, ownerLogin: string | undefined) {
	const managerEmail = getManagerAccountEmail(policy, ownerLogin);
	return managerEmail ? (getAccountIDsByLogins([managerEmail]).at(0) ?? -1) : -1;
	}

3. When a workflow is configured in NewDot, updateApprovalWorkflow writes exactly those same fields (employeeList submitsTo, approvalMode, approver) back into the policy — so NewDot's own read (step 2) is fully consistent with what the user just configured:

App/src/libs/actions/Workflow.ts

Lines 158 to 203 in a9e6aed

	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.APPROVAL_WORKFLOW | typeof ONYXKEYS.COLLECTION.POLICY>> = [
	{
	onyxMethod: Onyx.METHOD.SET,
	key: ONYXKEYS.APPROVAL_WORKFLOW,
	value: null,
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
	value: {
	employeeList: updatedEmployees,
	approvalMode: updatedApprovalMode,
	...(newDefaultApprover ? {approver: newDefaultApprover} : {}),
	},
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.POLICY>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
	value: {
	employeeList: previousEmployeeList,
	approvalMode: previousApprovalMode,
	pendingFields: {employeeList: null},
	...(newDefaultApprover ? {approver: previousDefaultApprover} : {}),
	},
	},
	];
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.POLICY>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
	value: {
	employeeList: Object.fromEntries(Object.keys(updatedEmployees).map((key) => [key, {pendingAction: null, pendingFields: null}])),
	},
	},
	];
	const parameters: UpdateWorkspaceApprovalParams = {
	policyID: policy.id,
	employees: JSON.stringify(Object.values(updatedEmployees)),
	defaultApprover: newDefaultApprover,
	};
	API.write(WRITE_COMMANDS.UPDATE_WORKSPACE_APPROVAL, parameters, {optimisticData, failureData, successData});

So on the client, once the NewDot workflow is saved, both the initial managerID set at report creation and the recomputed value at submit time are driven off the New Expensify config:

App/src/libs/ReportUtils.ts

Line 6858 in a9e6aed

managerID: getManagerAccountID(policy, login),

Because the config the client persists and the config the client reads back are the same employeeList/approvalMode/approver fields, NewDot cannot produce a Classic approver unless those fields still hold Classic values — i.e. the server-side workflow config for the migrated policy was never converted to the New Expensify config, or the backend SubmitReport command re-routes the report using the legacy (Classic) workflow and ignores the sent managerAccountID.

So: migrated policy → server still has the Classic approval config (or SubmitReport applies Classic routing) → report is approved via the Classic chain even though the New Expensify workflow was configured → symptom. This chain is authoritative on the server; NewDot's managerAccountID is only an optimistic hint and does not decide the workflow.

Note: the auto-linked/recently-merged PR is not the cause here — the client approval-routing code above is self-consistent and would route to the New Expensify approver whenever the policy's Onyx config reflects the New Expensify workflow.

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

There is no App-side change that fixes this: NewDot already (a) persists the New Expensify workflow into employeeList/approvalMode/approver via updateApprovalWorkflow (permalink) and (b) re-derives the approver from that same config at submit time via getSubmitReportManagerAccountID (permalink). Given correct policy data, both already route to the New Expensify approver, so the fix belongs on the backend (Auth / Web-Expensify) that owns migration and the SubmitReport command:

• Ensure the migration converts the Classic per-employee submitsTo/approvalMode into the New Expensify workflow config on the policy, and
• Ensure SubmitReport routes the report using the current New Expensify workflow config rather than the legacy Classic chain.

What would confirm the exact server-side cause (before opening a backend PR):

• Inspect the migrated policy's Onyx policy_<id> after configuring the workflow in NewDot — check whether employeeList[submitter].submitsTo / approvalMode / approver reflect the New Expensify approver or still hold Classic values. If they still hold Classic values, it's a migration/sync gap.
• Capture the SubmitReport request/response for the migrated user and confirm whether the sent managerAccountID (the New Expensify approver) is honored or overridden by the server. If overridden, it's a SubmitReport routing bug.

Since the reproduction is currently blocked, the first step is to unblock a repro with a migrated test account and capture the two data points above; minor triage details can be discussed in the PR phase once the exact server layer is pinpointed.

What alternative solutions did you explore? (Optional)

Forcing the client to always re-send the freshly-computed getSubmitToAccountID as managerAccountID — but the client already sends that value (permalink), and it is authoritatively re-evaluated on the server, so a client-only change cannot override Classic routing. The backend migration/SubmitReport fix is the only one that addresses the root cause.

[abbasifaizan70]

Proposal

Please re-state the problem that we are trying to solve in this issue.

• After a user is migrated from Expensify Classic (OldDot) to New Expensify, they configure an approval workflow in New Expensify, create a report, and submit it. Instead of being routed according to the workflow configured in New Expensify, the report is routed according to the approval workflow that was configured in Expensify Classic.

What is the root cause of that problem?

• When a report is submitted, getSubmitReportManagerAccountID decides which manager/approver ID to assign to the report. It first computes the "fresh" approver via getSubmitToAccountID (which reads the policy's current approvalMode, rules.approvalRules, and employeeList[login].submitsTo/default approver — i.e. exactly what's configured in New Expensify):
  

  App/src/libs/PolicyUtils.ts

  Lines 1721 to 1756 in 9472088

  	function getManagerAccountEmail(policy: OnyxEntry<Policy>, ownerLogin: string | undefined): string {
  	const defaultApprover = getDefaultApprover(policy);
  	// For policy using the optional or basic workflow, the manager is the policy default approver.
  	if (([CONST.POLICY.APPROVAL_MODE.OPTIONAL, CONST.POLICY.APPROVAL_MODE.BASIC] as Array<ValueOf<typeof CONST.POLICY.APPROVAL_MODE>>).includes(getApprovalWorkflow(policy))) {
  	return defaultApprover;
  	}
  	const employee = policy?.employeeList?.[ownerLogin ?? ''];
  	if (!employee && !defaultApprover) {
  	return '';
  	}
  	return employee?.submitsTo ?? defaultApprover ?? '';
  	}
  	function getManagerAccountID(policy: OnyxEntry<Policy>, ownerLogin: string | undefined) {
  	const managerEmail = getManagerAccountEmail(policy, ownerLogin);
  	return managerEmail ? (getAccountIDsByLogins([managerEmail]).at(0) ?? -1) : -1;
  	}
  	/**
  	* Returns the accountID to whom the given expenseReport submits reports to in the given Policy.
  	*/
  	function getSubmitToAccountID(policy: OnyxEntry<Policy>, expenseReport: OnyxEntry<Report>, ownerLogin: string | undefined): number {
  	const approvalRules = policy?.rules?.approvalRules;
  	if (!isSubmitAndClose(policy) && approvalRules?.length) {
  	const ruleApprover = getFirstRuleApprover(approvalRules, expenseReport, ownerLogin);
  	if (ruleApprover) {
  	return getAccountIDsByLogins([ruleApprover]).at(0) ?? -1;
  	}
  	}
  	return getManagerAccountID(policy, ownerLogin);
  	}

• It then decides whether to trust that freshly computed route via hasReliablePolicyRoute. That flag is only true for OPTIONAL/BASIC approval modes, when a category/tag approval rule matched, or when the submitter has an entry in policy.employeeList. If none of those hold (e.g. right after a Classic → New Expensify migration the submitter isn't yet present in policy.employeeList even though the policy already has approvalMode: ADVANCED and a valid default approver/owner configured), the function falls back to expenseReport.managerID — the manager ID the report already had, which for a migrated report was populated based on the Expensify Classic approval workflow. This is exactly why the report keeps following the Classic workflow instead of the newly configured New Expensify one:
  

  App/src/libs/PolicyUtils.ts

  Lines 1758 to 1780 in 9472088

  	function getSubmitReportManagerAccountID(policy: OnyxEntry<Policy>, expenseReport: OnyxEntry<Report>, submitterLogin: string | undefined): number | undefined {
  	const ownerAccountID = expenseReport?.ownerAccountID ?? CONST.DEFAULT_NUMBER_ID;
  	const existingManagerID = expenseReport?.managerID;
  	const approvalRules = policy?.rules?.approvalRules;
  	const ruleApprover = !isSubmitAndClose(policy) && approvalRules?.length ? getFirstRuleApprover(approvalRules, expenseReport, submitterLogin) : '';
  	const submitToAccountID = getSubmitToAccountID(policy, expenseReport, submitterLogin);
  	const isValidSubmitToAccountID = isValidAccountRoute(submitToAccountID);
  	const isValidExistingManagerID = isValidAccountRoute(existingManagerID ?? CONST.DEFAULT_NUMBER_ID) && existingManagerID !== ownerAccountID;
  	const hasReliablePolicyRoute =
  	([CONST.POLICY.APPROVAL_MODE.OPTIONAL, CONST.POLICY.APPROVAL_MODE.BASIC] as Array<ValueOf<typeof CONST.POLICY.APPROVAL_MODE>>).includes(getApprovalWorkflow(policy)) ||
  	!!ruleApprover ||
  	!!policy?.employeeList?.[submitterLogin ?? ''];
  	if (hasReliablePolicyRoute && isValidSubmitToAccountID) {
  	return submitToAccountID;
  	}
  	if (!hasReliablePolicyRoute && isValidExistingManagerID) {
  	return existingManagerID;
  	}
  	return isValidSubmitToAccountID ? submitToAccountID : existingManagerID;
  	}

• In short: hasReliablePolicyRoute treats "submitter missing from employeeList" as reason to distrust a validly-computed manager ID, even when the policy has a perfectly valid, currently-configured default approver (policy.approver/policy.owner). That causes the code to prefer the stale, Classic-derived managerID already stored on the report over the correct, currently configured New Expensify approver.

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

• In getSubmitReportManagerAccountID, also treat the computed route as reliable when the policy has a configured default approver (getDefaultApprover), since that reflects the workflow currently configured in New Expensify and shouldn't be overridden by a stale managerID inherited from Classic:
  

  App/src/libs/PolicyUtils.ts

  Lines 1766 to 1769 in 9472088

  	const hasReliablePolicyRoute =
  	([CONST.POLICY.APPROVAL_MODE.OPTIONAL, CONST.POLICY.APPROVAL_MODE.BASIC] as Array<ValueOf<typeof CONST.POLICY.APPROVAL_MODE>>).includes(getApprovalWorkflow(policy)) ||
  	!!ruleApprover ||
  	!!policy?.employeeList?.[submitterLogin ?? ''];

const hasReliablePolicyRoute =
  (
    [
      CONST.POLICY.APPROVAL_MODE.OPTIONAL,
      CONST.POLICY.APPROVAL_MODE.BASIC,
    ] as Array<ValueOf<typeof CONST.POLICY.APPROVAL_MODE>>
  ).includes(getApprovalWorkflow(policy)) ||
  !!ruleApprover ||
  !!policy?.employeeList?.[submitterLogin ?? ""] ||
  !!getDefaultApprover(policy);

[oqildev]

Proposal

What is the root cause of that problem?

A report's approver is not stored on the report — it is derived from the policy's employee submit chain (employeeList[submitter].submitsTo → forwardsTo) plus policy.approvalMode. Those two fields are the single source of truth that getSubmitToAccountID/getManagerAccountID and getApprovalWorkflow(policy) read to decide who the report routes to (see the SUBMITTED branch in NextStepUtils.ts L233-254 and its deprecated twin L750-808).

New Expensify's approvals editor reads and writes those very same fields, so a migrated policy whose employeeList was seeded from Classic will keep routing via Classic values unless the NewDot save rewrites them. Two things make that mismatch stick:

1. The migration copies the Classic "submit to" person straight into the new workspace's approver/submitsTo chain (upgrade-personal-workspace-to-collect-plan.md L64-74). The editor then reconstructs the visible workflows from that same seeded chain (convertPolicyEmployeesToApprovalWorkflows), so the member's reconstructed submitsTo already equals the stored Classic value.

2. On save, convertApprovalWorkflowToPolicyEmployees emits a submitsTo update only when it differs from what's already in Onyx:

for (const {email} of approvalWorkflow.members) {
    const submitsTo = ... firstApprover.email ...

    if (previousEmployeeList[email]?.submitsTo === submitsTo) {
        continue; // no update queued -> Classic submitsTo persists
    }
}

When the reconstructed value matches the seeded Classic value, no employee update is queued for that member, and the report keeps resolving its manager from the untouched Classic chain.

I want to be honest about the limit of my confidence: reproduction is blocked and the persisted routing is ultimately owned by the migration on the server. I can firmly cite the read chain and the no-op skip above, but I can't prove from source alone whether the migration seeds approvalMode/submitsTo inconsistently versus the NewDot save under-writing them. Both reduce to the same defect — the migrated employeeList/approvalMode is out of sync with what the NewDot editor shows and edits.

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

Fix layer is the workflow-save data path, not rendering.

• In convertApprovalWorkflowToPolicyEmployees, stop treating a matching submitsTo as a guaranteed no-op for migrated policies. Emit the submitsTo/forwardsTo for every member and approver in the edited workflow so the API payload authoritatively rewrites the chain instead of assuming the seeded value is already correct server-side.

• Confirm approvalMode is written on save the same way importPolicyMembers bumps it to ADVANCED when a submit/forward chain exists (Member.ts L1040-1051). If getApprovalWorkflow still returns the Classic mode, routing skips the NewDot approver regardless of submitsTo.

• Raise the seeding with the migration owners: the migration must write submitsTo/forwardsTo/approvalMode that match what the NewDot editor presents, since the App only mirrors those fields.

Edge cases touched: the offline optimistic managerID is computed from the same chain, so it will keep showing the Classic approver until the chain is rewritten (not just an eventual server correction); and the default workflow attaches members implicitly via the default approver rather than an explicit submitsTo, so its members must be handled when forcing the rewrite.

What alternative solutions did you explore? (Optional)

• Patch the next-step/display layer (getApprovalWorkflow, buildOptimisticNextStep). Rejected: those functions only render who should act; the report's actual managerID is resolved from employeeList.submitsTo, so changing the displayed next step leaves the real approval route pointed at the Classic approver.

• Force the correct approver through the invite path (addMembersToWorkspace, Member.ts L853-865) which defaults submitsTo to getDefaultApprover(policy). Rejected: migrated members already exist on the policy and never pass through the invite flow, so this code never runs for them.

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

Migrated users can keep a stale Classic approval submitsTo value in policy.employeeList. New Expensify’s workflow UI skips employees whose submitsTo points to a user that is not in the current policy employee list, so that stale Classic route is not represented as an editable workflow (convertPolicyEmployeesToApprovalWorkflows continues when submitsTo is missing or not in employees: https://github.com/Expensify/App/blob/main/src/libs/WorkflowUtils.ts#L169-L188). However, report submission still trusts policy.employeeList[submitterLogin].submitsTo as the approval manager for advanced workflows (getManagerAccountEmail returns employee?.submitsTo before falling back to the New Expensify default approver: https://github.com/Expensify/App/blob/main/src/libs/PolicyUtils.ts#L1721-L1734). That value is then used by getSubmitReportManagerAccountID() and passed to SubmitReport as managerAccountID during submit (https://github.com/Expensify/App/blob/main/src/libs/actions/IOU/ReportWorkflow.ts#L1381-L1387), so a hidden migrated Classic approver can still control the submitted report route.

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

Update the policy approval-route helpers so advanced approval routing only uses employee.submitsTo when it points to a valid current New Expensify approval target. In practice, getManagerAccountEmail() should fall back to the policy default approver when the submitter’s submitsTo is empty or points to a login that is not present in policy.employeeList and is not an HR-derived final approver. This makes the submit path match the workflow source of truth that New Expensify can actually display/edit.

Also adjust getSubmitReportManagerAccountID() so its hasReliablePolicyRoute check does not treat the mere existence of policy.employeeList[submitterLogin] as reliable when that employee has an orphaned submitsTo value (https://github.com/Expensify/App/blob/main/src/libs/PolicyUtils.ts#L1758-L1779). It should rely on the resolved, valid submit target from getSubmitToAccountID() instead. That keeps migrated stale Classic data from being passed as managerAccountID to SubmitReport.

What alternative solutions did you explore? (Optional)

I also considered fixing this only in the workflow editor by forcing migrated/orphaned members into the visible workflow list, but that would still leave the submit source of truth able to route reports through stale Classic data if another path submits before the admin edits the workflow.

[aswin-s]

Note: This proposal is not a duplicate. It identifies a deeper root cause rather than the surface symptom.

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user migrated from Expensify Classic to New Expensify submits a report, the report is routed to the Classic-era approver instead of the approver configured in the New Expensify workspace. This affects Web (Chrome/Safari on Windows and macOS).

What is the root cause of that problem?

In src/libs/PolicyUtils.ts:1758-1780, getSubmitReportManagerAccountID computes:

const hasReliablePolicyRoute =
    ([CONST.POLICY.APPROVAL_MODE.OPTIONAL, CONST.POLICY.APPROVAL_MODE.BASIC]).includes(getApprovalWorkflow(policy)) ||
    !!ruleApprover ||
    !!policy?.employeeList?.[submitterLogin ?? ''];

For a migrated workspace:

1. getApprovalWorkflow(policy) → ADVANCED (not OPTIONAL/BASIC) → first arm false.
2. No approval rules configured in NE → ruleApprover = '' → second arm false.
3. policy?.employeeList?.[submitterLogin ?? '']: if the submitter's email is absent from the NE employeeList or the Classic-stored email differs in case from the NE-keyed email, this lookup returns undefined → third arm false.

Result: hasReliablePolicyRoute = false.

The code then hits line 1776-1778 — the second if block:

if (!hasReliablePolicyRoute && isValidExistingManagerID) {
    return existingManagerID;  // ← stale Classic approver returned here
}

This returns the Classic managerID even when isValidSubmitToAccountID is true (i.e., getSubmitToAccountID successfully resolved a valid New Expensify approver via policy.approver || policy.owner). The Classic manager wins over the valid NE route.

Note: the final line return isValidSubmitToAccountID ? submitToAccountID : existingManagerID (line 1780) is not reached in the common case where isValidExistingManagerID = true; the bug fires at line 1776-1778.

submitReport in src/libs/actions/IOU/ReportWorkflow.ts uses the returned value directly as submitReportManagerAccountID → managerID, which is written to the optimistic report update and passed as managerAccountID in the SubmitReport API call.

submitMoneyRequestOnSearch in src/libs/actions/Search.ts:1037 follows the identical pattern and is also affected.

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

Fix 1 — src/libs/PolicyUtils.ts:1776 — stop preferring Classic fallback when a valid NE route exists:

Change the second guard from:

if (!hasReliablePolicyRoute && isValidExistingManagerID) {
    return existingManagerID;
}

to:

if (!hasReliablePolicyRoute && !isValidSubmitToAccountID && isValidExistingManagerID) {
    return existingManagerID;
}

This preserves the intent (fall back to Classic when NE genuinely has no configured route) while no longer silently discarding a valid NE submitToAccountID.

Fix 2 — src/libs/PolicyUtils.ts:1770 — normalize submitterLogin email case before employeeList lookup:

Change:

!!policy?.employeeList?.[submitterLogin ?? '']

to:

!!policy?.employeeList?.[(submitterLogin ?? '').toLowerCase()]

And mirror the same normalization in getManagerAccountEmail at line 1729:

const employee = policy?.employeeList?.[(ownerLogin ?? '').toLowerCase()];

Classic-migrated emails can differ in case from their NE employeeList keys; without this, case differences cause hasReliablePolicyRoute to stay false and the submitter's configured submitsTo to be missed entirely.

Fix 3 (verification, no code change) — src/libs/actions/IOU/ReportWorkflow.ts and src/libs/actions/Search.ts:

managerID in submitReport is set to submitReportManagerAccountID when no manual manager email is provided. After fixes 1 and 2 above, submitReportManagerAccountID will now correctly return the NE approver, so this propagates into managerID, the optimistic report's managerID, optimisticNextStepApproverID, and the SubmitReport API parameter without any additional change.

What alternative solutions did you explore? (Optional)

• Broaden hasReliablePolicyRoute for ADVANCED + non-empty employeeList: rejected because a non-empty employeeList does not guarantee the specific submitter has a configured route. The fix at line 1776 is more precise: only fall back to Classic if NE's computed route is actually invalid.
• Clear expenseReport.managerID at migration time: a valid backend/migration fix, but out of scope for a frontend-only fix; the frontend should route correctly regardless of what value was migrated on the report.
• Always ignore existingManagerID: too aggressive; there are valid non-migration cases where existingManagerID is the correct fallback when no NE route is configured at all.

[melvin-bot]

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