[$250] Custom IS "export failed" in ND

[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.4.41-4
Reproducible in staging?: Needs reproduction (Unable to reproduce)
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: @abbagail
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Go to Spend > reports
2. Select a report and open it
3. Click More > Export > Select custom IS template

Expected Result:

Get a message about the export running in the back end and will complete shortly.

Actual Result:

Errors out:
Export Failed
Your Export could not be completed. Please Try again later.

If we switch back to Classic, the export works with no issue, and all columns are available.

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

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022080356732002889330
• Upwork Job ID: 2080356732002889330
• Last Price Increase: 2026-07-23

Issue Owner

Current Issue Owner: @cristipaval

[MelvinBot]

Issue Analysis

Root Cause: This is a backend failure, not a NewDot UI bug. When you pick a custom IS template from More > Export, NewDot fires the QueueExportSearchWithTemplate API command. The frontend only shows "Export failed / Your export could not be completed. Please try again later." when that command comes back with a failure response — there is no frontend-only or offline path that produces this modal. So the export is being rejected server-side while the async/queued custom-template export runs. That it works in Classic with all columns present points to a difference in how the queued custom IS template is resolved/run on the backend, not to the App code.

Recommended next step: This needs an internal investigation by an engineer with backend access — the fix is outside the Expensify/App repo. To pin the exact cause, pull production logs for the QueueExportSearchWithTemplate command for the affected user/policy around v9.4.41-4 and read the returned jsonCode/error (QA couldn't reproduce, so it's likely specific to a particular saved custom template, policy, or its columns).

Investigation details (frontend flow, confirmed in code)

App checkout SHA: ad661b29f8c91c3fbb0b73db97644cf4c3bb5ab4

1. The More > Export menu lists custom IS templates and dispatches the export — src/hooks/useExportActions.ts:198-208. Custom IS templates come from the integration-server export templates NVP and are typed as INTEGRATIONS.
2. Selecting one calls beginExportWithTemplate → src/hooks/useExportActions.ts:106-129. Note: offline is handled by a separate "you appear to be offline" modal, so the "Export failed" modal is not the offline fallback.
3. That calls queueExportSearchWithTemplate, which sends the QueueExportSearchWithTemplate write command — src/libs/actions/Search.ts:1496-1542. It optimistically sets the export state to PREPARING (the expected "export is running" message) and sets FAILED only in failureData — i.e. only when the API returns a failure.
4. On failure, the modal renders the reported copy — src/components/ExportDownloadStatusModal.tsx:178-190 using strings at src/languages/en.ts:10400-10401 (failedTitle: 'Export failed', csvFailedBody: 'Your export could not be completed. Please try again later.') — which match the report verbatim.

Confidence: Medium. The mechanism (App only shows this modal on a backend failure response) is confirmed in code with high confidence. The specific backend cause is unconfirmed because production logs weren't available in this run — hence the log query recommended above.

Possibly related: #89388 (Custom Export Template Truncates GL Codes in New Expensify vs Classic) — also a custom-template-vs-Classic discrepancy, though a different symptom (truncation, not failure).

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

[mukhrr]

Proposal

What is the root cause of that problem?

The "Export failed / Your export could not be completed. Please try again later." dialog in the report is the export download-status modal in its FAILED state:

App/src/components/ExportDownloadStatusModal.tsx

Lines 178 to 191 in 5ca7950

	if (isFailed) {
	const resolvedFailedBody = failedBody ?? (exportType === CONST.EXPORT_DOWNLOAD.TYPE.CSV ? translate('exportDownload.csvFailedBody') : translate('exportDownload.pdfFailedBody'));
	return (
	<>
	<Text style={[styles.exportDownloadTitle, styles.mb2]}>{translate('exportDownload.failedTitle')}</Text>
	{!!resolvedFailedBody && <Text style={styles.mb5}>{resolvedFailedBody}</Text>}
	<Button
	text={translate('exportDownload.close')}
	onPress={onClose}
	style={styles.w100}
	/>
	</>
	);
	}

That state can only be reached when the export was queued with progress tracking, because tracking is what writes nvp_exportDownload_<id> and attaches the failureData that flips it to FAILED. Tracking is also what adds exportID to the request:

App/src/libs/actions/Search.ts

Lines 1528 to 1537 in 5ca7950

	const finalParameters = enhanceParameters(WRITE_COMMANDS.QUEUE_EXPORT_SEARCH_WITH_TEMPLATE, {
	templateName,
	templateType,
	jsonQuery,
	reportIDList,
	transactionIDList,
	policyID,
	exportName,
	...(shouldTrackExportProgress ? {exportID} : {}),
	}) as QueueExportSearchWithTemplateParams;

And exportID is exactly the flag that switches the backend off the asynchronous delivery custom Integration Server templates depend on:

App/src/libs/API/parameters/QueueExportSearchWithTemplateParams.ts

Lines 4 to 8 in 5ca7950

	/**
	* Identifier for the export download status flow (nvp_exportDownload_<id>). Only sent by callers that render
	* ExportDownloadStatusModal; when omitted, the backend keeps the legacy "Concierge will send" behavior.
	*/
	exportID?: string;

The report export path, however, turns tracking on unconditionally — for the two built-in integrations templates, for in-app CSV layouts, and for custom IS templates alike:

App/src/hooks/useExportActions.ts

Lines 116 to 128 in 5ca7950

	const exportID = queueExportSearchWithTemplate(
	{
	templateName,
	templateType,
	jsonQuery: '{}',
	reportIDList: [moneyRequestReport.reportID],
	transactionIDList,
	policyID,
	exportName,
	},
	true,
	);
	trackExport(exportID);

So a custom IS template is sent down a synchronous download flow it can never satisfy: the Integration Server builds those exports in the background and delivers them through Concierge, so there is no file for the download-status flow to hand back. Any rejection of the queue call then lands in failureData and surfaces as "Export failed" rather than the background-export confirmation the user expects.

This is a regression from bafa623, which removed the export.exportInProgress / export.conciergeWillSend confirmation from this hook and replaced it with the tracked modal for every template. Those two strings are still present in all ten language files but currently have no consumer anywhere in src/.

I verified this end to end on web. Because a custom IS template is created outside the app, I seeded one into Onyx directly (IndexedDB OnyxDB → keyvaluepairs, key nvp_expensify_integrationServerExportTemplates, value [{name: 'My Custom IS Template'}]) and it appeared in More → Export on a report. Selecting it on current main sent exportID in QueueExportSearchWithTemplate and rendered the exact dialog from the bug report; with the change below, the same click omits exportID and shows "Export in progress / Concierge will send you the file shortly."

The two other surfaces that queue template exports share the same unconditional tracking, so they have the same defect:

App/src/hooks/useSearchBulkActions.ts

Lines 630 to 660 in 5ca7950

	let exportID: string;
	if (areAllMatchingItemsSelected) {
	exportID = queueExportSearchWithTemplate(
	{
	templateName,
	templateType,
	jsonQuery: serializedQuery,
	reportIDList: [],
	transactionIDList: [],
	policyID,
	exportName,
	},
	true,
	);
	} else {
	const isGroupExport = !!queryJSON?.groupBy && selectedTransactionsKeys.some((key) => key.startsWith(CONST.SEARCH.GROUP_PREFIX));
	exportID = queueExportSearchWithTemplate(
	{
	templateName,
	templateType,
	jsonQuery: isGroupExport ? serializeQueryJSONForBackend(addSelectedGroupsFilter(queryJSON, selectedTransactions, currentSearchResults?.data)) : '{}',
	reportIDList: isGroupExport ? [] : selectedTransactionReportIDs,
	transactionIDList: isGroupExport ? [] : selectedTransactionsKeys,
	policyID,
	exportName,
	},
	true,
	);
	}
	trackExport(exportID);

App/src/components/MoneyRequestReportView/SelectionToolbar/index.tsx

Lines 103 to 115 in 5ca7950

	const exportID = queueExportSearchWithTemplate(
	{
	templateName,
	templateType,
	jsonQuery: '{}',
	reportIDList: [report.reportID],
	transactionIDList,
	policyID: policy?.id,
	exportName,
	},
	true,
	);
	trackExport(exportID);

One thing I want to flag rather than gloss over: my seeded template has no server-side counterpart, so the API answered jsonCode 666 "Invalid export template name" in both the broken and fixed runs. That is expected for a synthetic template, and it is what makes the front-end causality unambiguous — the same backend response produces "Export failed" with tracking on and the Concierge confirmation with tracking off. It does not explain why the reporter's real template is rejected while Classic exports it fine, which is worth a separate backend look.

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

I think we should identify custom Integration Server templates and queue them the legacy way. A custom IS template is an integrations-type template whose name is neither of the two built-in ones — the same distinction the export menu already draws when it picks the TablePencil icon over Table. In-app templates keep their own in-app type, so they are unaffected:

App/src/libs/actions/Search.ts

Lines 1580 to 1591 in 5ca7950

	// Collate a list of the user's account level in-app export templates, excluding the Default CSV template
	const accountInAppTemplates = Object.entries(csvExportLayouts ?? {})
	.filter(([, layout]) => layout.name !== CONST.REPORT.EXPORT_OPTION_LABELS.DEFAULT_CSV)
	.map(([templateName, layout]) => normalizeTemplate(templateName, layout, CONST.EXPORT_TEMPLATE_TYPES.IN_APP));
	// If we have a policy, collate a list of the policy-level in-app export templates
	const policyInAppTemplates = policy
	? Object.entries(policy.exportLayouts ?? {}).map(([templateName, layout]) => normalizeTemplate(templateName, layout, CONST.EXPORT_TEMPLATE_TYPES.IN_APP, policy.name, policy.id))
	: [];
	// Update the integrations export templates to include the name, description, policyID, and type
	const integrationsTemplates = integrationsExportTemplates.map((template) => normalizeTemplate(template.name, template, CONST.EXPORT_TEMPLATE_TYPES.INTEGRATIONS));

I would add a small predicate next to getExportTemplates in src/libs/actions/Search.ts:

function isCustomIntegrationsExportTemplate(templateName: string, templateType: string): boolean {
    return (
        templateType === CONST.EXPORT_TEMPLATE_TYPES.INTEGRATIONS &&
        templateName !== CONST.REPORT.EXPORT_OPTIONS.EXPENSE_LEVEL_EXPORT &&
        templateName !== CONST.REPORT.EXPORT_OPTIONS.REPORT_LEVEL_EXPORT
    );
}

and use it at each entry point to decide between the tracked download modal and the background-export confirmation:

+const shouldTrackExportProgress = !isCustomIntegrationsExportTemplate(templateName, templateType);
 const exportID = queueExportSearchWithTemplate(
     {templateName, templateType, jsonQuery: '{}', reportIDList: [moneyRequestReport.reportID], transactionIDList, policyID, exportName},
-    true,
+    shouldTrackExportProgress,
 );
+
+if (!shouldTrackExportProgress) {
+    showDecisionModal({
+        title: translate('export.exportInProgress'),
+        prompt: translate('export.conciergeWillSend'),
+        secondOptionText: translate('common.buttonConfirm'),
+    });
+    return;
+}
+
 trackExport(exportID);

Each surface already has a modal helper in scope, so this reuses showDecisionModal in useExportActions and showConfirmModal in useSearchBulkActions and SelectionToolbar — no new modal wiring, and it revives the export.exportInProgress / export.conciergeWillSend strings that are still translated in every locale.

For tests I would cover the predicate itself in tests/unit/SearchActionsTest.ts (custom IS → true; detailed_export, report_level_export, and in-app → false) and extend tests/unit/hooks/useExportActionsTest.ts with a case asserting that a custom IS export passes false to queueExportSearchWithTemplate, never calls trackExport, and shows the background-export confirmation. The existing test that asserts true plus the download modal for standard templates stays as the regression guard for the other direction.

This is safe because the expense-level, report-level, and in-app CSV flows keep their current tracked-download behavior verbatim. Only custom IS templates return to the request shape and UI they were built against.

What alternative solutions did you explore? (Optional)

I considered keeping the tracked flow and handing custom IS exports straight to the shouldSendFromConcierge branch of the status modal, so the user would get "Concierge will send you a message when the file is ready" inside the existing modal. I discarded it because that branch still depends on a tracked export existing on the backend, which is the assumption that does not hold here.

I also checked whether the front end simply sends the wrong identifier — getExportTemplates sets templateName to the display name for integrations templates. That turns out to be deliberate: the raw nvp_expensify_integrationServerExportTemplates entries carry only name (the pre-consolidation IntegrationServerExportTemplate type had a single name field), so there is no internal ID for the app to send. I ruled this out as a cause.

[ahmdshrif]

Proposal

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

Exporting a report in New Expensify via More > Export > a custom Integration Server (IS) template immediately shows "Export failed — Your export could not be completed. Please try again later." The same template exports fine (with all columns) from Classic. Expected: the "export is running in the back end and will complete shortly" message.

What is the root cause of that problem?

This is a regression from the tracked-download export flow (ExportDownloadStatusModal) being applied to all export templates, including custom IS templates that the tracked CSV-download pipeline cannot build.

1. The report's More > Export submenu builds one entry per template and calls beginExportWithTemplate for all of them — built-in "All Data" templates, in-app CSV layouts, and custom IS templates alike:

   App/src/hooks/useExportActions.ts

   Lines 199 to 207 in 8d9b172

   	const isStandardTemplate = template.templateName === CONST.REPORT.EXPORT_OPTIONS.EXPENSE_LEVEL_EXPORT || template.templateName === CONST.REPORT.EXPORT_OPTIONS.REPORT_LEVEL_EXPORT;
   	exportSubmenuOptions[template.name] = {
   	text: template.name,
   	icon: isStandardTemplate ? expensifyIcons.Table : expensifyIcons.TablePencil,
   	value: template.templateName,
   	description: template.description,
   	sentryLabel: CONST.SENTRY_LABEL.MORE_MENU.EXPORT_FILE,
   	onSelected: () => beginExportWithTemplate(template.templateName, template.type, transactionIDs, template.name, template.policyID),
   	};

2. beginExportWithTemplate unconditionally queues the export with shouldTrackExportProgress = true and hands the exportID to the status modal:

   App/src/hooks/useExportActions.ts

   Lines 106 to 129 in 8d9b172

   	const beginExportWithTemplate = (templateName: string, templateType: string, transactionIDList: string[], exportName: string, policyID?: string) => {
   	if (isOffline) {
   	showOfflineModal();
   	return;
   	}
   	if (!moneyRequestReport) {
   	return;
   	}
   	const exportID = queueExportSearchWithTemplate(
   	{
   	templateName,
   	templateType,
   	jsonQuery: '{}',
   	reportIDList: [moneyRequestReport.reportID],
   	transactionIDList,
   	policyID,
   	exportName,
   	},
   	true,
   	);
   	trackExport(exportID);
   	};

3. With tracking on, queueExportSearchWithTemplate sends exportID to the backend and seeds exportDownload_<id> with PREPARING (FAILED on error):

   App/src/libs/actions/Search.ts

   Lines 1496 to 1543 in 8d9b172

   	function queueExportSearchWithTemplate(
   	{templateName, templateType, jsonQuery, reportIDList, transactionIDList, policyID, exportName}: ExportSearchWithTemplateParams,
   	shouldTrackExportProgress = false,
   	): string {
   	const exportID = rand64();
   	const onyxKey = `${ONYXKEYS.COLLECTION.EXPORT_DOWNLOAD}${exportID}` as const;
   	const onyxData: OnyxData<typeof onyxKey> = shouldTrackExportProgress
   	? {
   	optimisticData: [
   	{
   	onyxMethod: Onyx.METHOD.SET,
   	key: onyxKey,
   	value: {
   	state: CONST.EXPORT_DOWNLOAD.STATE.PREPARING,
   	exportType: CONST.EXPORT_DOWNLOAD.TYPE.CSV,
   	},
   	},
   	],
   	failureData: [
   	{
   	onyxMethod: Onyx.METHOD.SET,
   	key: onyxKey,
   	value: {
   	state: CONST.EXPORT_DOWNLOAD.STATE.FAILED,
   	exportType: CONST.EXPORT_DOWNLOAD.TYPE.CSV,
   	},
   	},
   	],
   	}
   	: {};
   	const finalParameters = enhanceParameters(WRITE_COMMANDS.QUEUE_EXPORT_SEARCH_WITH_TEMPLATE, {
   	templateName,
   	templateType,
   	jsonQuery,
   	reportIDList,
   	transactionIDList,
   	policyID,
   	exportName,
   	...(shouldTrackExportProgress ? {exportID} : {}),
   	}) as QueueExportSearchWithTemplateParams;
   	write(WRITE_COMMANDS.QUEUE_EXPORT_SEARCH_WITH_TEMPLATE, finalParameters, onyxData);
   	return exportID;
   	}

4. Sending exportID opts the export into the downloadable-CSV worker flow. Custom IS templates instead run on the legacy Integration Server (custom columns/formats, delivered via Concierge), so the tracked job cannot produce the file and the key lands on FAILED. The param type documents the split — "when omitted, the backend keeps the legacy 'Concierge will send' behavior":

   App/src/libs/API/parameters/QueueExportSearchWithTemplateParams.ts

   Lines 4 to 9 in 8d9b172

   	/**
   	* Identifier for the export download status flow (nvp_exportDownload_<id>). Only sent by callers that render
   	* ExportDownloadStatusModal; when omitted, the backend keeps the legacy "Concierge will send" behavior.
   	*/
   	exportID?: string;
   	};

