[$250] Support bulk Mark as Exported for accounting integrations in New Expensify

[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:
Reproducible in staging?: Needs Reproduction
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: @Getrudygidashang
Slack conversation (hyperlinked to channel name): #Expensify bugs

Action Performed:

1. Connect to any accounting integrations (Netsuite here)
2. Have 50+ reports ready for export
3. Navigate to Reports > select all
4. Click All matching items selected dropdown
5. Observe the options

Expected Result:

New Expensify should provide a bulk action to manually mark selected reports or expenses as exported to an accounting integration, consistent with the existing Classic Expensify functionality.

Actual Result:

bulk manually marking reports or expenses as exported to an accounting integration is not displayed in All matching items selected dropdown

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

Issue Owner

Current Issue Owner: @ahmedGaber93

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022075581380402928785
• Upwork Job ID: 2075581380402928785
• Last Price Increase: 2026-07-10

[MelvinBot]

Proposal

TL;DR: A bulk "Mark as exported" action already exists in the Reports selection dropdown — but it's hidden whenever the selection spans more than one workspace (and it also requires whole reports, not individual expenses, to be selected). Selecting 50+ reports via "All matching items selected" almost always crosses workspaces, so the option never appears.

What is the root cause of that problem?

The bulk export options (both "Export to <integration>" and "Mark as exported") are built inside getExportOptions() in useSearchBulkActions.ts, and the entire block is wrapped in if (connectedIntegration) { … }.

connectedIntegration is derived from a single policy:

• useSearchBulkActions.ts:1478 — policy = selectedPolicyIDs.length === 1 ? policies[…] : undefined
• useSearchBulkActions.ts:1483 — connectedIntegration = getConnectedIntegration(policy) → returns undefined for an undefined policy.

selectedPolicyIDs is a de-duplicated set across all selected transactions' policyIDs (useSearchBulkActions.ts:484-493). When the selection contains reports from 2+ workspaces, selectedPolicyIDs.length > 1, so policy is undefined, connectedIntegration is undefined, and neither export option is pushed into the dropdown.

A second gate — includeReportLevelExport, which requires areFullReportsSelected (useSearchBulkActions.ts:1476) — also hides it if a mix of individual expenses (not whole reports) is selected.

So this is not a fully-missing feature: the bulk MarkAsExported API path already exists (markAsManuallyExported(reportIDs[], connectionName) in Report/index.ts → MarkAsExported command). It just only surfaces for a single-workspace, full-report selection.

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

Relax the single-policy gate on the Reports tab so bulk "Mark as exported" appears for multi-workspace selections:

1. Instead of requiring selectedPolicyIDs.length === 1 to compute one connectedIntegration, group the selected reports by their policy's connected integration (per-report data is already available via the existing canReportBeExported helper at useSearchBulkActions.ts:1489-1503).
2. Show the "Mark as exported" option when every selected report is individually markable-as-exported (each to its own workspace's integration), then dispatch markAsManuallyExported grouped per connection name. markAsManuallyExported already accepts an array of report IDs, so the main work is calling it once per distinct integration.
3. Keep the "Export to integration" (live re-export) behavior as-is or apply the same grouping, per product preference.

What alternative solutions did you explore? (Optional)

• Simplest partial fix: keep single-integration requirement but detect it across reports (allow the option when all selected reports share the same connected integration even across different workspaces). Lower effort, but still hides the option for genuinely mixed-integration selections.
• Confirm the exact reporter scenario (single vs. multiple workspaces) via reproduction before committing to scope.

Confidence & verification notes

• Confidence: Medium-High. The code path (connectedIntegration gate → hidden options) is verified with file:line evidence. I did not reproduce the reporter's exact selection, so I can't be 100% certain their set crossed workspaces vs. failing the full-report gate — but both lead to the same hidden-option symptom.
• The empty-selectedTransactions theory was refuted: on the Reports tab, selectedReports is derived from selectedTransactions, and the "select all matching" reconcile effect repopulates selectedTransactions (with policyID) — so the gap is the multi-policy length === 1 restriction, not empty selection state.
• Suggested repro to confirm: on the Reports tab, run a search spanning ≥2 workspaces connected to an accounting integration, "select all matching items", and confirm the export sub-menu is absent; then repeat within a single workspace and confirm it appears.

Related issues

• [CFI] [$250] Update the Export menu by adding dividers between groups and ordering them alphabetically #94706 — reorganizing/ordering the Export menu (same surface).
• [$250] Fix sorting on Exported-to filter. #95149 — sorting on the Exported-to filter (adjacent area).

---

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

[shivang-goliyan]

Proposal

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

When you select all matching reports in Search and open the "All matching items selected" dropdown, "Mark as Exported" is missing, even for reports on a policy with an accounting integration like NetSuite.

What is the root cause of that problem?

The option is not hidden by an early return in the all-matching branch. In src/hooks/useSearchBulkActions.ts, getExportOptions() is called unconditionally at L1632, before any all-matching check, and the string areAllMatchingItemsSelected never appears inside the function body (L1463-1630). The all-matching branch at L1657-1659 returns the same exportButtonOption that carries the full subMenuItems. The reporter's own screenshot confirms this: the CSV/template rows (Basic export, All Data, NS Import File) are all built inside getExportOptions() at L1588-1627, so their presence proves the function ran.

"Mark as Exported" is absent because it is never pushed inside getExportOptions() — the gates in front of it fail. There are three, and each one independently hides the option:

• Single-policy gate (L1471, L1476, L1510): policy is only set when selectedPolicyIDs.length === 1, so getConnectedIntegration(policy) returns undefined for any selection spanning 2+ workspaces (PolicyUtils.ts:2251 does policy?.connections?...). The if (connectedIntegration) guard at L1510 then drops both "Export to " and "Mark as exported". A genuine cross-workspace "select all" hits this every time.
• All-or-nothing eligibility (L1504-1508): canMarkAllReportsAsExported is selectedReports.every((r) => canReportBeExported(r, MARK_AS_EXPORTED)). One open or processing report makes .every() false and hides the option for the entire batch.
• ID-based action with no query variant (L1577): markAsManuallyExported(selectedReportIDs, connectedIntegration) runs on the loaded selection only. selectedReportIDs / selectedReports derive from selectedTransactions (L360, L484-493) — i.e. the loaded rows. The CSV/template handlers switch to a query-based call when areAllMatchingItemsSelected (L630, L726); MarkAsExported has no such branch, so even once it shows, it cannot reach reports past the loaded page.

There is a fourth, narrower defect that the open PR #95988 targets: the policy reads at L1471/L1487 use live Onyx (policies?.[...]) while the report read at L1488 already uses the snapshot-aware getReportFromSearchSnapshot. getPolicyFromSearchSnapshot is imported (L24) and used at L827/L1190 but not here, so on a fresh load where the policy exists only in the search snapshot, connectedIntegration is undefined and the single-policy gate fires spuriously. That is real, and it is the right fix for the fresh-load case — but it is narrow. It will not surface the option for a multi-workspace selection, and it will not cover unloaded reports.

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

Three changes in src/hooks/useSearchBulkActions.ts, all required — any one alone leaves the reported case broken.

1. Read the policy from the search snapshot at L1471/L1487 via the already-imported getPolicyFromSearchSnapshot, mirroring the report read at L1488. This is PR Fix missing bulk export-to-integration options on fresh load (Search Reports) #95988's change and it should land.
2. Stop collapsing the selection to a single policy at L1471. Resolve the connected integration across the selected policies rather than returning undefined whenever selectedPolicyIDs.length !== 1; when the selected reports span multiple integration-connected workspaces, the option must still be offered. Without this, the ordinary cross-workspace "select all" — which is exactly what the reporter did — still hides it.
3. Give MarkAsExported a query-based path, mirroring the CSV/template handlers at L630/L726: when areAllMatchingItemsSelected is true, the action must target the full query result instead of selectedReportIDs.

Point 3 is the one that decides whether this fix is real. Doing only 1 and 2 makes the option appear and is therefore easy to mistake for a complete fix — but the action still runs on selectedReportIDs, so a user who selects "all matching" and clicks it silently marks only the loaded page as exported, and believes the rest were exported too. That is a worse bug than the one reported, and it is invisible in a screenshot.

What alternative solutions did you explore? (Optional)

Fixing visibility alone (points 1 and 2 without 3) is the tempting minimal change and I would reject it for the reason above — the option appears but under-reports silently. Relaxing the all-or-nothing eligibility at L1504-1508 to a "some" check is also possible, but it changes what the button means for a mixed batch and should be a product decision, not folded into this fix; the batch it currently blocks is at least honestly blocked.

[yusufdeveloper2903]

Proposal

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

When a user selects reports on the Search Reports tab and opens the All matching items selected dropdown, the bulk Mark as exported action for the connected accounting integration is not offered.

What is the root cause of that problem?

The bulk Mark as exported action is actually already implemented in useSearchBulkActions.ts — it is pushed into the Export sub-menu here, and it already calls the array-capable markAsManuallyExported action:

App/src/hooks/useSearchBulkActions.ts

Lines 1580 to 1590 in 89a5c2d

	if (canMarkAllReportsAsExported) {
	exportOptions.push({
	text: translate('workspace.common.markAsExported'),
	icon: integrationIcon,
	onSelected: () => handleExportAction(() => markAsManuallyExported(selectedReportIDs, connectedIntegration)),
	shouldCloseModalOnSelect: true,
	shouldCallAfterModalHide: true,
	displayInDefaultIconColor: true,
	additionalIconStyles: styles.integrationIcon,
	});
	}

markAsManuallyExported(reportIDs, connectionName) loops the whole reportIDs array into a single MarkAsExported write, so the backend already supports bulk marking (Report/index.ts:6083-6159). So this is not a missing-feature problem — it's a gating problem: the whole integration block is hidden in the reporter's "select all 50+ reports" scenario.

The entire "Export to X" + "Mark as exported" block is wrapped in if (connectedIntegration), and connectedIntegration is derived from a single policy:

App/src/hooks/useSearchBulkActions.ts

Lines 1478 to 1483 in 89a5c2d

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

The single-policy gate — this is what hides it on "select all": policy is set only when selectedPolicyIDs.length === 1, otherwise it's undefined. getConnectedIntegration(undefined) returns undefined because it does policy?.connections?.[integration] (PolicyUtils.ts:2251-2253). The Search Reports view queries across all the user's workspaces, so "select all" over 50+ reports almost always spans more than one workspace → selectedPolicyIDs.length !== 1 → connectedIntegration is undefined → the if (connectedIntegration) block at line 1517 never runs, so both the "Export to X" and "Mark as exported" options are dropped.

Sibling path — the same gate hides "Export to integration": canExportAllReportsToIntegration and canMarkAllReportsAsExported both live under the same connectedIntegration guard, so this fix restores both at once:

App/src/hooks/useSearchBulkActions.ts

Lines 1506 to 1515 in 89a5c2d

	const canExportAllReportsToIntegration =
	isReportsTab &&
	selectedReportIDs.length > 0 &&
	includeReportLevelExport &&
	selectedReports.every((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.EXPORT_TO_INTEGRATION));
	const canMarkAllReportsAsExported =
	isReportsTab &&
	selectedReportIDs.length > 0 &&
	includeReportLevelExport &&
	selectedReports.every((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.MARK_AS_EXPORTED));

Why it reproduces as "Needs Reproduction": when the selection is confined to a single connected workspace (e.g. filter to one workspace, then select all), selectedPolicyIDs.length === 1 holds, connectedIntegration resolves to NetSuite, and both options do appear — which is exactly why the bug can't be reproduced with a one-workspace selection and only shows with a broad "select all".

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

useSearchBulkActions.ts — resolve connectedIntegration from all selected workspaces instead of only from a single one. Keep policy as-is (it's still needed for getExportTemplates on line 1479); only change how the integration is derived:

- const connectedIntegration = getConnectedIntegration(policy);
+ const selectedIntegrations = new Set(
+     selectedPolicyIDs
+         .map((id) => getConnectedIntegration(policies?.[`${ONYXKEYS.COLLECTION.POLICY}${id}`]))
+         .filter(Boolean),
+ );
+ // Only offer a single-integration bulk action when every selected workspace shares one integration
+ const connectedIntegration = selectedIntegrations.size === 1 ? [...selectedIntegrations].at(0) : undefined;

This surfaces both "Export to X" and "Mark as exported" whenever every selected report's workspace shares one connected integration, no matter how many workspaces are selected — which is the reporter's exact case. markAsManuallyExported(selectedReportIDs, connectedIntegration) and exportToIntegrationOnSearch(hash, selectedReportIDs, connectedIntegration, currentSearchKey) already take the full selectedReportIDs array plus one connectionName, so no backend or action change is needed — this is a FE-only gating change.

This is safe because:

• When the selection genuinely mixes integrations (e.g. one NetSuite workspace + one QBO workspace), selectedIntegrations.size > 1 → connectedIntegration stays undefined and the block is correctly hidden — a single MarkAsExported/ReportExport call can only target one integration.
• The per-report eligibility gate (canMarkAllReportsAsExported → selectedReports.every(canReportBeExported(..., MARK_AS_EXPORTED))) is untouched, so we still only show the option when every selected report is in an exportable state — no change to which reports are actually marked.
• getConnectedIntegration is already null-safe for a missing policy, so .map(...).filter(Boolean) can't throw on a not-yet-loaded workspace.

Note: the eligibility check is .every(...), so if any selected report isn't in an exportable state the option still disappears even after this fix — this matches the existing bulk pattern (Approve uses the same selectedReports.every((report) => report.canApprove) at line 1737). If product wants "select all" to mark just the eligible subset, we can instead filter selectedReportIDs down to the exportable ones inside the onSelected handler and gate with .some(...), but I'd keep the stricter .every(...) unless product asks for the subset behavior.

Result: selecting reports across one or many workspaces that share a single connected integration surfaces the bulk Mark as exported (and Export to X) action in the All matching items selected dropdown, matching Classic — with no backend change.

What alternative solutions did you explore? (Optional)

• Relax the per-report .every(canReportBeExported) to .some(...) so a heterogeneous selection still shows the option — rejected as the primary fix because it doesn't address the reporter's repro (the block is dropped before eligibility is ever evaluated, at the connectedIntegration gate), and because .every(...) is the established bulk-gating pattern here (Approve/Hold/Unhold all use .every). Listed above as an optional product-driven follow-up, not the root-cause fix.
• Group selected reports by policy and dispatch one markAsManuallyExported per distinct integration (true multi-integration bulk) — rejected because it would render multiple different "Mark as exported to X / to Y" rows and changes product semantics; the single-integration constraint is inherent to the MarkAsExported command taking one connectionName. The size === 1 check above is the minimal change that keeps one coherent action.
• Treating this as a brand-new feature — rejected: the option, the array-capable action, the params type, and the translation key (workspace.common.markAsExported) already exist on main; only the visibility gate needs broadening.

[dilshodmackbook-sketch]

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

Proposal

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

On a workspace connected to an accounting integration (NetSuite in the report), selecting all matching reports on the Reports page (50+, so the selection enters the "All matching items selected" state) offers no bulk way to export them to the integration or mark them as manually exported — the dropdown only shows CSV/template exports. Classic Expensify supports bulk "Mark as exported", so this is a parity gap.

What is the root cause of that problem?

Choosing "Select all" for all matching items only flips a flag — the concrete selection keeps holding just the currently loaded page:

App/src/components/Search/SearchList/SearchSelectAllMenu.tsx

Lines 49 to 52 in 89bfa7e

	closeSelectAllMenu();
	selectAllMatchingItems(true);
	}, [closeSelectAllMenu, selectAllMatchingItems]);

In that state the bulk-actions dropdown collapses to the Export submenu only:

App/src/hooks/useSearchBulkActions.ts

Lines 1651 to 1653 in 89bfa7e

	if (areAllMatchingItemsSelected) {
	return [exportButtonOption];
	}

Inside that submenu, both integration entries ("Export to X", "Mark as exported") are entirely ID-scoped, in two ways:

1. Their visibility flags run selectedReports.every(canReportBeExported) over the loaded rows, resolving each report from the local search snapshot — so eligibility only ever describes the loaded page, and a single row that fails (or isn't hydrated) hides the option for the whole selection:

App/src/hooks/useSearchBulkActions.ts

Lines 1476 to 1503 in 89bfa7e

	const canReportBeExported = (report: (typeof selectedReports)[0], exportOption: ValueOf<typeof CONST.REPORT.EXPORT_OPTIONS>) => {
	if (!report.reportID) {
	return false;
	}
	const reportPolicy = policies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
	const snapshotReport = getReportFromSearchSnapshot(report.reportID, currentSearchResults?.data, allReports);
	if (!snapshotReport) {
	return false;
	}
	const reportExportOptions = getSecondaryExportReportActions(accountID ?? CONST.DEFAULT_NUMBER_ID, currentUserLogin ?? '', snapshotReport, bankAccountList, reportPolicy);
	return reportExportOptions.includes(exportOption);
	};
	const canExportAllReportsToIntegration =
	isReportsTab &&
	selectedReportIDs.length > 0 &&
	includeReportLevelExport &&
	selectedReports.every((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.EXPORT_TO_INTEGRATION));
	const canMarkAllReportsAsExported =
	isReportsTab &&
	selectedReportIDs.length > 0 &&
	includeReportLevelExport &&
	selectedReports.every((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.MARK_AS_EXPORTED));

2. Even when they do show, the handlers act on selectedReportIDs (the loaded page only):

App/src/hooks/useSearchBulkActions.ts

Lines 1567 to 1578 in 89bfa7e

	if (canMarkAllReportsAsExported) {
	exportOptions.push({
	text: translate('workspace.common.markAsExported'),
	icon: integrationIcon,
	onSelected: () => handleExportAction(() => markAsManuallyExported(selectedReportIDs, connectedIntegration)),
	shouldCloseModalOnSelect: true,
	shouldCallAfterModalHide: true,
	displayInDefaultIconColor: true,
	additionalIconStyles: styles.integrationIcon,
	});
	}
	}

and markAsManuallyExported fundamentally cannot address unloaded reports — it must build a per-report optimistic report action and sends data: JSON.stringify([{reportID, label, optimisticReportActionID}, …]) to the MarkAsExported command:

App/src/libs/actions/Report/index.ts

Lines 6083 to 6159 in 89bfa7e

	function markAsManuallyExported(reportIDs: string[], connectionName: ConnectionName) {
	const label = CONST.POLICY.CONNECTIONS.NAME_USER_FRIENDLY[connectionName];
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.REPORT>> = [];
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.SNAPSHOT>> = [];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.REPORT>> = [];
	const reportData: Array<{reportID: string; label: string; optimisticReportActionID: string}> = [];
	// Process each report ID
	for (const reportID of reportIDs) {
	const action = buildOptimisticExportIntegrationAction(connectionName, true);
	const optimisticReportActionID = action.reportActionID;
	const previousExportedValue = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`]?.isExportedToIntegration;
	reportData.push({
	reportID,
	label,
	optimisticReportActionID,
	});
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: {
	[optimisticReportActionID]: action,
	},
	});
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	pendingFields: {
	export: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
	},
	isExportedToIntegration: true,
	},
	});
	successData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: {
	[optimisticReportActionID]: {
	pendingAction: null,
	},
	},
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: {
	[optimisticReportActionID]: {
	errors: getMicroSecondOnyxErrorWithTranslationKey('common.genericErrorMessage'),
	},
	},
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	pendingFields: {
	export: null,
	},
	isExportedToIntegration: previousExportedValue,
	},
	});
	}
	const params = {
	markedManually: true,
	data: JSON.stringify(reportData),
	} satisfies MarkAsExportedParams;
	API.write(WRITE_COMMANDS.MARK_AS_EXPORTED, params, {optimisticData, successData, failureData});

Compare that with the CSV/template exports — the only entries the reporter sees. Those work in the all-matching state precisely because they switch to a query-based call, sending the serialized search query for the backend to resolve instead of an ID list:

App/src/hooks/useSearchBulkActions.ts

Lines 627 to 644 in 89bfa7e

	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,

So the gap isn't just over-strict gating: there is no query-based variant of MarkAsExported/ReportExport at all, meaning no code path can mark "all matching" reports as exported when the matching set exceeds the loaded page.

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

Give the integration entries a query-based path in the all-matching state, mirroring how the template/CSV exports already handle it.

1. Add markAsExportedOnSearch to src/libs/actions/Search.ts, next to the existing exportToIntegrationOnSearch (which already shows the snapshot/optimistic patterns to reuse):

function markAsExportedOnSearch(hash: number, queryJSON: SearchQueryJSON, connectionName: ConnectionName, loadedReportIDs: string[], currentSearchKey?: SearchKey) {
    // Build the same optimistic export-integration report actions + isExportedToIntegration
    // updates markAsManuallyExported builds, but only for the loaded reports.
    const params = {
        markedManually: true,
        data: JSON.stringify(reportData), // loaded page, for optimistic reconciliation
        jsonQuery: serializeQueryJSONForBackend(queryJSON), // backend resolves ALL matching reports
    } satisfies MarkAsExportedParams;

    API.write(WRITE_COMMANDS.MARK_AS_EXPORTED, params, {optimisticData, successData, failureData});
}

MarkAsExportedParams gets an optional jsonQuery?: string. When present, Auth resolves the full matching set from the query and validates eligibility per report server-side — the same contract queueExportSearchWithTemplate/queueExportSearchItemsToCSV already rely on, so this needs a small Auth counterpart (internal). The same optional param on ReportExportParams covers the "Export to " entry.

2. In getExportOptions, branch on the all-matching state. Visibility stops depending on per-loaded-row hydration (the backend is the validator in this mode), and the handler routes to the query-based action:

const canMarkAllReportsAsExported =
    isReportsTab &&
    selectedReportIDs.length > 0 &&
    (areAllMatchingItemsSelected || (includeReportLevelExport && selectedReports.every((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.MARK_AS_EXPORTED))));

onSelected: () =>
    handleExportAction(() => {
        if (areAllMatchingItemsSelected && queryJSON) {
            markAsExportedOnSearch(hash, queryJSON, connectedIntegration, selectedReportIDs, currentSearchKey);
            return;
        }
        markAsManuallyExported(selectedReportIDs, connectedIntegration);
    }),

Same shape for canExportAllReportsToIntegration and its handler. The connectedIntegration gate (single policy across the selection) stays as is, so the entries still only appear where a single integration applies. The Search page already refreshes the snapshot after these writes, which reconciles the unloaded rows.

What specific scenarios should be covered in automated tests?

• On a reports-type search with a connected integration, with areAllMatchingItemsSelected on, the bulk dropdown contains both "Export to " and "Mark as exported"; they stay hidden when no integration is connected or the selection spans multiple policies.
• Selecting "Mark as exported" in the all-matching state calls MarkAsExported with the serialized jsonQuery plus the loaded-page data, and clears the selection; in the normal (page) selection state it keeps calling it with only the concrete ID list.
• Optimistic behavior: loaded reports get the export-integration report action and isExportedToIntegration: true; the failure path restores the previous values.
• The "export again" confirmation still shows when any selected loaded report was already exported.

What alternative solutions did you explore? (Optional)

• Only relaxing the visibility gates (what an earlier revision of this proposal suggested) and keeping markAsManuallyExported(selectedReportIDs): the option appears, but it would mark only the loaded page and silently skip the rest of the matching set — arguably worse than not offering it.
• A frontend-only variant: page through the search results to collect every matching report ID, then reuse the existing markAsManuallyExported with the full list. No backend change needed, but it issues N sequential Search calls for large sets and the matching set can drift while paginating; reasonable fallback if an Auth change is off the table.

[abbasifaizan70]

Proposal

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

When a workspace is connected to an accounting integration (e.g. NetSuite) and a user has 50+ reports on the Reports tab of Search, selecting "select all X matching items" (the flow offered once there are more results than are currently loaded) and opening the bulk-action "All matching items selected" dropdown does not offer a way to bulk "Mark as exported". This action already exists for a single report (via the report's export menu), but it effectively never appears for a bulk selection of 50+ reports, even though the underlying bulk code path for it exists.

What is the root cause of that problem?

The "select all matching items" option is only offered once the number of matching reports exceeds what has been fetched for the current page (hasMoreResults). CONST.SEARCH.RESULTS_PAGE_SIZE is 50, which is exactly why the repro calls for "50+ reports" — it's the smallest count that reliably exceeds one page and triggers this flow:

App/src/CONST/index.ts

Lines 6490 to 6491 in 9813012

	SEARCH: {
	RESULTS_PAGE_SIZE: 50,

Picking "select all matching items" calls selectAllMatchingItems(true) directly, without ever selecting the loaded rows first (that only happens through the separate "select all on this page" option):

App/src/components/Search/SearchList/SearchSelectAllMenu.tsx

Lines 39 to 51 in 9813012

	const shouldOpenSelectAllMenu = selectedItemsLength === 0 && !!currentSearchResults?.search?.hasMoreResults;
	const closeSelectAllMenu = useCallback(() => setIsSelectAllMenuVisible(false), []);
	const selectAllOnPage = useCallback(() => {
	closeSelectAllMenu();
	onAllCheckboxPress();
	}, [closeSelectAllMenu, onAllCheckboxPress]);
	const selectAllMatching = useCallback(() => {
	closeSelectAllMenu();
	selectAllMatchingItems(true);
	}, [closeSelectAllMenu, selectAllMatchingItems]);

selectAllMatchingItems itself only flips a boolean; it never populates selectedTransactions/selectedReports with the reports that match the query:

App/src/components/Search/SearchSelectionProvider.tsx

Lines 127 to 137 in 9813012

	const selectAllMatchingItems: SearchSelectionActionsValue['selectAllMatchingItems'] = (shouldSelectAll) => {
	setSelectionState((prevState) => {
	if (prevState.areAllMatchingItemsSelected === shouldSelectAll) {
	return prevState;
	}
	return {
	...prevState,
	areAllMatchingItemsSelected: shouldSelectAll,
	};
	});
	};

selectedTransactions/selectedReports are instead reconciled from filteredData, i.e. only the rows that are already loaded/rendered on screen for the current page — never rows belonging to matches beyond that page, regardless of areAllMatchingItemsSelected:

App/src/components/Search/SearchWriteActionsProvider.tsx

Lines 143 to 178 in 9813012

	for (const transactionGroup of filteredData) {
	if (!Object.hasOwn(transactionGroup, 'transactions') || !('transactions' in transactionGroup)) {
	continue;
	}
	if (transactionGroup.transactions.length === 0) {
	const reportKey = transactionGroup.keyForList;
	if (transactionGroup.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	continue;
	}
	if (reportKey && (reportKey in selectedTransactions || areAllMatchingItemsSelected)) {
	const [, emptyReportSelection] = mapEmptyReportToSelectedEntry(transactionGroup);
	newTransactionList[reportKey] = {
	...emptyReportSelection,
	isSelected: areAllMatchingItemsSelected || selectedTransactions[reportKey]?.isSelected,
	};
	}
	continue;
	}
	// For expense reports: when ANY transaction is selected, we want ALL transactions in the report selected.
	// This ensures report-level selection persists when new transactions are added.
	// Also check if the report itself was selected (when it was empty) by checking the reportID key
	const reportKey = transactionGroup.keyForList;
	const wasReportSelected = !!(reportKey && reportKey in selectedTransactions);
	const hasIndividualSelectedInGroup = transactionGroup.transactions.some(
	(transaction) => (!!transaction.keyForList && transaction.keyForList in selectedTransactions) || transaction.transactionID in selectedTransactions,
	);
	const propagateSelectionToAllRows = (isExpenseReportType && (wasReportSelected || hasIndividualSelectedInGroup)) || (wasReportSelected && !isExpenseReportType);
	for (const transactionItem of transactionGroup.transactions) {
	const listKey = transactionItem.keyForList ?? transactionItem.transactionID;
	const isSelected = listKey in selectedTransactions || transactionItem.transactionID in selectedTransactions;
	// Include transaction if: already individually selected, part of select-all, or group-level propagation (expense report / empty group expanded)
	const shouldInclude = isSelected || areAllMatchingItemsSelected || propagateSelectionToAllRows;

So with 50+ reports, selectedReports in the bulk-actions hook ends up holding only the first (loaded) batch of reports, not the true "all matching" set. The export submenu builder computes whether to offer "Export to <integration>" and "Mark as exported" with an all-or-nothing .every() check over that (partial) selectedReports list:

App/src/hooks/useSearchBulkActions.ts

Lines 1489 to 1515 in 9813012

	const canReportBeExported = (report: (typeof selectedReports)[0], exportOption: ValueOf<typeof CONST.REPORT.EXPORT_OPTIONS>) => {
	if (!report.reportID) {
	return false;
	}
	const reportPolicy = policies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
	const snapshotReport = getReportFromSearchSnapshot(report.reportID, currentSearchResults?.data, allReports);
	if (!snapshotReport) {
	return false;
	}
	const reportExportOptions = getSecondaryExportReportActions(accountID ?? CONST.DEFAULT_NUMBER_ID, currentUserLogin ?? '', snapshotReport, bankAccountList, reportPolicy);
	return reportExportOptions.includes(exportOption);
	};
	const canExportAllReportsToIntegration =
	isReportsTab &&
	selectedReportIDs.length > 0 &&
	includeReportLevelExport &&
	selectedReports.every((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.EXPORT_TO_INTEGRATION));
	const canMarkAllReportsAsExported =
	isReportsTab &&
	selectedReportIDs.length > 0 &&
	includeReportLevelExport &&
	selectedReports.every((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.MARK_AS_EXPORTED));

And isMarkAsExportedAction requires each report to be individually "finished" (approved, closed, or reimbursed) before it counts as eligible:

App/src/libs/ReportSecondaryActionUtils.ts

Lines 536 to 579 in 9813012

	function isMarkAsExportedAction(currentAccountID: number, currentUserLogin: string, report: Report, bankAccountList: OnyxEntry<BankAccountList>, policy?: Policy): boolean {
	if (!policy) {
	return false;
	}
	const connectedIntegration = getConnectedIntegration(policy);
	if (!connectedIntegration) {
	return false;
	}
	const isInvoiceReport = isInvoiceReportUtils(report);
	const isReportSender = isCurrentUserSubmitter(report);
	if (isInvoiceReport && isReportSender) {
	return true;
	}
	const isExpenseReport = isExpenseReportUtils(report);
	if (!isExpenseReport) {
	return false;
	}
	const isReportPayer = isPayerUtils(currentAccountID, currentUserLogin, report, bankAccountList, policy, false);
	const arePaymentsEnabled = arePaymentsEnabledUtils(policy);
	const isReportApproved = isReportApprovedUtils({report});
	const isReportClosed = isClosedReportUtils(report);
	const isReportReimbursed = isSettled(report);
	const isReportFinished = isReportClosed || isReportApproved || isReportReimbursed;
	if (!isReportFinished) {
	return false;
	}
	if (isReportPayer && arePaymentsEnabled) {
	return true;
	}
	const isAdmin = policy?.role === CONST.POLICY.ROLE.ADMIN;
	const isExporter = isPreferredExporter(policy, currentUserLogin);
	return isAdmin || isExporter;
	}

A realistic batch of 50+ "reports ready for export" almost always contains a mix of report states (some approved/closed, some still open or pending approval). Because canMarkAllReportsAsExported/canExportAllReportsToIntegration require every single selected report to pass isMarkAsExportedAction/isExportAction, a single ineligible report anywhere in that batch of 50 makes .every() return false, which silently removes "Mark as exported" (and "Export to <integration>") from the dropdown for the entire selection — this is exactly what the reporter observes. The two menu items are then built (and gated) here, using the unfiltered selectedReportIDs for the actual bulk write:

App/src/hooks/useSearchBulkActions.ts

Lines 1568 to 1590 in 9813012

	if (canExportAllReportsToIntegration) {
	exportOptions.push({
	text: connectionNameFriendly,
	icon: integrationIcon,
	onSelected: () => handleExportAction(() => exportToIntegrationOnSearch(hash, selectedReportIDs, connectedIntegration, currentSearchKey)),
	shouldCloseModalOnSelect: true,
	shouldCallAfterModalHide: true,
	displayInDefaultIconColor: true,
	additionalIconStyles: styles.integrationIcon,
	});
	}
	if (canMarkAllReportsAsExported) {
	exportOptions.push({
	text: translate('workspace.common.markAsExported'),
	icon: integrationIcon,
	onSelected: () => handleExportAction(() => markAsManuallyExported(selectedReportIDs, connectedIntegration)),
	shouldCloseModalOnSelect: true,
	shouldCallAfterModalHide: true,
	displayInDefaultIconColor: true,
	additionalIconStyles: styles.integrationIcon,
	});
	}

By contrast, the plain CSV/template export path in the same hook already special-cases areAllMatchingItemsSelected by delegating resolution of "all matching items" to the backend via the serialized query, rather than relying on the frontend's partial selectedReportIDs — the integration export/mark-as-exported path was never given the same "apply to what's actually eligible" treatment, which is why it disappears instead of degrading gracefully.

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

Change the gates from "every selected report must qualify" to "at least one selected report qualifies," and have the two actions operate only on the subset of selectedReports that is actually eligible, instead of the full (and possibly partially-ineligible) selectedReportIDs. This makes the bulk action available and correct whenever any of the currently-known selected reports can be exported/marked, instead of one ineligible report vetoing the option for everyone:

App/src/hooks/useSearchBulkActions.ts

Lines 1506 to 1515 in 9813012

	const canExportAllReportsToIntegration =
	isReportsTab &&
	selectedReportIDs.length > 0 &&
	includeReportLevelExport &&
	selectedReports.every((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.EXPORT_TO_INTEGRATION));
	const canMarkAllReportsAsExported =
	isReportsTab &&
	selectedReportIDs.length > 0 &&
	includeReportLevelExport &&
	selectedReports.every((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.MARK_AS_EXPORTED));

const exportableReportIDs = selectedReports
    .filter((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.EXPORT_TO_INTEGRATION))
    .map((report) => report.reportID)
    .filter((reportID): reportID is string => reportID !== undefined);
const markAsExportedReportIDs = selectedReports
    .filter((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.MARK_AS_EXPORTED))
    .map((report) => report.reportID)
    .filter((reportID): reportID is string => reportID !== undefined);

const canExportAllReportsToIntegration = isReportsTab && includeReportLevelExport && exportableReportIDs.length > 0;
const canMarkAllReportsAsExported = isReportsTab && includeReportLevelExport && markAsExportedReportIDs.length > 0;

Then thread the eligible-subset IDs through handleExportAction (parameterizing it instead of closing over the full selectedReportIDs) and the two onSelected handlers:

App/src/hooks/useSearchBulkActions.ts

Lines 1521 to 1590 in 9813012

	const handleExportAction = (exportAction: () => void) => {
	const exportedReportNames: string[] = [];
	let areAnyReportsExported = false;
	for (const reportID of selectedReportIDs) {
	const report = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`] ?? currentSearchResults?.data?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`];
	if (!report?.pendingFields?.export && !report?.isExportedToIntegration) {
	continue;
	}
	areAnyReportsExported = true;
	// The live Onyx report can be an incomplete optimistic record (e.g. exported offline before it
	// was ever loaded) that lacks `reportName`, so fall back to the Search snapshot for the name.
	const reportName = report.reportName ?? currentSearchResults?.data?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`]?.reportName;
	if (reportName) {
	exportedReportNames.push(reportName);
	}
	}
	if (areAnyReportsExported) {
	showConfirmModal({
	title: translate('workspace.exportAgainModal.title'),
	prompt: translate('workspace.exportAgainModal.description', {
	connectionName: connectedIntegration,
	reportName: exportedReportNames.join('\n'),
	}),
	confirmText: translate('workspace.exportAgainModal.confirmText'),
	cancelText: translate('workspace.exportAgainModal.cancelText'),
	shouldEnablePromptScroll: true,
	}).then((result) => {
	if (result.action !== ModalActions.CONFIRM) {
	return;
	}
	if (hash) {
	clearSelectedTransactions();
	exportAction();
	}
	});
	} else if (hash) {
	exportAction();
	clearSelectedTransactions();
	}
	};
	if (canExportAllReportsToIntegration) {
	exportOptions.push({
	text: connectionNameFriendly,
	icon: integrationIcon,
	onSelected: () => handleExportAction(() => exportToIntegrationOnSearch(hash, selectedReportIDs, connectedIntegration, currentSearchKey)),
	shouldCloseModalOnSelect: true,
	shouldCallAfterModalHide: true,
	displayInDefaultIconColor: true,
	additionalIconStyles: styles.integrationIcon,
	});
	}
	if (canMarkAllReportsAsExported) {
	exportOptions.push({
	text: translate('workspace.common.markAsExported'),
	icon: integrationIcon,
	onSelected: () => handleExportAction(() => markAsManuallyExported(selectedReportIDs, connectedIntegration)),
	shouldCloseModalOnSelect: true,
	shouldCallAfterModalHide: true,
	displayInDefaultIconColor: true,
	additionalIconStyles: styles.integrationIcon,
	});
	}

