[$250] Spend/Export - Default CSV option doesn't display when select report from 2 workspaces

[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: v9.4.6-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-42186/folder/14961849/44240945/1481941966?sort=%2Bidentifier
Email or phone of affected tester (no customers): applausetester+exportemplate@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10/Chrome
App Component: Chat Report View

Action Performed:

1. Log in with applausetester+exportemplate@applause.expensifail.com
2. Check if there is a second workspace with an expense submitted in the workspace chat. If not, create both the workspace and the expense
3. Go to the Spend > Reports
4. Select 2 reports, one from each workspace
5. Click the x selected dropdown green button for more options,-> Export
6. Verify you see the options: Basic export, All Data - expense level, All Data - report level, Default CSV (the custom user export template)

Expected Result:

Verify you see the options: Basic export, All Data - expense level, All Data - report level, Default CSV (the custom user export template)

Actual Result:

Missing "Default CSV" option

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7178561_1781239828124.csv.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7178561

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022065374580949583347
• Upwork Job ID: 2065374580949583347
• Last Price Increase: 2026-06-19

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

[MelvinBot]

Proposal

Problem

When selecting reports from two different workspaces in Spend → Reports and opening the Export menu, the workspace-level "Default CSV" template (and any other policy-level custom template) is missing. It appears correctly when all selected reports belong to a single workspace.

Root Cause

The bulk-export submenu only resolves a policy — and therefore policy-level export templates — when exactly one workspace is selected.

In useSearchBulkActions.ts:1317:

const policy = selectedPolicyIDs.length === 1 ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${selectedPolicyIDs.at(0)}`] : undefined;
const exportTemplates = getExportTemplates(integrationsExportTemplates ?? [], csvExportLayouts ?? {}, translate, policy, includeReportLevelExport);

When reports span 2 workspaces, selectedPolicyIDs.length !== 1, so policy is undefined. Inside getExportTemplates, the policy-level templates are only collated when a policy is passed, so they are dropped:

const policyInAppTemplates = policy
    ? Object.entries(policy.exportLayouts ?? {}).map(...)
    : [];

"Default CSV" is a workspace-level template stored in policy.exportLayouts — the account-level one is deliberately excluded at Search.ts:1305-1308 — which is why it only ever surfaces via the resolved policy and disappears as soon as more than one workspace is in the selection.

Why the other three options still show

"Basic export", "All Data - expense level" (EXPENSE_LEVEL_EXPORT) and "All Data - report level" (REPORT_LEVEL_EXPORT) are added unconditionally and don't depend on a policy (Search.ts:1293-1303), so only the policy-scoped templates go missing.

Proposed Change

Aggregate policy-level export templates across all selected workspaces instead of only when a single policy is selected. Pass the set of selected policies into getExportTemplates, collate every policy's exportLayouts, and de-duplicate by template name so a template common to all selected workspaces (e.g. "Default CSV") still appears once.

Implementation note / open question

getExportTemplates currently takes a single optional policy; it would change to accept the selected policies (or their exportLayouts). The export itself is queued via queueExportSearchWithTemplate, which sends a single policyID plus templateName. We should confirm how the backend QUEUE_EXPORT_SEARCH_WITH_TEMPLATE command resolves a policy-scoped template when reportIDList spans multiple workspaces — whether it matches the template per-report by name (in which case the App-only fix is sufficient) or requires a policyID per report. That command lives outside the App repo, so if it needs per-policy resolution a separate internal/backend change is required. The visible gating bug, however, is entirely in App.

Alternatives Considered

• Resolve to the first selected policy's templates — rejected; it would show one workspace's custom templates while silently omitting the other's, producing inconsistent/misleading results.

---

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

[lorretheboy]

Proposal

What is the root cause of that problem?

The "Default CSV" entry is a workspace-level custom export template. In getExportTemplates, these only get added to the list when a policy is passed in — they come from policy.exportLayouts:

App/src/libs/actions/Search.ts

Lines 1305 to 1313 in 462368d

	// 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))
	: [];

In the Search bulk-action menu, the policy is only resolved when exactly one policy is selected; otherwise it falls back to undefined:

App/src/hooks/useSearchBulkActions.ts

Lines 1317 to 1318 in 462368d

	const policy = selectedPolicyIDs.length === 1 ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${selectedPolicyIDs.at(0)}`] : undefined;
	const exportTemplates = getExportTemplates(integrationsExportTemplates ?? [], csvExportLayouts ?? {}, translate, policy, includeReportLevelExport);

