[Due for payment 2026-06-24] [Due for payment 2026-06-23] Workflows-User returns to "Approver" selection instead of confirm page after inviting member

[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.4.8-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: #80449
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 / Chrome
App Component: Money Requests

Action Performed:

Prerequisite: User is owner of a "Control" workspace.
Prerequisite 2: Workspace has "Approvals" enabled.
Prerequisite 3: Workspace has at least one member apart from "Owner"

1. Open the staging.new.expensify.com website.
2. Navigate to "Workspaces" > Workspace > "Workflows"
3. Scroll down to "Approvals" and click on "Add approval workflow"
4. On "Expenses From" select the owner.
5. On "Approver" select any member.
6. Click on "Skip"
7. On confirm page, click on "Expenses From"
8. Enter the Email of any existing user that is not member of workspace > "Save" > "Invite"
9. Note that you return to "Approver" page, where approver is still selected instead of returning to confirm page.

Expected Result:

After opening "Expenses From" on confirm page and inviting a new member, user should return to confirm page again.

Actual Result:

After opening "Expenses From" on confirm page and inviting a new member, user is redirected to "Approver" again, where selected user is still displayed as chosen approver.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7181604_1781552328158.Invite_Workflow_6.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Vincenzo Godoy
Bug ID: 7181604

[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/8fab64c6cd74e00a10107e4f3dc81d9888e64a508984af46a1cf21ada63e53a5

[melvin-bot]

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

[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

What is the root cause of that problem?

This is a regression from #80449. After inviting a new member, sendInvitation decides where to go based on whether the expenses‑from URL carries a nested backTo param:

if (nestedBackTo) {  goBack(nestedBackTo)  }   // → confirm page
else                 { navigate(APPROVALS_APPROVER, 0) }  // → Approver page

The nested backTo is only present when the expenses‑from page was opened with a backTo. But handleExpensesFromPress only sets backTo for the EDIT action:

const backTo = approvalWorkflow.action === ACTION.EDIT
    ? WORKSPACE_WORKFLOWS_APPROVALS_EDIT.getRoute(...)
    : undefined;

In the reported flow the workflow is still being created (action === CREATE) — the user reaches the confirm page via "Skip" — so backTo is undefined, nestedBackTo is empty, and the else branch fires, sending the user to the Approver page instead of back to the confirm page.

This is why Test 2 in the PR (EDIT an existing workflow) works but this scenario (confirm page during initial creation) does not.

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

In ApprovalWorkflowEditor.handleExpensesFromPress, also set a backTo for the create/confirm case so the post‑invite navigation returns to the confirm page. For CREATE, point it at ROUTES.WORKSPACE_WORKFLOWS_APPROVALS_NEW.getRoute(policyID) (the confirm page) instead of leaving it undefined.

This cleanly preserves both flows:

• Invite from the very first expenses‑from step (Test 1 — page opened from the Workflows list, no backTo) → else branch still runs → user proceeds to the Approver page. ✅
• Invite after re‑opening expenses‑from from the confirm page (this bug) → nestedBackTo is now set → goBack returns to the confirm page. ✅

What alternative solutions did you explore? (Optional)

Alternatively, change the else fallback in sendInvitation to goBack() rather than hard‑navigating to the Approver page — but that risks the genuine first‑step flow (Test 1), so scoping the fix to handleExpensesFromPress is safer.

Related sibling deploy blockers (same PR #80449)

These were all filed against #80449 and touch the same invite‑in‑workflow flow — worth coordinating fixes/revert:

• [Due for payment 2026-06-24] [Due for payment 2026-06-23] Workflow - Different level of opacity seen on workflows fields after inviting member offline #93637 — different opacity on workflow fields after inviting offline
• [Due for payment 2026-06-24] [Due for payment 2026-06-23] iOS - Workflows - Invite confirm page opens after inviting member and swiping back #93632 — iOS confirm page opens after inviting + swipe back
• [Due for payment 2026-06-24] [Due for payment 2026-06-23] Workflow - Invited phone number appears twice in Expenses from list #93621 — invited phone number appears twice in Expenses from list

---

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