5. ExportDownloadStatusModal renders the FAILED state as exactly the reported copy (exportDownload.failedTitle / csvFailedBody):

   App/src/components/ExportDownloadStatusModal.tsx

   Lines 178 to 191 in 8d9b172

   	if (isFailed) {
   	const resolvedFailedBody = failedBody ?? (exportType === CONST.EXPORT_DOWNLOAD.TYPE.CSV ? translate('exportDownload.csvFailedBody') : translate('exportDownload.pdfFailedBody'));
   	return (
   	<>
   	<Text style={[styles.exportDownloadTitle, styles.mb2]}>{translate('exportDownload.failedTitle')}</Text>
   	{!!resolvedFailedBody && <Text style={styles.mb5}>{resolvedFailedBody}</Text>}
   	<Button
   	text={translate('exportDownload.close')}
   	onPress={onClose}
   	style={styles.w100}
   	/>
   	</>
   	);
   	}

6. Regression source: PR #92169 (merged 2026-06-17) wired the tracked modal into the search bulk export and deleted the legacy "Export in progress / Concierge will send you the file shortly" confirm modal; PR #93796 (merged 2026-06-25) did the same for the report-level flow. Those strings are now orphaned in every locale file:

   App/src/languages/en.ts

   Lines 10379 to 10380 in 8d9b172

   	exportInProgress: 'Export in progress',
   	conciergeWillSend: 'Concierge will send you the file shortly.',