So the chain is: select 2 reports from 2 workspaces → selectedPolicyIDs.length === 2 → policy = undefined → getExportTemplates receives no policy → policyInAppTemplates is empty → the workspace template "Default CSV" is dropped. With a single workspace the length is 1, the policy resolves, and the option appears — which is why the bug only shows across two workspaces.

selectedPolicyIDs itself is correctly populated from every selected item, so the data is available — it's the === 1 guard that discards it:

App/src/hooks/useSearchBulkActions.ts

Lines 436 to 445 in 462368d

	const selectedPolicyIDs = useMemo(
	() => [
	...new Set(
	Object.values(selectedTransactions)
	.map((transaction) => transaction.policyID)
	.filter(Boolean),
	),
	],
	[selectedTransactions],
	);

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

Stop collapsing the selection to a single policy when building the template list. Instead of the selectedPolicyIDs.length === 1 ? ... : undefined guard, gather the export templates for every selected policy and merge them (deduping by template name so a "Default CSV" shared across workspaces isn't listed twice). Each template already carries its own policyID, which is what beginExportWithTemplate uses, so per-workspace templates stay correctly attributed.

The cleanest place is the loop that builds the submenu here — feed it templates collected across all selected policies rather than the single resolved policy:

App/src/hooks/useSearchBulkActions.ts

Lines 1444 to 1459 in 462368d

	if (!allSelectedAreDeleted && !includesGroupExport) {
	for (const template of exportTemplates) {
	const isStandardTemplate =
	template.templateName === CONST.REPORT.EXPORT_OPTIONS.EXPENSE_LEVEL_EXPORT || template.templateName === CONST.REPORT.EXPORT_OPTIONS.REPORT_LEVEL_EXPORT;
	exportOptions.push({
	text: template.name,
	icon: isStandardTemplate ? expensifyIcons.Table : expensifyIcons.TablePencil,
	description: template.description,
	onSelected: () => {
	beginExportWithTemplate(template.templateName, template.type, template.policyID);
	},
	shouldCloseModalOnSelect: true,
	shouldCallAfterModalHide: true,
	});
	}
	}

The single-policy policy value can still be used for the connected-integration / "mark as exported" options, since those legitimately require one workspace.

What alternative solutions did you explore? (Optional)

Change getExportTemplates to accept a list of policies (instead of one) and have it internally flatMap each policy's exportLayouts, deduping by name. This makes the shared helper handle multi-workspace selections directly and keeps both call sites (useSearchBulkActions and useExportActions) consistent.

[melvin-bot]

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

[melvin-bot]

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

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[mukhrr]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-12 10:07:35 UTC.

Proposal

What is the root cause of that problem?

The regression comes from the shared getExportTemplates() helper added in PR #69802. That PR intentionally deduped export-option creation and included a test note that workspace-level templates should not show when selected expenses come from multiple workspaces. But the same helper also filters out the account-level Default CSV template unconditionally:

App/src/libs/actions/Search.ts

Lines 1305 to 1308 in e18daff

	// 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));

That is OK for the single-workspace case because policy-level templates are still loaded from policy.exportLayouts:

App/src/libs/actions/Search.ts

Lines 1310 to 1313 in e18daff

	// 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))
	: [];

But in the bulk Reports export flow, we only pass a policy when every selected transaction belongs to one workspace:

App/src/hooks/useSearchBulkActions.ts

Lines 1264 to 1265 in e18daff

	const policy = selectedPolicyIDs.length === 1 ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${selectedPolicyIDs.at(0)}`] : undefined;
	const exportTemplates = getExportTemplates(integrationsExportTemplates ?? [], csvExportLayouts ?? {}, translate, policy, includeReportLevelExport);

So when selected reports span two workspaces:

1. policy becomes undefined.
2. Policy-level exportLayouts are skipped.
3. Account-level Default CSV is also filtered out.
4. The menu only shows Basic export and standard templates.

Similar cases confirm this is specific to the multi-policy bulk flow: single-report export via useExportActions() passes the report policy into getExportTemplates(), so policy templates can still be shown; selected-transaction export inside one report also passes the report policy. The missing case is bulk search/report export where there is no single policy context.

History also supports this RCA: the PR test steps for #69802 asked testers to create an account CSV template “with a name other than Default CSV Export Template”, so this exact default-template edge case was not covered.

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

Keep the current default behavior of excluding account-level Default CSV, so we do not introduce duplicates in existing single-policy menus. Add an explicit opt-in to include the account-level Default CSV only when the caller has no single policy context.

Small illustrative diff:

function getExportTemplates(
    integrationsExportTemplates: ExportTemplate[],
    csvExportLayouts: Record<string, ExportTemplate>,
    translate: LocalizedTranslate,
    policy?: Policy,
    includeReportLevelExport = true,
+   includeDefaultCSVAccountTemplate = false,
): ExportTemplate[] {
    ...
    const accountInAppTemplates = Object.entries(csvExportLayouts ?? {})
-       .filter(([, layout]) => layout.name !== CONST.REPORT.EXPORT_OPTION_LABELS.DEFAULT_CSV)
+       .filter(([, layout]) => includeDefaultCSVAccountTemplate || layout.name !== CONST.REPORT.EXPORT_OPTION_LABELS.DEFAULT_CSV)
        .map(([templateName, layout]) => normalizeTemplate(templateName, layout, CONST.EXPORT_TEMPLATE_TYPES.IN_APP));

Then enable it only for the affected bulk Reports/Search export case when there is no single selected policy:

const policy = selectedPolicyIDs.length === 1
    ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${selectedPolicyIDs.at(0)}`]
    : undefined;
