[$250] Confirm details page opens instead of participant page

[jponikarchuk]

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: v9.3.51-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #86505
Email or phone of affected tester (no customers): applausetester+ck33126@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11/Chrome
App Component: Money Requests

Action Performed:

Prerequisite:

1. Create new expensifail account
2. Have a default workspace with distance rate enabled
3. Have odometer beta

Steps:

1. Navigate to staging.new.expensify.com
2. Press the global create button > Create expense > Manual
3. Enter any amount and go next
4. Observe it goes to the confirm details page
5. Go back and switch to Scan
6. Add an image and go next
7. Observe it goes to the confirm details page
8. Close the RHP
9. Press the global create button > Track distance > Map
10. Enter any waypoints and go next
11. Observe it goes to the confirm details page
12. Go back and switch to Manual
13. Enter any amount and go next
14. Observe it goes to the confirm details page
15. Go back and switch to Odometer
16. Enter any amount and go next
17. Observe it goes to the confirm details page

Expected Result:

On steps 4, 7, 11, 14, 17 - Participant page should open

Actual Result:

On steps 4, 7, 11, 14, 17 - Confirm details page opens instead of participant page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @Ollyws

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022039286582426405710
• Upwork Job ID: 2039286582426405710
• Last Price Increase: 2026-04-22

[MelvinBot]

Proposal

What is the root cause of that problem?

When a user creates an expense from the global + menu (which sets iouType = CONST.IOU.TYPE.CREATE), the navigation logic in every expense-creation step (Manual, Scan, Distance Map, Distance Manual, Odometer) calls shouldUseDefaultExpensePolicy() to decide whether to show the participant page or skip directly to the confirmation page.

shouldUseDefaultExpensePolicy returns true when all of these conditions are met:

1. iouType === CONST.IOU.TYPE.CREATE
2. The user's default expense policy is a paid group policy (TEAM or CORPORATE type)
3. The policy has isPolicyExpenseChatEnabled === true
4. The user is not billing-restricted (!shouldRestrictUserBillableActions(...))

When shouldUseDefaultExpensePolicy returns true, the code auto-assigns the default workspace as the participant and navigates directly to the confirmation page, completely skipping participant selection. This branching logic exists in three independent locations:

• IOURequestStepAmount.tsx:332 (manual flow)
• MoneyRequest.ts:521 (scan flow)
• MoneyRequest.ts:751 (distance/odometer flows)

For the reproduction case (new account with a default paid workspace, no billing issues), all four conditions are satisfied, so the participant page is always skipped.

While this issue was discovered during QA of PR #86505, the behavior is pre-existing since shouldUseDefaultExpensePolicy was introduced (Jan 22, 2026). PR #86505 changed how billing grace period data is passed (from a deprecated module-level Onyx subscription to explicit useOnyx hook values), but for users without billing restrictions, the return value of shouldRestrictUserBillableActions is false in both the old and new approach — so the navigation behavior is unchanged.

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

The fix depends on the intended product behavior for the CREATE expense flow:

Option A — Always show participant page for CREATE flow:
Remove iouType === CONST.IOU.TYPE.CREATE from shouldUseDefaultExpensePolicy (which would make the function always return false since CREATE is the only iouType it accepts). Effectively, this disables the auto-assign/skip-participants feature entirely. The participant page would always be shown when creating from the global + menu.

Option B — Only auto-assign when user has exactly one workspace:
Add an additional condition to shouldUseDefaultExpensePolicy that only returns true when the user has exactly one accessible paid group policy. The useDefaultExpensePolicy hook already has logic to return a single policy, but it also returns a policy when there's an active/preferred policy even if the user has multiple workspaces. The fix would be to pass additional context indicating whether the user has multiple workspaces and only skip participants when there's truly only one choice.

I'd recommend Option A as the simplest and safest approach — the participant page is lightweight and gives users full control over where their expense goes. The change would be in shouldUseDefaultExpensePolicy.ts to return false always (or remove the function and its callers), ensuring navigateToParticipantPage() is called in all three locations.

What alternative solutions did you explore? (Optional)

An alternative is to keep the auto-assign behavior but add a way for users to go back from the confirmation page to change the participant. However, this adds complexity and doesn't match the expected flow described in the issue.

---

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.

Cat fact: Cats can rotate their ears 180 degrees using 32 muscles in each ear — far more than the six muscles humans have for the same job.

[melvin-bot]

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

[melvin-bot]

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

[surafeal-dev]

Proposal: Always show participant selection for “Create expense” flow

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

When a user creates an expense from the global + menu (i.e., iouType = CONST.IOU.TYPE.CREATE), the expense creation flow can skip the participant selection step and navigate directly to confirmation.

This is unexpected because “Create expense” is a user-initiated flow where the user should be able to choose who / which workspace the expense is for. Skipping participants removes that control and can silently route the expense to the user’s default workspace.

This behavior occurs across multiple creation entry points/steps (manual, scan, distance, odometer), so it’s easy to reproduce and hard for users to understand or correct.

What is the root cause of that problem?

The navigation logic for the CREATE flow relies on shouldUseDefaultExpensePolicy() to decide whether to auto-assign a workspace and skip the participant page.

shouldUseDefaultExpensePolicy() returns true when all of the following are met (see src/libs/shouldUseDefaultExpensePolicy.ts):

• iouType === CONST.IOU.TYPE.CREATE
• The user’s default expense policy is a paid group policy (TEAM/CORPORATE)
• The policy has isPolicyExpenseChatEnabled === true
• The user is not billing-restricted (!shouldRestrictUserBillableActions(...))