const handleExportAction = (exportAction: () => void, reportIDsToProcess: string[]) => {
    const exportedReportNames: string[] = [];
    let areAnyReportsExported = false;

    for (const reportID of reportIDsToProcess) {

                if (canExportAllReportsToIntegration) {
                    exportOptions.push({
                        text: connectionNameFriendly,
                        icon: integrationIcon,
                        onSelected: () => handleExportAction(() => exportToIntegrationOnSearch(hash, exportableReportIDs, connectedIntegration, currentSearchKey), exportableReportIDs),

                if (canMarkAllReportsAsExported) {
                    exportOptions.push({
                        text: translate('workspace.common.markAsExported'),
                        icon: integrationIcon,
                        onSelected: () => handleExportAction(() => markAsManuallyExported(markAsExportedReportIDs, connectedIntegration), markAsExportedReportIDs),

This directly fixes the reported symptom: as long as any subset of the selected/loaded reports is eligible (which is the common case for a real 50+ report batch on a connected policy), the "Mark as exported" option now shows up and only acts on the reports that can legitimately be exported/marked, instead of the whole feature vanishing because of one ineligible report. It also keeps existing behavior intact for every other case:

• When the workspace has no connected integration, connectedIntegration is falsy and this whole block is skipped exactly as before — no regression there.
• Offline handling is unaffected since handleExportAction/handleExportAction's callers still run inside the existing isOffline guards elsewhere in the hook.
• When nothing in the selection is exportable/markable (e.g. everything is still open/unapproved), exportableReportIDs/markAsExportedReportIDs are empty arrays, so canExportAllReportsToIntegration/canMarkAllReportsAsExported are correctly false and neither menu item renders — same end result as today for a fully-ineligible selection, just no longer punished for a partially eligible one.
• This does not change how areAllMatchingItemsSelected interacts with pagination (it still only reconciles the already-loaded page into selectedReports), so it doesn't regress or attempt to silently touch reports the frontend hasn't loaded yet; it only ensures the option is shown/acted-on correctly for whatever has been loaded and is genuinely eligible, which resolves the exact repro in this issue (50+ reports, connected NetSuite policy, "select all matching items").

[samranahm]

Proposal

What is the root cause of that problem?

When a user selects multiple reports in the Search page and opens the "All matching items selected" dropdown, the option to "Mark as Exported" for accounting integrations is not available. This functionality is missing because the client-side code responsible for populating this bulk action menu does not include an entry for marking reports as exported.

While the application can display the export status of individual reports using ExportedIconCell.tsx and filter reports based on their export status via useExportedToFilterOptions.ts, there is no corresponding client-side action or backend API command to perform a bulk update of reports to mark them as exported. The existing markAllMessagesAsRead.tsx demonstrates the pattern for performing bulk actions on reports, but a similar implementation for marking reports as exported is absent.

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

1. Implement a new Report action to bulk mark reports as exported:

   • Create a new action function, for example, Report.markReportsAsExported(reportIDs: string[], integrationLabel?: string). This function will be responsible for optimistically updating the UI and then calling a new backend command.
   • Inside this function, for each reportID, construct an optimistic reportAction of a new type (e.g., CONST.REPORT.ACTIONS.TYPE.MARKED_AS_EXPORTED) or an existing type like CONST.REPORT.ACTIONS.TYPE.EXPORTED_TO_CSV if applicable. This reportAction should include message details such as label and type to indicate the integration, similar to how ExportedIconCell.tsx identifies export actions.
   • The optimisticData and failureData for Onyx would involve merging these new reportActions into the respective report's reportActions collection.
   • Finally, call a new backend API.write command (e.g., WRITE_COMMANDS.MARK_REPORTS_AS_EXPORTED) passing the reportIDs and integrationLabel (if provided) to persist the changes.
   • This approach leverages the existing pattern for bulk actions and report action updates.
   • Reference for bulk action structure and Onyx updates:
     

     App/src/libs/actions/Report/MarkAllMessageAsRead.tsx

     Lines 32 to 91 in 1d5d806

     	function markAllMessagesAsRead(reportNameValuePairs: OnyxCollection<ReportNameValuePairs>) {
     	if (isAnonymousUser()) {
     	return;
     	}
     	const newLastReadTime = getDBTimeWithSkew();
     	// Read the in-memory offline state directly since this is an imperative one-shot action (reactivity is not needed here).
     	const isOffline = getIsOffline();
     	type PartialReport = {
     	lastReadTime: Report['lastReadTime'] | null;
     	};
     	const optimisticReports: Record<string, PartialReport> = {};
     	const failureReports: Record<string, PartialReport> = {};
     	const reportIDList: string[] = [];
     	for (const report of Object.values(allReports ?? {})) {
     	if (!report) {
     	continue;
     	}
     	const chatReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${report.chatReportID}`];
     	const oneTransactionThreadReportID = getOneTransactionThreadReportID(report, chatReport, allReportActions?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${report.reportID}`], isOffline);
     	const oneTransactionThreadReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${oneTransactionThreadReportID}`];
     	const isReportArchived = isArchivedReport(reportNameValuePairs?.[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${report.reportID}`]);
     	if (!isUnread(report, oneTransactionThreadReport, isReportArchived)) {
     	continue;
     	}
     	const reportKey = `${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`;
     	optimisticReports[reportKey] = {lastReadTime: newLastReadTime};
     	failureReports[reportKey] = {lastReadTime: report.lastReadTime ?? null};
     	reportIDList.push(report.reportID);
     	}
     	if (reportIDList.length === 0) {
     	return;
     	}
     	const optimisticData = [
     	{
     	onyxMethod: Onyx.METHOD.MERGE_COLLECTION,
     	key: ONYXKEYS.COLLECTION.REPORT,
     	value: optimisticReports,
     	},
     	];
     	const failureData = [
     	{
     	onyxMethod: Onyx.METHOD.MERGE_COLLECTION,
     	key: ONYXKEYS.COLLECTION.REPORT,
     	value: failureReports,
     	},
     	];
     	const parameters: MarkAllMessagesAsReadParams = {
     	reportIDList,
     	};
     	API.write(WRITE_COMMANDS.MARK_ALL_MESSAGES_AS_READ, parameters, {optimisticData, failureData});
     	}

   • Reference for reportAction structure and integration labels:
     

     App/src/components/Search/SearchList/ListItem/ExportedIconCell.tsx

     Lines 22 to 101 in 1d5d806

     	function ExportedIconCell({reportActions}: ExportedIconCellProps) {
     	const theme = useTheme();
     	const styles = useThemeStyles();
     	const actions = reportActions ?? [];
     	const icons = useMemoizedLazyExpensifyIcons([
     	'NetSuiteSquare',
     	'XeroSquare',
     	'IntacctSquare',
     	'QBOSquare',
     	'Table',
     	'TablePencil',
     	'ZenefitsSquare',
     	'BillComSquare',
     	'CertiniaSquare',
     	'RilletSquare',
     	]);
     	let isExportedToStandardTemplate = false;
     	let isExportedToCustomTemplate = false;
     	let isExportedToNetsuite = false;
     	let isExportedToXero = false;
     	let isExportedToIntacct = false;
     	let isExportedToQuickbooksOnline = false;
     	let isExportedToQuickbooksDesktop = false;
     	let isExportedToCertinia = false;
     	let isExportedToRillet = false;
     	let isExportedToBillCom = false;
     	let isExportedToZenefits = false;
     	for (const action of actions) {
     	if (action.actionName === CONST.REPORT.ACTIONS.TYPE.EXPORTED_TO_CSV) {
     	isExportedToStandardTemplate = true;
     	}
     	if (isExportedToIntegrationAction(action)) {
     	const message = getOriginalMessage(action);
     	const label = message?.label;
     	const type = message?.type;
     	const isStandardExportTemplate = !!label && STANDARD_EXPORT_TEMPLATE_LABELS.has(label);
     	if (type === CONST.EXPORT_TEMPLATE && isStandardExportTemplate) {
     	isExportedToStandardTemplate = true;
     	}
     	if (type === CONST.EXPORT_TEMPLATE && !isStandardExportTemplate) {
     	isExportedToCustomTemplate = true;
     	}
     	isExportedToXero = isExportedToXero || label === CONST.EXPORT_LABELS.XERO;
     	isExportedToNetsuite = isExportedToNetsuite || label === CONST.EXPORT_LABELS.NETSUITE;
     	isExportedToQuickbooksOnline = isExportedToQuickbooksOnline || label === CONST.EXPORT_LABELS.QBO;
     	isExportedToQuickbooksDesktop = isExportedToQuickbooksDesktop || label === CONST.EXPORT_LABELS.QBD;
     	isExportedToZenefits = isExportedToZenefits || label === CONST.EXPORT_LABELS.ZENEFITS;
     	isExportedToBillCom = isExportedToBillCom || label === CONST.EXPORT_LABELS.BILLCOM;
     	isExportedToCertinia = isExportedToCertinia || label === CONST.EXPORT_LABELS.CERTINIA;
     	isExportedToRillet = isExportedToRillet || label === CONST.EXPORT_LABELS.RILLET;
     	isExportedToIntacct = isExportedToIntacct || label === CONST.EXPORT_LABELS.INTACCT || label === CONST.EXPORT_LABELS.SAGE_INTACCT;
     	}
     	}
     	return (
     	<View style={[styles.flexRow, styles.gap2]}>
     	{isExportedToStandardTemplate && (
     	<Icon
     	src={icons.Table}
     	fill={theme.icon}
     	size={CONST.ICON_SIZE.SMALL}
     	/>
     	)}
     	{isExportedToCustomTemplate && (
     	<Icon
     	src={icons.TablePencil}
     	fill={theme.icon}
     	size={CONST.ICON_SIZE.SMALL}
     	/>
     	)}
     	{isExportedToNetsuite && (
     	<Avatar
     	source={icons.NetSuiteSquare}
     	type={CONST.ICON_TYPE_AVATAR}

2. Add "Mark as Exported" option to the bulk selection dropdown:

   • Identify the component responsible for rendering the "All matching items selected" dropdown (e.g., SearchSelectionFooter).
   • Conditionally add a new menu item labeled "Mark as Exported". This option should be displayed only when:
     • Multiple reports are selected.
     • The current user has the necessary permissions (e.g., is a policy admin).
     • There is at least one accounting integration connected to the policy. The logic for checking connected integrations can be adapted from useExportedToFilterOptions.ts which uses getConnectedIntegrationNamesForPolicies.
       

       App/src/hooks/useExportedToFilterOptions.ts

       Lines 46 to 101 in 1d5d806

       	export default function useExportedToFilterOptions(): UseExportedToFilterDataResult {
       	const {currentSearchQueryJSON} = useSearchQueryContext();
       	const policyIDs = currentSearchQueryJSON?.policyID;
       	const {translate} = useLocalize();
       	const [integrationsExportTemplates] = useOnyx(ONYXKEYS.NVP_INTEGRATION_SERVER_EXPORT_TEMPLATES);
       	const [csvExportLayouts] = useOnyx(ONYXKEYS.NVP_CSV_EXPORT_LAYOUTS);
       	const [policies] = useOnyx(ONYXKEYS.COLLECTION.POLICY, {selector: exportedToPoliciesSelector});
       	// When search is scoped to workspaces, use only those policies otherwise use all.
       	const policiesToUse = policyIDs !== undefined ? getAllPolicyValues(policyIDs, ONYXKEYS.COLLECTION.POLICY, policies) : Object.values(policies ?? {});
       	const policyLevelExportTemplates = policiesToUse.flatMap((policy) => getExportTemplates([], {}, translate, policy, false));
       	const accountLevelExportTemplates = getExportTemplates(integrationsExportTemplates ?? [], csvExportLayouts ?? {}, translate, undefined, true);
       	const combinedExportTemplates = [...accountLevelExportTemplates, ...policyLevelExportTemplates];
       	const uniqueExportTemplatesByName = new Map<string, ExportTemplate>();
       	for (const template of combinedExportTemplates) {
       	if (!uniqueExportTemplatesByName.has(template.templateName)) {
       	uniqueExportTemplatesByName.set(template.templateName, template);
       	}
       	}
       	const combinedUniqueExportTemplates = Array.from(uniqueExportTemplatesByName.values());
       	const integrationConnectionNamesSet = new Set<string>(CONST.POLICY.CONNECTIONS.ACCOUNTING_CONNECTION_NAMES);
       	const standardAndCustomExportTemplates: string[] = [];
       	for (const template of combinedUniqueExportTemplates) {
       	// Classic export formats map to in-app templates and cannot be identified in exported-to filter.
       	if (template.type === CONST.EXPORT_TEMPLATE_TYPES.IN_APP || integrationConnectionNamesSet.has(template.templateName)) {
       	continue;
       	}
       	const standardExportTemplateDisplayName = getStandardExportTemplateDisplayName(template.templateName);
       	const filterValue = standardExportTemplateDisplayName !== template.templateName ? standardExportTemplateDisplayName : (template.name ?? template.templateName);
       	standardAndCustomExportTemplates.push(filterValue);
       	}
       	const connectedIntegrationNames = policyIDs?.length === 0 ? new Set<string>() : getConnectedIntegrationNamesForPolicies(policies, policyIDs);
       	const displayNameToConnectionName = new Map<string, string>(
       	Object.entries(CONST.POLICY.CONNECTIONS.NAME_USER_FRIENDLY).map(([connectionName, displayName]) => [displayName, connectionName]),
       	);
       	const connectedIntegrationDisplayNames = CONST.POLICY.CONNECTIONS.EXPORTED_TO_INTEGRATION_DISPLAY_NAMES.filter((displayName) => {
       	const connectionName = displayNameToConnectionName.get(displayName);
       	return connectionName && connectedIntegrationNames.has(connectionName);
       	});
       	const exportedToFilterOptions = [...new Set([...connectedIntegrationDisplayNames, ...standardAndCustomExportTemplates])];
       	return {
       	exportedToFilterOptions,
       	combinedUniqueExportTemplates,
       	connectedIntegrationNames,
       	};
       	}

   • When this menu item is selected, it should trigger the Report.markReportsAsExported action with the reportIDs of the currently selected reports. For a minimal fix, a single "Mark as Exported" option that updates for all relevant connected integrations is a good starting point, with the backend handling the specifics of which integration's status to update.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-10 14:11:42 UTC.

Proposal

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

With an accounting integration connected (NetSuite), selecting all reports on the Reports page and opening the "All matching items selected" dropdown offers no bulk "Mark as exported" action, even though Classic Expensify supports it.

What is the root cause of that problem?

The bulk "Mark as exported" option already exists in New Expensify (added in PR #83527), but three compounding client-side gates make it unreachable in this flow. The structural cause: eligibility is computed all-or-nothing over the whole selection, and the "select all" flow force-selects every loaded row, so one ineligible row hides the action for all 50+ eligible reports.

1. The dropdown's Export submenu builds the option behind canMarkAllReportsAsExported, which requires every selected report to pass canReportBeExported:
   

   App/src/hooks/useSearchBulkActions.ts

   Lines 1511 to 1515 in 1d5d806

   	const canMarkAllReportsAsExported =
   	isReportsTab &&
   	selectedReportIDs.length > 0 &&
   	includeReportLevelExport &&
   	selectedReports.every((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.MARK_AS_EXPORTED));

2. Per report, canReportBeExported → getSecondaryExportReportActions → isMarkAsExportedAction, which returns false unless the report is approved/closed/reimbursed and the user is payer/admin/exporter:
   

   App/src/libs/ReportSecondaryActionUtils.ts

   Lines 536 to 579 in 1d5d806

   	function isMarkAsExportedAction(currentAccountID: number, currentUserLogin: string, report: Report, bankAccountList: OnyxEntry<BankAccountList>, policy?: Policy): boolean {
   	if (!policy) {
   	return false;
   	}
   	const connectedIntegration = getConnectedIntegration(policy);
   	if (!connectedIntegration) {
   	return false;
   	}
   	const isInvoiceReport = isInvoiceReportUtils(report);
   	const isReportSender = isCurrentUserSubmitter(report);
   	if (isInvoiceReport && isReportSender) {
   	return true;
   	}
   	const isExpenseReport = isExpenseReportUtils(report);
   	if (!isExpenseReport) {
   	return false;
   	}
   	const isReportPayer = isPayerUtils(currentAccountID, currentUserLogin, report, bankAccountList, policy, false);
   	const arePaymentsEnabled = arePaymentsEnabledUtils(policy);
   	const isReportApproved = isReportApprovedUtils({report});
   	const isReportClosed = isClosedReportUtils(report);
   	const isReportReimbursed = isSettled(report);
   	const isReportFinished = isReportClosed || isReportApproved || isReportReimbursed;
   	if (!isReportFinished) {
   	return false;
   	}
   	if (isReportPayer && arePaymentsEnabled) {
   	return true;
   	}
   	const isAdmin = policy?.role === CONST.POLICY.ROLE.ADMIN;
   	const isExporter = isPreferredExporter(policy, currentUserLogin);
   	return isAdmin || isExporter;
   	}

3. The repro is "Reports > select all". Choosing "Select all" sets areAllMatchingItemsSelected, and the reconcile effect then force-includes every loaded row in the selection — including reports that are still open/processing on the default Reports view:
   

   App/src/components/Search/SearchWriteActionsProvider.tsx

   Lines 153 to 178 in 1d5d806

   	if (reportKey && (reportKey in selectedTransactions || areAllMatchingItemsSelected)) {
   	const [, emptyReportSelection] = mapEmptyReportToSelectedEntry(transactionGroup);
   	newTransactionList[reportKey] = {
   	...emptyReportSelection,
   	isSelected: areAllMatchingItemsSelected || selectedTransactions[reportKey]?.isSelected,
   	};
   	}
   	continue;
   	}
   	// For expense reports: when ANY transaction is selected, we want ALL transactions in the report selected.
   	// This ensures report-level selection persists when new transactions are added.
   	// Also check if the report itself was selected (when it was empty) by checking the reportID key
   	const reportKey = transactionGroup.keyForList;
   	const wasReportSelected = !!(reportKey && reportKey in selectedTransactions);
   	const hasIndividualSelectedInGroup = transactionGroup.transactions.some(
   	(transaction) => (!!transaction.keyForList && transaction.keyForList in selectedTransactions) || transaction.transactionID in selectedTransactions,
   	);
   	const propagateSelectionToAllRows = (isExpenseReportType && (wasReportSelected || hasIndividualSelectedInGroup)) || (wasReportSelected && !isExpenseReportType);
   	for (const transactionItem of transactionGroup.transactions) {
   	const listKey = transactionItem.keyForList ?? transactionItem.transactionID;
   	const isSelected = listKey in selectedTransactions || transactionItem.transactionID in selectedTransactions;
   	// Include transaction if: already individually selected, part of select-all, or group-level propagation (expense report / empty group expanded)
   	const shouldInclude = isSelected || areAllMatchingItemsSelected || propagateSelectionToAllRows;

   
   One such row makes the .every() in (1) false, so the entry never renders. Classic instead offers the action and applies it to eligible reports.
4. Upstream of (1), the whole integration block is skipped unless the selection resolves to exactly one policy — policy is only set when selectedPolicyIDs.length === 1, and connectedIntegration gates both "Export to X" and "Mark as exported":
   

   App/src/hooks/useSearchBulkActions.ts

   Lines 1478 to 1517 in 1d5d806

   	const policy = selectedPolicyIDs.length === 1 ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${selectedPolicyIDs.at(0)}`] : undefined;
   	const exportTemplates = getExportTemplates(integrationsExportTemplates ?? [], csvExportLayouts ?? {}, translate, policy, includeReportLevelExport);
   	const exportOptions: PopoverMenuItem[] = [];
   	const connectedIntegration = getConnectedIntegration(policy);
   	const isReportsTab = isExpenseReportType;
   	const includesGroupExport = Object.entries(selectedTransactions).some(
   	([key, selectedTransaction]) => key.startsWith(CONST.SEARCH.GROUP_PREFIX) && !selectedTransaction?.transaction,
   	);
   	const canReportBeExported = (report: (typeof selectedReports)[0], exportOption: ValueOf<typeof CONST.REPORT.EXPORT_OPTIONS>) => {
   	if (!report.reportID) {
   	return false;
   	}
   	const reportPolicy = policies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
   	const snapshotReport = getReportFromSearchSnapshot(report.reportID, currentSearchResults?.data, allReports);
   	if (!snapshotReport) {
   	return false;
   	}
   	const reportExportOptions = getSecondaryExportReportActions(accountID ?? CONST.DEFAULT_NUMBER_ID, currentUserLogin ?? '', snapshotReport, bankAccountList, reportPolicy);
   	return reportExportOptions.includes(exportOption);
   	};
   	const canExportAllReportsToIntegration =
   	isReportsTab &&
   	selectedReportIDs.length > 0 &&
   	includeReportLevelExport &&
   	selectedReports.every((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.EXPORT_TO_INTEGRATION));
   	const canMarkAllReportsAsExported =
   	isReportsTab &&
   	selectedReportIDs.length > 0 &&
   	includeReportLevelExport &&
   	selectedReports.every((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.MARK_AS_EXPORTED));
   	if (connectedIntegration) {

   
   Any second workspace among the matching reports also removes the option.
5. This matches the screenshot exactly: the CSV/template entries (Basic export, Current view, All Data, NS Import File) are appended unconditionally (

   App/src/hooks/useSearchBulkActions.ts

   Lines 1595 to 1634 in 1d5d806

   	exportOptions.push({
   	// Group by exports dont have a basicExport, at the same time the backend expects isBasicExport to be true for grouped exports, so we just rename the option here
   	// Fixing here https://github.com/Expensify/Expensify/issues/652978
   	text: translate(isGroupedSearch ? 'export.currentView' : 'export.basicExport'),
   	icon: expensifyIcons.Table,
   	onSelected: () => {
   	handleBasicExport();
   	},
   	shouldCloseModalOnSelect: true,
   	shouldCallAfterModalHide: true,
   	});
   	if (!isGroupedSearch) {
   	exportOptions.push({
   	text: translate('export.currentView'),
   	icon: expensifyIcons.Table,
   	onSelected: () => {
   	handleExportCurrentView();
   	},
   	shouldCloseModalOnSelect: true,
   	shouldCallAfterModalHide: true,
   	});
   	}
   	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, template.name);
   	},
   	shouldCloseModalOnSelect: true,
   	shouldCallAfterModalHide: true,
   	});
   	}
   	}

   ), while both integration entries sit behind gates (1)–(4). In the "All matching items selected" state only this Export submenu is returned at all:
   

   App/src/hooks/useSearchBulkActions.ts

   Lines 1664 to 1666 in 1d5d806

   	if (areAllMatchingItemsSelected) {
   	return [exportButtonOption];
   	}

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

In getExportOptions (useSearchBulkActions.ts), compute the eligible subset once and gate on "at least one", then act on that subset — mirroring Classic:

const markableReportIDs = selectedReports
    .filter((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.MARK_AS_EXPORTED))
    .map((report) => report.reportID);
// show the option when markableReportIDs.length > 0
// onSelected: handleExportAction(() => markAsManuallyExported(markableReportIDs, connectedIntegration))

• Do the same for canExportAllReportsToIntegration / exportToIntegrationOnSearch (

  App/src/hooks/useSearchBulkActions.ts

  Lines 1568 to 1590 in 1d5d806

  	if (canExportAllReportsToIntegration) {
  	exportOptions.push({
  	text: connectionNameFriendly,
  	icon: integrationIcon,
  	onSelected: () => handleExportAction(() => exportToIntegrationOnSearch(hash, selectedReportIDs, connectedIntegration, currentSearchKey)),
  	shouldCloseModalOnSelect: true,
  	shouldCallAfterModalHide: true,
  	displayInDefaultIconColor: true,
  	additionalIconStyles: styles.integrationIcon,
  	});
  	}
  	if (canMarkAllReportsAsExported) {
  	exportOptions.push({
  	text: translate('workspace.common.markAsExported'),
  	icon: integrationIcon,
  	onSelected: () => handleExportAction(() => markAsManuallyExported(selectedReportIDs, connectedIntegration)),
  	shouldCloseModalOnSelect: true,
  	shouldCallAfterModalHide: true,
  	displayInDefaultIconColor: true,
  	additionalIconStyles: styles.integrationIcon,
  	});
  	}

  ), and use the eligible list inside handleExportAction's already-exported re-confirm loop (L1521–L1566) so the confirm prompt only names reports we will actually touch.
• Fix gate (4) by deriving the policy from the eligible reports' policyIDs (require one connected policy among them) instead of all selected transactions' policies.
• No API change is needed: MarkAsExported already accepts an arbitrary report array (

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

  Lines 1 to 12 in 1d5d806

  	type MarkAsExportedParams = {
  	markedManually: boolean;
  	/**
  	* Stringified JSON object with type of following structure:
  	* Array<{
  	* reportID: number;
  	* label: string;
  	* optimisticReportActionID: string;
  	* }>
  	*/
  	data: string;
  	};

  ) and markAsManuallyExported already loops any ID list (

  App/src/libs/actions/Report/index.ts

  Lines 6111 to 6130 in 1d5d806

  	function markAsManuallyExported(reportIDs: string[], connectionName: ConnectionName) {
  	const label = CONST.POLICY.CONNECTIONS.NAME_USER_FRIENDLY[connectionName];
  	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.REPORT>> = [];
  	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.SNAPSHOT>> = [];
  	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.REPORT>> = [];
  	const reportData: Array<{reportID: string; label: string; optimisticReportActionID: string}> = [];
  	// Process each report ID
  	for (const reportID of reportIDs) {
  	const action = buildOptimisticExportIntegrationAction(connectionName, true);
  	const optimisticReportActionID = action.reportActionID;
  	const previousExportedValue = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`]?.isExportedToIntegration;
  	reportData.push({
  	reportID,
  	label,
  	optimisticReportActionID,
  	});

  ).

Regression safety: canReportBeExported, getSecondaryExportReportActions, and the single-report export menus (useExportActions.ts, ExportWithDropdownMenu.tsx) are untouched — only the Search bulk gating and the ID list passed to the existing actions change.

Why the obvious one-line fix fails: just flipping .every() to .some() is not enough. The handler would still send all selectedReportIDs — including open/processing reports — to markAsManuallyExported, optimistically writing "marked as exported" system messages on reports the backend will reject; and the option would still vanish for multi-workspace selections because the selectedPolicyIDs.length === 1 gate sits upstream of the entire integration block (L1478–L1517). The eligible-subset list has to be threaded into the handler and the policy resolution, not only into the visibility check.

One caveat to note in the PR: in "All matching items selected" with 50+ results, CSV/template exports send the serialized query so the backend covers unloaded pages (

App/src/hooks/useSearchBulkActions.ts

Lines 630 to 642 in 1d5d806

	if (areAllMatchingItemsSelected) {
	exportID = queueExportSearchWithTemplate(
	{
	templateName,
	templateType,
	jsonQuery: serializedQuery,
	reportIDList: [],
	transactionIDList: [],
	policyID,
	exportName,
	},
	true,
	);

); MarkAsExported has no query-based variant, so this fix (like the existing bulk integration export) applies to the loaded, eligible reports — extending the command with a query parameter can be an optional backend follow-up.

What alternative solutions did you explore? (Optional)

• .every() → .some() spot-fix: shows the option but mis-fires the action on ineligible reports and still misses multi-workspace selections (see above).
• Backend-only fix (query-based MarkAsExported): doesn't help — the App-side gating would still hide the option, so the App change is required regardless.
• Show a disabled entry with an explanation tooltip: more code, and not how Classic (or the sibling bulk actions like Approve) behave.

[melvin-bot]

Current assignee @ahmedGaber93 is eligible for the External assigner, not assigning anyone new.