+const shouldIncludeDefaultCSVAccountTemplate = selectedPolicyIDs.length !== 1;

const exportTemplates = getExportTemplates(
    integrationsExportTemplates ?? [],
    csvExportLayouts ?? {},
    translate,
    policy,
    includeReportLevelExport,
+   shouldIncludeDefaultCSVAccountTemplate,
);

To avoid regressions, the new parameter should default to false, so useExportActions, useSelectedTransactionsActions, exported-to filters, and existing single-workspace menus keep their current behavior. We should add a focused test for getExportTemplates() or useSearchBulkActions covering:

• one selected policy: no duplicate account-level Default CSV
• multiple selected policies: account-level Default CSV appears
• standard templates and non-default account templates still appear as before

What alternative solutions did you explore? (Optional)

We could collect exportLayouts from every selected policy and show templates common to all selected workspaces, but that is broader and risks exporting with the wrong policyID. The existing API already supports account-level templates with policyID: undefined, so selectively restoring the account-level Default CSV fallback is the smallest fix for this regression.

[yusufdeveloper2903]

Proposal

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

When selecting reports from two different workspaces in Search (Spend → Reports) and opening the bulk Export menu, the user's Default CSV export template is missing. It shows correctly when the selected reports all belong to a single workspace.

What is the root cause of that problem?

The export submenu for bulk selection is built in useSearchBulkActions. The policy passed to getExportTemplates is only resolved when exactly one policy is selected — otherwise it's undefined:

App/src/hooks/useSearchBulkActions.ts