The structural cause: the tracked flow assumes every template yields a browser-downloadable CSV. That holds for the built-in detailed_export/report_level_export templates and in-app layouts, but not for custom IS templates, which getExportTemplates merges into the same list with no distinction at queue time:

App/src/libs/actions/Search.ts

Line 1591 in 8d9b172

const integrationsTemplates = integrationsExportTemplates.map((template) => normalizeTemplate(template.name, template, CONST.EXPORT_TEMPLATE_TYPES.INTEGRATIONS));

This explains every symptom: only custom IS templates fail; Classic works (IS pipeline untouched); the expected message is literally the deleted legacy copy; the timeline fits (PRs merged mid/late June, issue on 9.4.41-4).

All affected call sites (each queues with tracking hardcoded true):

• Report More > Export submenu and the wide-layout header selection dropdown (both via useExportActions):

  App/src/hooks/useExportActions.ts

  Lines 116 to 127 in 8d9b172

  	const exportID = queueExportSearchWithTemplate(
  	{
  	templateName,
  	templateType,
  	jsonQuery: '{}',
  	reportIDList: [moneyRequestReport.reportID],
  	transactionIDList,
  	policyID,
  	exportName,
  	},
  	true,
  	);

• Narrow-layout selection toolbar inside a report:

  App/src/components/MoneyRequestReportView/SelectionToolbar/index.tsx

  Lines 93 to 116 in 8d9b172

  	const beginExportWithTemplate = (templateName: string, templateType: string, transactionIDList: string[], exportName: string) => {
  	if (isOffline) {
  	setOfflineModalVisible(true);
  	return;
  	}
  	if (!report) {
  	return;
  	}
  	const exportID = queueExportSearchWithTemplate(
  	{
  	templateName,
  	templateType,
  	jsonQuery: '{}',
  	reportIDList: [report.reportID],
  	transactionIDList,
  	policyID: policy?.id,
  	exportName,
  	},
  	true,
  	);
  	trackExport(exportID);
  	};

