Submit workspace-Missing receipt modal on confirm page when submitting expense without receipt

[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.34-12
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: #94319
Email or phone of affected tester (no customers): applausetester+sdoisdddndos@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Log in with Expensifail account.
• Account has no workspace.

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create a manual expense without receipt.
4. Click Submit to my employer.

Expected Result:

Confirm page should show receipt modal so user can add a receipt.

Actual Result:

Confirm page is missing receipt modal when submitting manual expense without receipt.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7209310

[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/d14b6bd5e5f385071fddd18754319b45f7def847a380d245100e7ea763a15ab4

[melvin-bot]

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

[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

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

On the confirmation page, the receipt "empty state" (the dropzone/prompt to add a receipt) is missing when a user with no workspace creates a manual expense without a receipt from their self DM and chooses Submit to my employer. This is a regression introduced by #94319, which split "Submit it to someone" into "Submit to a friend" / "Submit to my employer" and added a brand-new SUBMIT path that lands directly on the confirmation page.

What is the root cause of that problem?

The receipt empty state is gated by shouldShowReceiptEmptyState, which for the SUBMIT action only shows when isGroupPolicy(policy) is true:

Gate logic (IOUUtils.ts)

// shouldShowReceiptEmptyState
(iouType === SUBMIT || TRACK || PAY || CREATE) &&
!isPerDiemRequest &&
(!isMovingTransactionFromTrackExpense(action) || isGroupPolicy(policy))

For action === SUBMIT, isMovingTransactionFromTrackExpense returns true, so the empty state hinges entirely on isGroupPolicy(policy).

For this new self-DM → "Submit to my employer" flow, policy resolves to undefined at render time. usePolicyForTransaction returns the self-DM policy (which is undefined for a user with no workspace) whenever the transaction is still unreported, and only falls back to policyDraft in the reported branch:

const policy = isUnreportedExpense || isCreatingTrackExpense ? policyForSelfDMExpense : (reportPolicy ?? policyDraft);

So isGroupPolicy(undefined) === false → shouldShowReceiptEmptyState returns false → the receipt empty state is hidden. The old "Submit to a friend" path always routed through the participant selector where a real group policy was chosen, so policy was always a group policy there — which is why this only regressed for the new employer/draft-workspace path.

Key references (HEAD 763218c)

• Gate call: IOURequestStepConfirmation.tsx:822
• Gate logic: IOUUtils.ts:324-334
• Policy resolution (undefined here): usePolicyForTransaction.ts:50
• Existing draft-submit flag concept: useExpenseSubmission.ts:1002 (isSubmittingExpenseToDraftWorkspace = action === SUBMIT && isDraftPolicy && policy?.type === SUBMIT)
• Introduced by PR: [Submit] Update "Submit to someone" to two options to allow for Submit workspace creation #94319 (merged 2026-07-13)

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

Stop gating the receipt empty state on policy being a fully-hydrated group policy for the new draft-submit flow. Reuse the existing isSubmittingExpenseToDraftWorkspace concept (already added in useExpenseSubmission.ts) and OR it into the empty-state condition so the receipt prompt shows for the "Submit to my employer" / draft-workspace path regardless of whether policy has resolved yet.

Concretely: pass an isSubmittingToDraftWorkspace flag into shouldShowReceiptEmptyState and change the final clause from (!isMovingTransactionFromTrackExpense(action) || isGroupPolicy(policy)) to also allow that flag, then compute it at IOURequestStepConfirmation.tsx:822.

Alternatively, adjust usePolicyForTransaction.ts:50 so the SUBMIT action falls back to policyDraft even when the transaction is still unreported, so policy resolves consistently to the draft submit workspace.

Confidence

Medium-high. The suppression point (isGroupPolicy(policy) gate with action === SUBMIT) is unambiguous, and this path is new in #94319. The one open question is render-timing: whether the draft transaction still reads UNREPORTED on first render (which makes policy undefined). Confirming with a quick repro + a log of iouType, action, policy?.type, transaction?.reportID at the gate line would pin down the exact sub-case.

---

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug (fix lives in Expensify/App)
Causing PR: #94319 - "[Submit] Update "Submit to someone" to two options to allow for Submit workspace creation" by @abzokhattab (High confidence)
Related Issues: StagingDeployCash #96044 (9.4.34 release)

Recommendation: ROLL FORWARD (targeted forward-fix, not revert)

#94319 is a large feature PR (27 files, +341/-73) that ships the entire "Submit to my employer" workspace-creation flow; a revert would be highly disruptive and pull a shipping feature. The bug is a single missing case in the receipt empty-state gating for the new SUBMIT path, which is a narrow, CP-able forward-fix.

Assigned: @abzokhattab (PR author), @hungvu193 and @iwiznia (approving reviewers)
Labels: No change. DeployBlockerCash kept — this is a frontend bug and the App deploy is correctly blocked. No DeployBlocker present to remove.

📋 Detailed Analysis

Evidence

• PR is in this release: [Submit] Update "Submit to someone" to two options to allow for Submit workspace creation #94319 is listed in the open StagingDeployCash Deploy Checklist: New Expensify 2026-07-14 #96044 (New Expensify 2026-07-14, version 9.4.34), matching the reported staging build v9.4.34-12.
• PR introduced the failing flow: The diff of [Submit] Update "Submit to someone" to two options to allow for Submit workspace creation #94319 adds CONST.IOU.SUBMIT_DESTINATION.EMPLOYER, the "Submit to my employer" option, and the routing that lands this flow directly on the confirmation page:
  Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(actionName, CONST.IOU.TYPE.SUBMIT, ...)). Before this PR, submitting from a self DM always went through the participant-selection path, so a self-DM SUBMIT with no workspace never reached the confirmation page.
• Not reproducible in production: This is a brand-new feature that does not exist in prod, consistent with the report (Reproducible in production: N/A - new feature). Staging-only regression, cause is in the current deploy set.

Verification

• Affected file (symptom): src/pages/iou/request/step/IOURequestStepConfirmation.tsx
  • line 187: const {policy} = usePolicyForTransaction({...})
  • line 822: const showReceiptEmptyState = shouldShowReceiptEmptyState(iouType, action, policy, isPerDiemRequest)
• Gate logic: src/libs/IOUUtils.ts:324-334 — for action === SUBMIT, isMovingTransactionFromTrackExpense returns true (line 317), so the empty state depends entirely on isGroupPolicy(policy).
• Policy resolution: src/hooks/usePolicyForTransaction.ts:50
const policy = isUnreportedExpense || isCreatingTrackExpense ? policyForSelfDMExpense : (reportPolicy ?? policyDraft);
  For an unreported self-DM expense with no workspace, policyForSelfDMExpense is undefined, and the policyDraft fallback is only reached in the reported branch. So policy = undefined → isGroupPolicy(undefined) = false → empty state hidden.
• Note on ownership of the hook: usePolicyForTransaction.ts itself was last modified by Part 11 - Thread delegateAccountID through split and inline edit flows #95328, so the fallback logic is pre-existing. However, [Submit] Update "Submit to someone" to two options to allow for Submit workspace creation #94319 is the PR that first drives the new SUBMIT-to-employer/draft-workspace path into this code, exposing the unhandled undefined-policy state. [Submit] Update "Submit to someone" to two options to allow for Submit workspace creation #94319 is the correct owner of the regression.

Root Cause

The new "Submit to my employer" flow routes an unreported self-DM expense straight to the confirmation page. At render time, for a user with no workspace, usePolicyForTransaction returns undefined (the self-DM/moving-expenses policy) because the transaction is unreported, and never falls back to the draft workspace policy. shouldShowReceiptEmptyState gates the SUBMIT empty state on isGroupPolicy(policy), which is false for undefined, so the receipt empty-state / add-receipt prompt is suppressed.

Suggested forward-fix (for the owner)

Make the empty state resolve correctly for the new SUBMIT path, e.g. one of:

• Have usePolicyForTransaction fall back to policyDraft for the unreported SUBMIT-to-employer case (so policy reflects the draft/soon-to-be-created Submit workspace), or
• Adjust shouldShowReceiptEmptyState so the SUBMIT action shows the empty state when a submit/draft-workspace destination is in play even if policy is not yet a group policy.

The author should confirm which is safest given the draft-workspace-creation timing.