Lines 1317 to 1318 in d756515

	const policy = selectedPolicyIDs.length === 1 ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${selectedPolicyIDs.at(0)}`] : undefined;
	const exportTemplates = getExportTemplates(integrationsExportTemplates ?? [], csvExportLayouts ?? {}, translate, policy, includeReportLevelExport);

So selecting reports from two workspaces makes selectedPolicyIDs.length === 1 false → policy becomes undefined.

Now look at getExportTemplates. The account-level in-app templates explicitly drop the layout named Default CSV, and the Default CSV is instead expected to come back via the policy-level templates (which are only collated when a policy is passed):

App/src/libs/actions/Search.ts

Lines 1305 to 1313 in d756515

	// 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))
	: [];

The two facts combine into the bug:

• The account-level Default CSV (from csvExportLayouts, NVP nvp_expensify_csvExportLayouts) is filtered out unconditionally at L1307.
• With multiple workspaces selected, policy is undefined, so policyInAppTemplates is [] (L1311-L1313) and the policy-level Default CSV is never added either.

Result: Default CSV is excluded from both sources and disappears entirely. With a single workspace the policy is defined, so the policy-level Default CSV is included and everything looks correct — which is exactly why this only reproduces across two workspaces.

This is also why the single-report Export menu (useExportActions) never has the problem — it always passes the report's own policy to getExportTemplates, so policy is never undefined:

App/src/hooks/useExportActions.ts

Lines 62 to 64 in d756515

	const connectedIntegration = getValidConnectedIntegration(policy);
	const connectedIntegrationFallback = getConnectedIntegration(policy);
	const exportTemplates = getExportTemplates(integrationsExportTemplates ?? [], csvExportLayouts ?? {}, translate, policy);

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

The Default CSV is filtered from the account-level list only to avoid duplicating it with the policy-level copy. That dedupe is only meaningful when a policy is present. When there's no single policy (the multi-workspace case), the account-level Default CSV is the correct, policy-agnostic source and should be kept.

So I'd gate the exclusion on whether a policy was provided, in getExportTemplates:

     const accountInAppTemplates = Object.entries(csvExportLayouts ?? {})
-        .filter(([, layout]) => layout.name !== CONST.REPORT.EXPORT_OPTION_LABELS.DEFAULT_CSV)
+        .filter(([, layout]) => !policy || layout.name !== CONST.REPORT.EXPORT_OPTION_LABELS.DEFAULT_CSV)
         .map(([templateName, layout]) => normalizeTemplate(templateName, layout, CONST.EXPORT_TEMPLATE_TYPES.IN_APP));

Behavior after the fix:

• Multiple workspaces (policy === undefined): account-level Default CSV is included once (its policyID is undefined, which is exactly what a cross-workspace export needs — beginExportWithTemplate/queueExportSearchWithTemplate already accept an undefined policyID).
• Single workspace (policy defined): unchanged — account-level Default CSV stays filtered and the policy-level copy is shown, so there's still exactly one Default CSV (no duplicate).
• Single report (useExportActions, useSelectedTransactionsActions): always pass a defined policy, so they're unaffected.

This fix is centralized in getExportTemplates, so it covers every caller (bulk search and single-report) consistently, and is platform-agnostic (the affected platforms — Android/iOS/Web — all route through this same hook). Offline behavior is unchanged.

I'd also add a unit test to getExportTemplates asserting that, given a csvExportLayouts containing a Default CSV layout and no policy, the returned templates include Default CSV; and that with a policy it is not duplicated.

What alternative solutions did you explore? (Optional)

• Fix at the call site in useSearchBulkActions (L1317) by aggregating the Default CSV from each selected policy's exportLayouts and de-duplicating by name. Rejected: it's more code, leaks the dedupe concern into the hook, only fixes the bulk path (not future callers), and we'd still have to choose a policyID for an option that is conceptually account-level.
• Always include the account-level Default CSV (drop the filter entirely). Rejected: in the single-workspace case the policy-level copy is still added, so this would render Default CSV twice.