• Search/Reports page bulk export, both the all-matching and selected branches:

  App/src/hooks/useSearchBulkActions.ts

  Lines 633 to 660 in 8d9b172

  	exportID = queueExportSearchWithTemplate(
  	{
  	templateName,
  	templateType,
  	jsonQuery: serializedQuery,
  	reportIDList: [],
  	transactionIDList: [],
  	policyID,
  	exportName,
  	},
  	true,
  	);
  	} else {
  	const isGroupExport = !!queryJSON?.groupBy && selectedTransactionsKeys.some((key) => key.startsWith(CONST.SEARCH.GROUP_PREFIX));
  	exportID = queueExportSearchWithTemplate(
  	{
  	templateName,
  	templateType,
  	jsonQuery: isGroupExport ? serializeQueryJSONForBackend(addSelectedGroupsFilter(queryJSON, selectedTransactions, currentSearchResults?.data)) : '{}',
  	reportIDList: isGroupExport ? [] : selectedTransactionReportIDs,
  	transactionIDList: isGroupExport ? [] : selectedTransactionsKeys,
  	policyID,
  	exportName,
  	},
  	true,
  	);
  	}
  	trackExport(exportID);

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

Opt custom IS templates out of the tracked-download flow and restore the legacy Concierge messaging for them — the exact behavior the issue's Expected Result asks for, and a path the backend still supports when exportID is omitted.

Add a small shared predicate next to getExportTemplates in Search.ts:

function isCustomIntegrationsExportTemplate(templateName: string, templateType: string) {
    return templateType === CONST.EXPORT_TEMPLATE_TYPES.INTEGRATIONS
        && templateName !== CONST.REPORT.EXPORT_OPTIONS.EXPENSE_LEVEL_EXPORT
        && templateName !== CONST.REPORT.EXPORT_OPTIONS.REPORT_LEVEL_EXPORT;
}

(EXPORT_TEMPLATE_TYPES and the built-in template names:

App/src/CONST/index.ts

Lines 1930 to 1953 in 8d9b172

	EXPORT_OPTIONS: {
	EXPORT_TO_INTEGRATION: 'exportToIntegration',
	MARK_AS_EXPORTED: 'markAsExported',
	DOWNLOAD_CSV: 'downloadCSV',
	REPORT_LEVEL_EXPORT: 'report_level_export',
	EXPENSE_LEVEL_EXPORT: 'detailed_export',
	},
	EXPORT_OPTION_LABELS: {
	REPORT_LEVEL_EXPORT: 'All Data - Report Level Export',
	EXPENSE_LEVEL_EXPORT: 'All Data - Expense Level Export',
	DEFAULT_CSV: 'Default CSV',
	},
	ROOM_MEMBERS_BULK_ACTION_TYPES: {
	REMOVE: 'remove',
	},
	MOVE_TYPE: {
	FROM: 'from',
	TO: 'to',
	},
	},
	EXPORT_TEMPLATE_TYPES: {
	INTEGRATIONS: 'integrations',
	IN_APP: 'in-app',
	},