When it returns true, the flow auto-assigns the default workspace as the participant and routes directly to confirmation, bypassing participant selection.

This branching logic is duplicated in three independent call-sites, which means the skip behavior is consistently applied across flows:

• Manual amount step: src/pages/iou/request/step/IOURequestStepAmount.tsx
• Scan flow: src/libs/actions/IOU/MoneyRequest.ts
• Distance/odometer flows: src/libs/actions/IOU/MoneyRequest.ts

So for a reproduction case like “new account + default paid workspace + expense chat enabled + no billing issues,” all conditions are satisfied and the participant page is always skipped.

Note: This issue was observed during QA of PR #86505, but the behavior predates that PR. PR #86505 changed how billing/grace-period inputs are sourced, but for users without billing restrictions the return value remains false either way, so the navigation path is unchanged.

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

The correct fix depends on the intended product behavior for iouType=CREATE.

Recommended (Option A): Always show participant page for CREATE

Make “Create expense” always require an explicit participant selection.

Implementation approach:

• Update shouldUseDefaultExpensePolicy() (or stop calling it for CREATE) so it does not cause CREATE flows to skip participants.
• Update all three call-sites to always navigate through the participant step for CREATE.

This is the simplest behavioral contract:

• CREATE = user chooses where the expense goes.
• Auto-assignment does not occur silently.

Acceptance criteria

• Starting “Create expense” from the global + menu always shows the participant page (manual, scan, distance map, distance manual, odometer).
• No default workspace is auto-selected unless the user explicitly chooses it.
• Existing non-CREATE flows are unchanged.

Alternative (Option B): Only auto-assign when there is exactly one workspace choice

If the original goal was to reduce friction, we can keep skipping participants only when there is truly no choice.

Implementation approach:

• Extend the logic behind shouldUseDefaultExpensePolicy() to return true only when the user has exactly one accessible paid group policy.
• Ensure “preferred/active policy” does not cause skipping when the user has multiple workspaces.

This preserves a fast path for single-workspace users while avoiding surprising behavior for multi-workspace users.

What alternative solutions did you explore? (Optional)

Leave current behavior and add a UI affordance on confirmation

For example, add an “Edit participant/workspace” action on the confirmation step.

This is not ideal because the default selection is still silent and users can miss that they need to correct it.

Centralize the navigation decision

Deduplicate the three call-sites by creating a single helper that decides the next route for all CREATE flows.

This would reduce maintenance risk, but it’s orthogonal to the core issue: even with centralization, the CREATE flow should not unexpectedly skip participant selection unless that behavior is explicitly desired.

[nkdengineer]

I think it's not a bug. In this PR #86505, the user is billing-restricted, then the participant page appears cc @bernhardoj . For the tester account, the billing is not ended then the confirmation page appears.

[trasnake87]

Proposal

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

When creating an expense from the global "+" menu (Create expense or Track distance), users are taken directly to the confirm details page instead of the participant selection page, even though they haven't chosen a recipient yet.

What is the root cause of that problem?

The confirm details page (IOURequestStepConfirmation.tsx) lacks a guard to redirect users to the participant page when participants were silently auto-assigned during a global create flow. The existing guard at line 501-515 only redirects when there are no participants, but in this bug the participants have already been auto-assigned by the time the confirmation page renders. Additionally, when proceeding from the participant page to confirmation, IOURequestStepParticipants.tsx at line 354 does not pass the participantsAutoAssigned route parameter, preventing the confirmation page from distinguishing between auto-assigned and user-confirmed navigation.

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

We should add a guard in IOURequestStepConfirmation.tsx to redirect to the participant page when participants were auto-assigned in a global create flow, and update IOURequestStepParticipants.tsx to pass participantsAutoAssigned=true in the route so the guard knows the user has explicitly confirmed their selection.

In src/pages/iou/request/step/IOURequestStepConfirmation.tsx, expand the useEffect at ~line 501:

useEffect(() => {
    if (!!isLoadingTransaction) {
        return;
    }
    // Redirect to participant page when participants were auto-assigned from default policy
    if (transaction?.transactionID && transaction?.isFromGlobalCreate && 
        transaction?.participantsAutoAssigned && participantsAutoAssignedFromRoute !== 'true') {
        Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_PARTICIPANTS.getRoute(
            iouType, initialTransactionID, reportID, undefined, action));
        return;
    }
    if (transaction?.transactionID && (!transaction?.isFromGlobalCreate || !isEmptyObject(transaction?.participants))) {
        return;
    }
    startMoneyRequest(iouType ?? CONST.IOU.TYPE.CREATE, reportID ?? generateReportID(), draftTransactionIDs);
}, [isLoadingTransaction]);

In src/pages/iou/request/step/IOURequestStepParticipants.tsx, update goToNextStep at ~line 354:

const iouConfirmationPageRoute = ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(
    action,
    iouType === CONST.IOU.TYPE.CREATE || iouType === CONST.IOU.TYPE.TRACK ? CONST.IOU.TYPE.SUBMIT : iouType,
    initialTransactionID,
    newReportID,
    undefined,
    true,  // participantsAutoAssigned: user explicitly confirmed
    action === CONST.IOU.ACTION.SHARE ? Navigation.getActiveRoute() : undefined,
);

This centralized approach catches all three entry paths (manual amount, scan receipt, distance) at the confirmation page level, using the existing participantsAutoAssigned route parameter to prevent redirect loops.