[$250] Per diem - Expense report opens after creating distance expense from report preview

[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: 9.3.77-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-31426/folder/13176674/41236543/1424363464?sort=-identifier
Email or phone of affected tester (no customers): sdsdjoijdoisnjodis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Workspace has per diem rates.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an empty report,
4. On the empty report preview, click Add expense > Create expense > Per diem.
5. Create a per diem expense.

Expected Result:

After creating per diem expense from report preview, app will stay in workspace chat (similar to Manual, Scan and Distance expense).

Actual Result:

After creating per diem expense from report preview, app opens expense report.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7158091_1779203764470.4.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056761743835370498
• Upwork Job ID: 2056761743835370498
• Last Price Increase: 2026-05-19
• Automatic offers:
• MobileMage | Contributor | 111487982

Issue Owner

Current Issue Owner: @MobileMage

[MelvinBot]

Proposal

What is the root cause of that problem?

When creating an expense from a report preview in workspace chat, the workspace chat's reportID is passed as backToReport so the app knows where to navigate back to after creation. For regular expenses (manual, scan, distance), requestMoney uses backToReport ?? activeReportID as the navigation target, correctly returning the user to workspace chat.

For per diem expenses, two things go wrong:

1. The per diem intermediate steps (Destination → Time → Subrate) don't thread backToReport through their routes, so it's lost before reaching the confirmation step. See IOURequestStepSubrate.tsx:162 — it navigates to confirmation without passing backToReport.

2. Even if backToReport reached confirmation, the per diem submission path in useExpenseSubmission.ts:476 calls navigateAfterExpenseCreate with only activeReportID (the expense report), ignoring backToReport entirely — unlike the regular expense path.

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

In useExpenseSubmission.ts, change the per diem navigation to use backToReport when available, matching the pattern used by regular expenses:

activeReportID  →  backToReport ?? activeReportID

This is sufficient because backToReport is already available at the confirmation step via the MONEY_REQUEST_CREATE parent route (it doesn't need to be threaded through the per diem sub-steps since confirmation reads it from the parent route params at IOURequestStepConfirmation.tsx:453).

What alternative solutions did you explore? (Optional)

An alternative would be to add backToReport as a route parameter to all per diem intermediate routes (STEP_DESTINATION, STEP_TIME, STEP_SUBRATE) and thread it through each navigation step. This is more invasive and unnecessary since the confirmation step already has access to backToReport from its parent route — the fix only needs to ensure the per diem submission handler actually uses it.

---

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.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

When creating a per diem expense from a report preview, the navigation logic after submission navigates the user into the expense report instead of staying in the workspace chat. This differs from Manual, Scan, and Distance expense flows which correctly return to the originating chat. The per diem submission path likely calls a different navigation handler or lacks the backTo / reportID param guard that the other flows use.

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

I'd look at the per diem expense creation completion handler in src/libs/actions/IOU.ts (or the relevant per diem page under src/pages/iou/). The other expense types pass the original reportID so that after creation the app navigates back to that report's chat rather than opening the newly created expense report. The fix is to ensure the per diem flow passes the same backTo route or uses Navigation.goBack() / Navigation.navigate(ROUTES.REPORT.getRoute(linkedReportID)) consistently with the other flows.

- // Per diem completion — navigates to new expense report
- Navigation.navigate(ROUTES.REPORT.getRoute(expenseReportID));
+ // Stay in originating report, same as Manual/Scan/Distance
+ if (backTo) {
+     Navigation.goBack(backTo);
+ } else {
+     Navigation.navigate(ROUTES.REPORT.getRoute(linkedReportID));
+ }

This ensures that when a per diem is created from a report preview, the user is returned to the workspace chat (the linkedReportID) rather than being pushed into the newly created expense report.

What alternative solutions did you explore?

I considered adding a dedicated isCreatedFromReportPreview flag, but reusing the existing backTo/linkedReportID pattern already present in other IOU flows is cleaner and more consistent.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-19 15:42:21 UTC.

Proposal

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

Creating a Per Diem expense from a report preview's "Add expense" menu opens the expense report afterwards, instead of staying in the workspace chat like Manual, Scan, and Distance do.

What is the root cause of that problem?

In useExpenseSubmission.ts, the per diem branch calls navigateAfterExpenseCreate with activeReportID only, ignoring the backToReport param that the report-preview flow sets to the workspace chat report ID. Because report here is the IOU/expense report (the preview's host), activeReportID resolves to the expense report and that's what we end up on.

App/src/pages/iou/request/step/confirmation/useExpenseSubmission.ts

Lines 475 to 482 in e8c6aa8

	if (shouldHandleNav && result && activeReportID) {
	navigateAfterExpenseCreate({
	activeReportID,
	transactionID: transaction.transactionID,
	isFromGlobalCreate: transaction.isFromFloatingActionButton ?? transaction.isFromGlobalCreate,
	hasMultipleTransactions: reportTransactions.length > 0,
	});
	}

Manual (requestMoney) and Distance (createDistanceRequest) avoid this by forwarding backToReport into their IOU action, which then does backToReport ?? activeReportID before navigating:

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

Lines 1886 to 1892 in e8c6aa8

	if (shouldHandleNavigation) {
	handleNavigateAfterExpenseCreate({
	activeReportID: backToReport ?? activeReportID,
	transactionID: transaction.transactionID,
	isFromGlobalCreate,
	});
	}

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

In the per diem branch of submitPerDiemExpense inside useExpenseSubmission.ts, pass backToReport ?? activeReportID as the activeReportID argument to navigateAfterExpenseCreate so the post-submit navigation lands on the workspace chat when the flow was launched from a report preview, matching the behavior of Manual, Scan, and Distance.

What alternative solutions did you explore? (Optional)

An alternative is to centralize the fix at the consumer by aligning IOURequestStepConfirmation.tsx's destinationReportID computation with the same "where is the user actually viewing right now" logic that useExpenseSubmission.submitPerDiemExpense already uses for its activeReportID. The two currently disagree when backToReport is missing:

• Slow path (useExpenseSubmission.ts:434): isExpenseReport && Navigation.getTopmostReportId() === report?.reportID ? report.reportID : chatReportID — correctly picks the parent chat when the user is on the workspace chat.
• Fast path / pre-insert (IOURequestStepConfirmation.tsx:453): backToReport ?? report?.reportID ?? selfDMReportID — falls to the expense report when backToReport is missing.

Making them agree (when report is a money request report and the user is not viewing it, fall back to report?.chatReportID):

const isMRReport = isMoneyRequestReport(report);
const destinationReportID = backToReport ?? (isMRReport && Navigation.getTopmostReportId() !== report?.reportID ? report?.chatReportID : report?.reportID) ?? selfDMReportID;

This fixes the bug at the single point where the navigation decision is actually made (the SubmitExpenseOrchestrator pre-insert reads destinationReportID), without touching the route layer or threading backToReport through the per-diem step routes. It also makes the behavior robust to any future flow that drops backToReport for similar reasons. Combined with the primary backToReport ?? activeReportID change above (which still helps the slow shouldHandleNavigation=true path for consistency with Manual/Scan/Distance), both navigation paths now honor the same intent.

[wildan-m]

Proposal

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

When a user creates a Per diem expense via Add expense > Create expense > Per diem from an empty report preview in a workspace chat, the app opens the resulting expense report after submission. The same flow performed with Manual, Scan, or Distance expenses correctly leaves the user in the workspace chat (the screen they started from).

What is the root cause of that problem?

The Add expense dropdown rendered on a report preview in the workspace chat (ReportPreviewActionButton) calls getAddExpenseDropdownOptions and provides iouRequestBackToReport: chatReportID. When the user picks Create expense, this gets passed into startMoneyRequest(...) as the backToReport argument and is then propagated as a route param through every IOU step screen and into IOURequestStepConfirmation, which forwards it to useExpenseSubmission as backToReport.

App/src/components/ReportActionItem/MoneyRequestReportPreview/ReportPreviewActionButton.tsx

Lines 202 to 228 in e8c6aa8

	if (reportPreviewAction === CONST.REPORT.REPORT_PREVIEW_ACTIONS.ADD_EXPENSE) {
	return (
	<ButtonWithDropdownMenu
	onPress={() => {}}
	shouldAlwaysShowDropdownMenu
	customText={translate('iou.addExpense')}
	options={getAddExpenseDropdownOptions({
	translate,
	icons: expensifyIcons,
	iouReportID: iouReport?.reportID,
	policy,
	userBillingGracePeriodEnds,
	draftTransactionIDs,
	amountOwed,
	ownerBillingGracePeriodEnd,
	iouRequestBackToReport: chatReportID,
	unreportedExpenseBackToReport: iouReport?.parentReportID,
	lastDistanceExpenseType,
	})}
	isSplitButton={false}
	anchorAlignment={{
	horizontal: CONST.MODAL.ANCHOR_ORIGIN_HORIZONTAL.RIGHT,
	vertical: CONST.MODAL.ANCHOR_ORIGIN_VERTICAL.BOTTOM,
	}}
	sentryLabel={CONST.SENTRY_LABEL.REPORT_PREVIEW.ADD_EXPENSE_BUTTON}
	/>
	);

App/src/libs/ReportUtils.ts

Lines 2957 to 2973 in e8c6aa8

	return [
	{
	value: CONST.REPORT.ADD_EXPENSE_OPTIONS.CREATE_NEW_EXPENSE,
	text: translate('iou.createExpense'),
	icon: icons.Plus,
	sentryLabel: CONST.SENTRY_LABEL.MORE_MENU.ADD_EXPENSE_CREATE,
	onSelected: () => {
	if (!iouReportID) {
	return;
	}
	if (policy && policy.type !== CONST.POLICY.TYPE.PERSONAL && shouldRestrictUserBillableActions(policy, ownerBillingGracePeriodEnd, userBillingGracePeriodEnds, amountOwed)) {
	Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(policy.id));
	return;
	}
	startMoneyRequest(CONST.IOU.TYPE.SUBMIT, iouReportID, draftTransactionIDs, undefined, false, iouRequestBackToReport);
	},
	},

For Manual, Scan, and Distance the submission flows through requestMoney in TrackExpense.ts, which (after the submission completes) calls the post-create navigation helper with backToReport ?? activeReportID. This is what makes those flows return to the workspace chat — backToReport is the workspace chat report ID, so it overrides whatever activeReportID would otherwise be (which, when the user has been routed through the empty expense report mid-flow, can be the expense report ID).

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

Lines 1883 to 1893 in e8c6aa8

	if (!requestMoneyInformation.isRetry) {
	highlightTransactionOnSearchRouteIfNeeded(isFromGlobalCreate, transaction.transactionID, CONST.SEARCH.DATA_TYPES.EXPENSE);
	if (shouldHandleNavigation) {
	handleNavigateAfterExpenseCreate({
	activeReportID: backToReport ?? activeReportID,
	transactionID: transaction.transactionID,
	isFromGlobalCreate,
	});
	}
	}

For Per diem the submission flows through a different branch of useExpenseSubmission.submitPerDiemExpense, which computes its own activeReportID and then calls navigateAfterExpenseCreate directly — and that call passes activeReportID without ever consulting backToReport:

App/src/pages/iou/request/step/confirmation/useExpenseSubmission.ts

Lines 432 to 483 in e8c6aa8

	const activeReportID = isExpenseReport && Navigation.getTopmostReportId() === report?.reportID ? report?.reportID : chatReportID;
	const result = submitPerDiemExpenseIOUActions({
	report,
	participantParams: {
	payeeEmail: currentUserPersonalDetails.login,
	payeeAccountID: currentUserPersonalDetails.accountID,
	participant,
	},
	policyParams: {
	policy,
	policyTagList: policyTags,
	policyRecentlyUsedTags,
	policyCategories,
	policyRecentlyUsedCategories: policyRecentlyUsedCategoriesParam,
	},
	recentlyUsedParams: {
	destinations: recentlyUsedDestinations,
	},
	transactionParams: {
	currency: transaction.currency,
	created: transaction.created,
	comment: trimmedComment,
	category: transaction.category,
	tag: transaction.tag,
	customUnit: transaction.comment?.customUnit,
	billable: transaction.billable,
	reimbursable: transaction.reimbursable,
	attendees: transaction.comment?.attendees,
	isFromGlobalCreate: transaction.isFromFloatingActionButton ?? transaction.isFromGlobalCreate,
	},
	isASAPSubmitBetaEnabled,
	currentUserAccountIDParam: currentUserPersonalDetails.accountID,
	currentUserEmailParam: currentUserPersonalDetails.login ?? '',
	hasViolations,
	policyRecentlyUsedCurrencies,
	quickAction,
	betas,
	personalDetails,
	optimisticChatReportID,
	conciergeReportID,
	shouldHandleNavigation: shouldHandleNav,
	});
	if (shouldHandleNav && result && activeReportID) {
	navigateAfterExpenseCreate({
	activeReportID,
	transactionID: transaction.transactionID,
	isFromGlobalCreate: transaction.isFromFloatingActionButton ?? transaction.isFromGlobalCreate,
	hasMultipleTransactions: reportTransactions.length > 0,
	});
	}
	}

Because report at this point is the expense report (the user came from the empty report preview, which routes the IOU flow with the expense report as reportID), isExpenseReport is true and Navigation.getTopmostReportId() matches report?.reportID, so activeReportID is set to the expense report's ID. navigateAfterExpenseCreate then calls dismissModalAndOpenReportInInboxTab(activeReportID, ...) which opens that expense report after the modal is dismissed — exactly the wrong-behavior observed in the bug report.

In short: the Per diem path doesn't honor backToReport at the post-submission navigation step, while every other expense type does.

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

Make the Per diem submission honor backToReport the same way Manual/Scan/Distance do, so that when the user starts the flow from a report preview button (which sets backToReport to the workspace chat), they return to the workspace chat after submission.

The minimal change is in src/pages/iou/request/step/confirmation/useExpenseSubmission.ts, inside submitPerDiemExpense, at the navigateAfterExpenseCreate call:

• Update the activeReportID argument passed to navigateAfterExpenseCreate to be backToReport ?? activeReportID instead of just activeReportID. This mirrors the exact pattern that requestMoney in TrackExpense.ts already uses at the same logical point in its flow, so the post-create behavior becomes consistent across all expense types.

backToReport is already in scope inside useExpenseSubmission — it's destructured from params at the top of the hook and is already passed through to requestMoney/trackExpense/createDistanceRequest. The hook just doesn't forward it into the Per diem branch yet. No new prop drilling or signature changes are needed; the value is already available.

The guard shouldHandleNav && result && activeReportID should also be updated so the activeReportID check uses the resolved-with-backToReport value, otherwise a missing activeReportID combined with a present backToReport would skip navigation (an inconsistency vs Manual/Scan/Distance).

After this change, the repro flow plays out as follows:

1. User is in workspace chat.
2. User clicks Add expense > Create expense on the empty report preview — backToReport is set to the workspace chat report ID.
3. User picks Per diem, fills in subrates, submits.
4. submitPerDiemExpense runs, the API write is dispatched, and navigateAfterExpenseCreate is called with activeReportID = backToReport (the workspace chat).
5. dismissModalAndOpenReportInInboxTab dismisses the IOU modal and opens the workspace chat — matching Manual/Scan/Distance.

The Self-DM branch (submitPerDiemExpenseForSelfDM) does not need to change — that branch is only used for Track Expense and there's no backToReport flow into it from this entry point.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/91093-per-diem-back-to-report?expand=1

What alternative solutions did you explore? (Optional)

An alternative would be to extend the IOU action submitPerDiemExpense in src/libs/actions/IOU/PerDiem.ts to accept and use backToReport internally (the way requestMoney does in TrackExpense.ts). That would also work, but it requires adding a new field to PerDiemExpenseInformation and threading it through additional plumbing, while the fix at the useExpenseSubmission layer is a one-spot change at the exact site where the navigation call is made. Both fixes produce the same user-visible behavior; the proposed one is smaller and matches where the existing activeReportID resolution already lives.

[melvin-bot]

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

[melvin-bot]

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

[KJ21-ENG]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).