— useExportActions already uses this exact built-in-name check for the menu icon at L199.)

Then in each of the three call sites above: pass !isCustomIntegrationsExportTemplate(...) as shouldTrackExportProgress, and when it's a custom IS template, skip trackExport(exportID) and show the existing confirm copy instead (export.exportInProgress / export.conciergeWillSend — still present in all locales, so zero translation work).

Regression safety in one sentence: built-in All Data templates and in-app CSV layouts still queue with tracking true, so the download modal flow they were built for is untouched.

Why the obvious spot fix fails: patching only useExportActions leaves the identical FAILED modal on the Search-page bulk export and the report selection toolbar; and flipping shouldTrackExportProgress to false while still calling trackExport(exportID) is worse — the modal subscribes to an exportDownload_<id> key that is never written, state stays undefined, renderContent() returns null, and the user gets a blank modal (

App/src/components/ExportDownloadStatusModal.tsx

Lines 111 to 194 in 8d9b172

	const renderContent = () => {
	if (isPreparing) {
	return (
	<>
	<View style={[styles.flexRow, styles.justifyContentBetween, styles.alignItemsCenter, styles.mb2]}>
	<Text style={[styles.exportDownloadTitle, styles.flexShrink1]}>{translate('exportDownload.preparingTitle')}</Text>
	<ActivityIndicator
	size="small"
	reasonAttributes={{context: 'ExportDownloadStatusModal.preparing'}}
	/>
	</View>
	<Text style={styles.mb5}>{translate('exportDownload.preparingBody')}</Text>
	<Button
	text={translate('exportDownload.sendFromConcierge')}
	onPress={handleSendFromConcierge}
	style={styles.w100}
	/>
	</>
	);
	}
	if (isConcierge) {
	return (
	<>
	<Text style={[styles.exportDownloadTitle, styles.mb2]}>{translate('exportDownload.conciergeTitle')}</Text>
	<Text style={styles.mb5}>{translate('exportDownload.conciergeBody')}</Text>
	<Button
	success
	text={translate('exportDownload.goToConcierge')}
	onPress={handleGoToConcierge}
	style={styles.w100}
	/>
	<Button
	text={translate('exportDownload.dismiss')}
	onPress={onClose}
	style={[styles.w100, styles.mt3]}
	/>
	</>
	);
	}
	if (isReady) {
	return (
	<>
	<Text style={[styles.exportDownloadTitle, styles.mb2]}>{translate('exportDownload.readyTitle')}</Text>
	{isPartialFailure ? (
	<View style={styles.mb5}>
	<RenderHTML
	html={translate('exportDownload.readyPartialBody', {
	count: reportCount,
	total: reportCount + failedReportCount,
	})}
	/>
	</View>
	) : (
	<Text style={styles.mb5}>{translate('exportDownload.readyBody')}</Text>
	)}
	<Button
	success
	text={translate('exportDownload.downloadFile')}
	onPress={handleDownloadFile}
	style={styles.w100}
	/>
	</>
	);
	}
	if (isFailed) {
	const resolvedFailedBody = failedBody ?? (exportType === CONST.EXPORT_DOWNLOAD.TYPE.CSV ? translate('exportDownload.csvFailedBody') : translate('exportDownload.pdfFailedBody'));
	return (
	<>
	<Text style={[styles.exportDownloadTitle, styles.mb2]}>{translate('exportDownload.failedTitle')}</Text>
	{!!resolvedFailedBody && <Text style={styles.mb5}>{resolvedFailedBody}</Text>}
	<Button
	text={translate('exportDownload.close')}
	onPress={onClose}
	style={styles.w100}
	/>
	</>
	);
	}
	return null;
	};

). The untracked branch must both skip tracking and surface the legacy message.

Long-term the backend could add tracked-download support for IS-template exports, but the App-side fix above restores the expected behavior today and is mergeable by an external contributor.

What alternative solutions did you explore? (Optional)

• Gate inside queueExportSearchWithTemplate itself (single convergence point): callers would still call trackExport and render the blank modal described above, so the call sites need awareness either way — the predicate-at-call-site version is the smaller total change.
• Suppress/soften the FAILED modal: pure symptom fix — the export still fails server-side.
• Backend-only fix (make the download worker handle IS templates): not mergeable by an external contributor, and the FE would still show tracked "Preparing download…" messaging for a Concierge-delivered file.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-23 18:34:43 UTC.

Proposal

What is the root cause of that problem?

NewDot sends every template selected from report More > Export through the tracked-download flow. beginExportWithTemplate() unconditionally passes true for shouldTrackExportProgress and tracks the returned export ID, without distinguishing custom Integration Server (IS) templates from templates that produce an immediate downloadable CSV.

App/src/hooks/useExportActions.ts

Lines 106 to 129 in ea855a7

	const beginExportWithTemplate = (templateName: string, templateType: string, transactionIDList: string[], exportName: string, policyID?: string) => {
	if (isOffline) {
	showOfflineModal();
	return;
	}
	if (!moneyRequestReport) {
	return;
	}
	const exportID = queueExportSearchWithTemplate(
	{
	templateName,
	templateType,
	jsonQuery: '{}',
	reportIDList: [moneyRequestReport.reportID],
	transactionIDList,
	policyID,
	exportName,
	},
	true,
	);
	trackExport(exportID);
	};

Tracking changes both the request and its UI state: queueExportSearchWithTemplate() sends exportID, writes an optimistic PREPARING download record, and changes that record to FAILED if the request rejects. The failure record is what produces the exact Export failed modal shown in the issue.

App/src/libs/actions/Search.ts

Lines 1496 to 1541 in ea855a7

	function queueExportSearchWithTemplate(
	{templateName, templateType, jsonQuery, reportIDList, transactionIDList, policyID, exportName}: ExportSearchWithTemplateParams,
	shouldTrackExportProgress = false,
	): string {
	const exportID = rand64();
	const onyxKey = `${ONYXKEYS.COLLECTION.EXPORT_DOWNLOAD}${exportID}` as const;
	const onyxData: OnyxData<typeof onyxKey> = shouldTrackExportProgress
	? {
	optimisticData: [
	{
	onyxMethod: Onyx.METHOD.SET,
	key: onyxKey,
	value: {
	state: CONST.EXPORT_DOWNLOAD.STATE.PREPARING,
	exportType: CONST.EXPORT_DOWNLOAD.TYPE.CSV,
	},
	},
	],
	failureData: [
	{
	onyxMethod: Onyx.METHOD.SET,
	key: onyxKey,
	value: {
	state: CONST.EXPORT_DOWNLOAD.STATE.FAILED,
	exportType: CONST.EXPORT_DOWNLOAD.TYPE.CSV,
	},
	},
	],
	}
	: {};
	const finalParameters = enhanceParameters(WRITE_COMMANDS.QUEUE_EXPORT_SEARCH_WITH_TEMPLATE, {
	templateName,
	templateType,
	jsonQuery,
	reportIDList,
	transactionIDList,
	policyID,
	exportName,
	...(shouldTrackExportProgress ? {exportID} : {}),
	}) as QueueExportSearchWithTemplateParams;
	write(WRITE_COMMANDS.QUEUE_EXPORT_SEARCH_WITH_TEMPLATE, finalParameters, onyxData);
	return exportID;

The request type documents the missing distinction: exportID is optional, and omitting it preserves the legacy “Concierge will send” behavior. Custom IS exports run in the background and use that legacy delivery path, so opting them into tracked browser-download handling changes the backend contract they rely on.

App/src/libs/API/parameters/QueueExportSearchWithTemplateParams.ts

Lines 3 to 8 in ea855a7

	type QueueExportSearchWithTemplateParams = ExportSearchWithTemplateParams & {
	/**
	* Identifier for the export download status flow (nvp_exportDownload_<id>). Only sent by callers that render
	* ExportDownloadStatusModal; when omitted, the backend keeps the legacy "Concierge will send" behavior.
	*/
	exportID?: string;

This regressed in PR #93796. The report-level flow previously queued without tracked progress and showed the still-translated “Export in progress / Concierge will send you the file shortly” confirmation; the PR replaced that behavior with tracked progress for every template.

#93796

App/src/languages/en.ts

Lines 10381 to 10401 in ea855a7

	export: {
	basicExport: 'Basic export',
	currentView: 'Current view',
	reportLevelExport: 'All Data - report level',
	expenseLevelExport: 'All Data - expense level',
	exportInProgress: 'Export in progress',
	conciergeWillSend: 'Concierge will send you the file shortly.',
	},
	exportDownload: {
	preparingTitle: 'Preparing download...',
	preparingBody: 'You can either wait for the download to finish or Concierge can send it to you via chat.',
	sendFromConcierge: "Send me the file when it's ready",
	conciergeTitle: 'You bet!',
	conciergeBody: 'Concierge will send you a message when the file is ready.',
	goToConcierge: 'Go to Concierge',
	dismiss: 'Dismiss',
	readyTitle: 'Your file is ready!',
	readyBody: "If it didn't automatically download, use the button below.",
	downloadFile: 'Download file',
	failedTitle: 'Export failed',
	csvFailedBody: 'Your export could not be completed. Please try again later.',

The same unconditional tracking exists in the report selection toolbar and both Search bulk-export branches, so the defect is not confined to the More menu.

App/src/components/MoneyRequestReportView/SelectionToolbar/index.tsx

Lines 93 to 116 in ea855a7

	const beginExportWithTemplate = (templateName: string, templateType: string, transactionIDList: string[], exportName: string) => {
	if (isOffline) {
	setOfflineModalVisible(true);
	return;
	}
	if (!report) {
	return;
	}
	const exportID = queueExportSearchWithTemplate(
	{
	templateName,
	templateType,
	jsonQuery: '{}',
	reportIDList: [report.reportID],
	transactionIDList,
	policyID: policy?.id,
	exportName,
	},
	true,
	);
	trackExport(exportID);
	};

App/src/hooks/useSearchBulkActions.ts

Lines 608 to 660 in ea855a7

	const beginExportWithTemplate = useCallback(
	(templateName: string, templateType: string, policyID: string | undefined, exportName: string) => {
	const emptyReports =
	selectedReports?.filter((selectedReport) => {
	if (!selectedReport) {
	return false;
	}
	const fullReport = currentSearchResults?.data?.[`${ONYXKEYS.COLLECTION.REPORT}${selectedReport.reportID}`];
	return !!fullReport && (fullReport.transactionCount ?? 0) === 0;
	}) ?? [];
	const hasOnlyEmptyReports = selectedReports.length > 0 && emptyReports.length === selectedReports.length;
	if (hasOnlyEmptyReports) {
	setEmptyReportsCount(emptyReports.length);
	setIsDownloadErrorModalVisible(true);
	return;
	}
	if (isOffline) {
	setIsOfflineModalVisible(true);
	return;
	}
	const serializedQuery = queryJSON ? serializeQueryJSONForBackend(queryJSON) : JSON.stringify(queryJSON);
	let exportID: string;
	if (areAllMatchingItemsSelected) {
	exportID = queueExportSearchWithTemplate(
	{
	templateName,
	templateType,
	jsonQuery: serializedQuery,
	reportIDList: [],
	transactionIDList: [],
	policyID,
	exportName,
	},
	true,
	);
	} else {
	const isGroupExport = !!queryJSON?.groupBy && selectedTransactionsKeys.some((key) => key.startsWith(CONST.SEARCH.GROUP_PREFIX));
	exportID = queueExportSearchWithTemplate(
	{
	templateName,
	templateType,
	jsonQuery: isGroupExport ? serializeQueryJSONForBackend(addSelectedGroupsFilter(queryJSON, selectedTransactions, currentSearchResults?.data)) : '{}',
	reportIDList: isGroupExport ? [] : selectedTransactionReportIDs,
	transactionIDList: isGroupExport ? [] : selectedTransactionsKeys,
	policyID,
	exportName,
	},
	true,
	);
	}
	trackExport(exportID);

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

Add a shared predicate that identifies only custom IS templates: the template type is CONST.EXPORT_TEMPLATE_TYPES.INTEGRATIONS, while the template name is neither the built-in expense-level export nor the built-in report-level export. The existing template collation and menu logic already preserve those type and name distinctions.

App/src/libs/actions/Search.ts

Lines 1552 to 1593 in ea855a7

	function getExportTemplates(
	integrationsExportTemplates: ExportTemplate[],
	csvExportLayouts: Record<string, ExportTemplate>,
	translate: LocalizedTranslate,
	policy?: Policy,
	includeReportLevelExport = true,
	): ExportTemplate[] {
	// Helper function to normalize template data into consistent ExportTemplate format
	const normalizeTemplate = (templateName: string, template: ExportTemplate, type: ValueOf<typeof CONST.EXPORT_TEMPLATE_TYPES>, description = '', policyID?: string): ExportTemplate => ({
	...template,
	templateName,
	description,
	policyID,
	type,
	});
	// By default, we always include the expense level export template
	const exportTemplates: ExportTemplate[] = [
	normalizeTemplate(CONST.REPORT.EXPORT_OPTIONS.EXPENSE_LEVEL_EXPORT, {name: translate('export.expenseLevelExport')} as ExportTemplate, CONST.EXPORT_TEMPLATE_TYPES.INTEGRATIONS),
	];
	// Conditionally include the report level export template
	if (includeReportLevelExport) {
	exportTemplates.push(
	normalizeTemplate(CONST.REPORT.EXPORT_OPTIONS.REPORT_LEVEL_EXPORT, {name: translate('export.reportLevelExport')} as ExportTemplate, CONST.EXPORT_TEMPLATE_TYPES.INTEGRATIONS),
	);
	}
	// Collate a list of the user's account level in-app export templates, excluding the Default CSV template
	const accountInAppTemplates = Object.entries(csvExportLayouts ?? {})
	.filter(([, layout]) => layout.name !== CONST.REPORT.EXPORT_OPTION_LABELS.DEFAULT_CSV)
	.map(([templateName, layout]) => normalizeTemplate(templateName, layout, CONST.EXPORT_TEMPLATE_TYPES.IN_APP));
	// If we have a policy, collate a list of the policy-level in-app export templates
	const policyInAppTemplates = policy
	? Object.entries(policy.exportLayouts ?? {}).map(([templateName, layout]) => normalizeTemplate(templateName, layout, CONST.EXPORT_TEMPLATE_TYPES.IN_APP, policy.name, policy.id))
	: [];
	// Update the integrations export templates to include the name, description, policyID, and type
	const integrationsTemplates = integrationsExportTemplates.map((template) => normalizeTemplate(template.name, template, CONST.EXPORT_TEMPLATE_TYPES.INTEGRATIONS));
	return [...exportTemplates, ...integrationsTemplates, ...accountInAppTemplates, ...policyInAppTemplates];

Use that predicate at all three template-export entry points:

• For built-in expense/report exports and in-app layouts, keep passing shouldTrackExportProgress=true, calling trackExport(), and showing the current preparing/ready/download modal.
• For custom IS templates, queue without tracked progress so exportID is omitted, do not call trackExport(), and show the existing export.exportInProgress / export.conciergeWillSend confirmation instead.

Both parts of the custom-IS branch are required. Merely passing false while still calling trackExport() would open a modal subscribed to an export-download key that is never created. Apply the branch in useExportActions, SelectionToolbar, and useSearchBulkActions so the same template behaves consistently from report More > Export, report selection mode, and Search bulk export.

Test coverage:

• Add unit coverage for the shared predicate: a custom integrations template uses legacy delivery, while expense-level, report-level, and in-app templates remain tracked.
• Update useExportActions tests to assert that custom IS export omits tracking, skips trackExport(), and shows the Concierge confirmation; retain the existing tracked-export assertion for standard templates.
• Add equivalent callback coverage for SelectionToolbar and both Search bulk branches.
• Manually export a real custom IS template from all three web entry points and verify the background-export confirmation appears and the export completes; also verify built-in and in-app templates still use the download-status modal.

What alternative solutions did you explore? (Optional)

I considered changing getExportTemplates() to preserve a separate template.templateName, but git history shows the raw Integration Server template model originally contained only name; the shared helper deliberately derives its normalized templateName from that value. Reading template.templateName from the raw NVP could therefore send undefined and make the export worse.

2f81fba

b274ecb

I also considered suppressing the failure modal, but that would only hide the rejected tracked request. A backend enhancement could eventually make custom IS jobs participate in tracked downloads, but selecting the existing untracked request contract restores the expected behavior without changing valid tracked exports.

[melvin-bot]

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

[wildan-m]

Proposal

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

Exporting a report with a custom Integration Server (IS) export template from the report's More > Export menu in NewDot fails with the "Export failed — Your export could not be completed. Please try again later." modal, while the same export works in Expensify Classic.

What is the root cause of that problem?

The failure modal the user sees is the failed branch of ExportDownloadStatusModal, which renders once the export download NVP for this export goes into the failed state:

App/src/components/ExportDownloadStatusModal.tsx

Lines 178 to 184 in 8d9b172

	if (isFailed) {
	const resolvedFailedBody = failedBody ?? (exportType === CONST.EXPORT_DOWNLOAD.TYPE.CSV ? translate('exportDownload.csvFailedBody') : translate('exportDownload.pdfFailedBody'));
	return (
	<>
	<Text style={[styles.exportDownloadTitle, styles.mb2]}>{translate('exportDownload.failedTitle')}</Text>
	{!!resolvedFailedBody && <Text style={styles.mb5}>{resolvedFailedBody}</Text>}
	<Button

That state is written by the failureData of the QueueExportSearchWithTemplate request, so the request itself is being rejected.

The reason it is rejected is the policyID parameter we send. The report's More > Export submenu is built in useExportActions, and for each template it passes the template's policyID through to the export request:

App/src/hooks/useExportActions.ts

Line 206 in 8d9b172

onSelected: () => beginExportWithTemplate(template.templateName, template.type, transactionIDs, template.name, template.policyID),

That value is then forwarded verbatim as the policyID parameter of QueueExportSearchWithTemplate:

App/src/hooks/useExportActions.ts

Lines 116 to 127 in 8d9b172

	const exportID = queueExportSearchWithTemplate(
	{
	templateName,
	templateType,
	jsonQuery: '{}',
	reportIDList: [moneyRequestReport.reportID],
	transactionIDList,
	policyID,
	exportName,
	},
	true,
	);

The problem is that custom IS templates never carry a policyID. They come from the account-level NVP nvp_expensify_integrationServerExportTemplates, and getExportTemplates normalizes them with the normalizeTemplate helper while omitting the optional policyID argument, so policyID is explicitly set to undefined on every integrations-type template:

App/src/libs/actions/Search.ts

Lines 1590 to 1591 in 8d9b172

	// Update the integrations export templates to include the name, description, policyID, and type
	const integrationsTemplates = integrationsExportTemplates.map((template) => normalizeTemplate(template.name, template, CONST.EXPORT_TEMPLATE_TYPES.INTEGRATIONS));

App/src/libs/actions/Search.ts

Lines 1560 to 1566 in 8d9b172

	const normalizeTemplate = (templateName: string, template: ExportTemplate, type: ValueOf<typeof CONST.EXPORT_TEMPLATE_TYPES>, description = '', policyID?: string): ExportTemplate => ({
	...template,
	templateName,
	description,
	policyID,
	type,
	});

Only the policy-level in-app templates get a real policyID (they are normalized with policy.id passed explicitly). So when the user picks a custom IS template from More > Export, the export request is queued with no workspace context at all, and the backend cannot resolve which workspace the custom IS template export should run against — it errors out and the client flips the export state to failed.

The very same export succeeds from the other report-level entry point, the in-report selection toolbar, because that one ignores the template's policyID and sends the report's own policy instead:

App/src/components/MoneyRequestReportView/SelectionToolbar/index.tsx

Lines 103 to 114 in 8d9b172

	const exportID = queueExportSearchWithTemplate(
	{
	templateName,
	templateType,
	jsonQuery: '{}',
	reportIDList: [report.reportID],
	transactionIDList,
	policyID: policy?.id,
	exportName,
	},
	true,
	);

The existing unit test for this hook also documents the intended behaviour — it drives beginExportWithTemplate with the report's policy ID and asserts that policyID reaches queueExportSearchWithTemplate:

App/tests/unit/hooks/useExportActionsTest.ts

Lines 97 to 115 in 8d9b172

	it('queues the export with progress tracking', () => {
	const {result} = renderHook(() => useExportActions({reportID: REPORT_ID}));
	act(() => {
	result.current.beginExportWithTemplate('Test Template', 'csv', ['1', '2'], EXPORT_NAME, POLICY_ID);
	});
	expect(mockQueueExportSearchWithTemplate).toHaveBeenCalledWith(
	{
	templateName: 'Test Template',
	templateType: 'csv',
	jsonQuery: '{}',
	reportIDList: [REPORT_ID],
	transactionIDList: ['1', '2'],
	policyID: POLICY_ID,
	exportName: EXPORT_NAME,
	},
	true,
	);

In production the call site never supplies it for custom IS templates, so the parameter is silently dropped. Classic is unaffected because it always exports in the context of the report's workspace. This also explains why QA could not reproduce it: it only shows up on an account that actually has a custom IS template configured, and only from the report header's More > Export menu.

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

In beginExportWithTemplate inside src/hooks/useExportActions.ts, stop trusting the template to supply the workspace context. When the selected template has no policyID of its own — which is always the case for custom Integration Server templates and for account-level in-app templates — fall back to the policyID of the report we are exporting, which the hook already has available on the moneyRequestReport it reads from Onyx and which it already guards against being missing.

Concretely: the policyID value handed to queueExportSearchWithTemplate should be the template's policyID when one exists, otherwise the report's policyID. That keeps the current behaviour for policy-level in-app templates (they continue to export against their own workspace) and makes the custom IS template case send the report's workspace, exactly like the in-report selection toolbar already does. With a real workspace on the request, the backend can resolve the export and the user gets the expected "export is running in the background" flow instead of the failure modal.

Because the report header's secondary-actions menu and the report header's selection dropdown both consume this same hook, this one change fixes the custom IS export from both of those entry points, and it aligns all report-level export surfaces on a single rule for policyID.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/96885-custom-is-export-policyid?expand=1

What alternative solutions did you explore? (Optional)

I considered fixing this in getExportTemplates in src/libs/actions/Search.ts by normalizing integrations templates with the caller's policy.id instead of leaving policyID undefined. I rejected it because getExportTemplates is also used by surfaces that are not report-scoped — the Search filter selector and the exported-to filter options — where it is called with no policy at all, so the templates it returns would still be missing a workspace in some callers while gaining a possibly unrelated one in others. Deciding the workspace at the point where we actually know which report is being exported is both narrower and correct for every caller.

I also considered making queueExportSearchWithTemplate derive the workspace itself from the first entry of reportIDList. I rejected that too: that function serves the Search bulk-export path, where the request can legitimately span reports from several workspaces or carry no reportIDList at all (a whole-query export), so a fallback there would be guessing rather than using known context.