[$250] Unable to bulk edit Attendees on expenses

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.17-0
Reproducible in staging?: Y
Reproducible in production?: Y
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: @DGephart
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. User signed in and went to Spend > Reports
2. Clicked on report reports in an Open state
3. Selected multiple expenses
4. Clicked the green selected button > Edit Multiple

Expected Result:

To be able to bulk edit Attendees on open expenses

Actual Result:

There is no option to edit Attendees in bulk

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

Recording.3064.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022069414493237658128
• Upwork Job ID: 2069414493237658128
• Last Price Increase: 2026-07-21

Issue Owner

Current Issue Owner: @samranahm

[MelvinBot]

Proposal

What is the root cause of that problem?

The bulk-edit ("Edit Multiple") flow has its own hardcoded list of editable fields that simply never included Attendees. The single-expense edit flow supports Attendees, but bulk edit was built as a separate feature with a fixed field set, so the asymmetry in this issue is by omission, not by a bug.

Attendees is missing from four places in the bulk-edit feature:

1. The field list rendered in the Edit Multiple menu — SearchEditMultiplePage.tsx:237-300 — only builds amount, description, merchant, date plus conditional category, tag, tax, billable, reimbursable.
2. The routes — ROUTES.ts:1001-1013 — there is no SEARCH_EDIT_MULTIPLE_ATTENDEES_RHP, and no Attendees sub-page exists in src/pages/Search/SearchEditMultiple/.
3. The save handler — SearchEditMultiplePage.tsx:131-197 — only copies the handled keys into changes.
4. The bulk action's updates whitelist — BulkEdit.ts:227-263 — has no attendees branch.

By contrast, single-expense edit shows the field via MoneyRequestView.tsx:1359-1392, gated by shouldShowAttendees (TransactionUtils/index.ts:502-508 — Control/corporate policy with attendee tracking enabled).

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

Add Attendees to the bulk-edit feature, mirroring the existing conditional fields (category/tag/tax) so it only appears when it should:

1. Add an attendees entry to the fields array in SearchEditMultiplePage.tsx, gated the same way the single flow is (shouldShowAttendees — corporate policy + attendee tracking enabled). This keeps it hidden for expenses where attendees don't apply.
2. Add a SEARCH_EDIT_MULTIPLE_ATTENDEES_RHP route and a new Attendees sub-page that reuses the existing attendees selector component used by the single-expense flow.
3. Persist the value. The single-expense path already works via the dedicated UPDATE_MONEY_REQUEST_ATTENDEES command (UpdateMoneyRequest.ts:371-424). The simplest App-only approach is to have the bulk save loop call UPDATE_MONEY_REQUEST_ATTENDEES once per selected transaction, rather than trying to fold attendees into the generic UPDATE_MONEY_REQUEST updates blob.

⚠️ Backend caveat — confirm before implementing

The bulk flow uses the generic UPDATE_MONEY_REQUEST command with a JSON updates blob (BulkEdit.ts:579-585), which has no attendees support today. Attendees are persisted only via the separate UPDATE_MONEY_REQUEST_ATTENDEES command. Folding attendees into UPDATE_MONEY_REQUEST's updates would require a backend change (outside this repo) to parse/recompute it. Routing per-transaction through the existing UPDATE_MONEY_REQUEST_ATTENDEES command avoids that and keeps the fix in App — an internal engineer should confirm that command behaves correctly when called in a loop across mixed transactions. Worth a product check too: attendees affect per-attendee amount splitting, so bulk-applying one attendee set across heterogeneous expenses should be a deliberate decision.

What alternative solutions did you explore? (Optional)

Adding attendees support to the generic UPDATE_MONEY_REQUEST command's updates contract — rejected for the frontend-only scope because it needs a backend change.

🔎 Possibly related issues

• #75617 — [Bulk Edit Expenses] Implement frontend changes — the original bulk-edit implementation (context for which fields were intentionally scoped in).
• #82738 — Date field is disabled when bulk editing per diem expenses and #82724 — IOU expenses can be changed to non-reimbursable by bulk editing — other per-field gating bugs in the same bulk-edit menu.

---

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

[MobileMage]

Proposal

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

When a user selects multiple expenses on a report (or in Search) and chooses the green selected button > "Edit Multiple", the bulk edit screen lists fields such as Amount, Description, Merchant, Date, Category, Tag, Tax, Billable and Reimbursable, but there is no row to bulk-edit Attendees. On a Control (Corporate) workspace with attendee tracking enabled, each expense exposes an Attendees field in the single-expense view, so users expect to set it across a selection in one shot. Today they have to open each expense individually.

What is the root cause of that problem?

The bulk-edit menu is a static fields array built in SearchEditMultiplePage. Each editable field is an entry in that array (or a conditionally spread entry) pointing at a dedicated RHP sub-page that writes the chosen value into the single bulk-edit draft transaction (TRANSACTION_DRAFT under OPTIMISTIC_BULK_EDIT_TRANSACTION_ID). Attendees is simply not one of the entries — there is no Attendees row, no SEARCH_EDIT_MULTIPLE_ATTENDEES_RHP route/screen, and no sub-page. This is the READ path gap.

App/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx

Lines 262 to 300 in 9b6f2bb

	...(areCategoriesEnabled
	? [
	{
	description: translate('common.category'),
	title: draftTransaction?.category ?? '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_CATEGORY_RHP,
	},
	]
	: []),
	...tagFields,
	...(isTaxTrackingEnabled
	? [
	{
	description: policy?.taxRates?.name ?? translate('common.tax'),
	title: draftTransaction?.taxCode ? (getTaxName(policy, draftTransaction) ?? '') : '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_TAX_RHP,
	disabled: hasPartiallyEditableTaxRateTransaction || hasSplitTransaction,
	},
	]
	: []),
	...(areSelectedTransactionsBillable
	? [
	{
	description: translate('common.billable'),
	title: getBooleanTitle(draftTransaction?.billable),
	route: ROUTES.SEARCH_EDIT_MULTIPLE_BILLABLE_RHP,
	},
	]
	: []),
	...(areSelectedTransactionsReimbursable
	? [
	{
	description: translate('common.reimbursable'),
	title: getBooleanTitle(draftTransaction?.reimbursable),
	route: ROUTES.SEARCH_EDIT_MULTIPLE_REIMBURSABLE_RHP,
	},
	]
	: []),
	];

On the WRITE path, save() in the same file copies recognized draft keys into a TransactionChanges object and hands it to updateMultipleMoneyRequests. That copy step only knows about amount, merchant, comment, created, category, tag, taxCode, billable and reimbursable — attendees is never read off the draft. And inside updateMultipleMoneyRequests the per-transaction loop builds an updates object that it serializes and sends via API.write(WRITE_COMMANDS.UPDATE_MONEY_REQUEST, ...). Attendees are deliberately not part of that command: single-expense attendee edits go through a separate path, updateMoneyRequestAttendees in UpdateMoneyRequest.ts, which sets transactionChanges = {attendees} and calls API.write(WRITE_COMMANDS.UPDATE_MONEY_REQUEST_ATTENDEES, ...). So even if we added an Attendees row, the existing bulk loop has no branch to emit the attendee write.

App/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx

Lines 136 to 164 in 9b6f2bb

	const changes: TransactionChanges = {};
	if (draftTransaction.amount !== undefined) {
	changes.amount = draftTransaction.amount;
	}
	if (draftTransaction.merchant) {
	changes.merchant = draftTransaction.merchant;
	}
	if (draftTransaction.comment?.comment) {
	changes.comment = draftTransaction.comment.comment;
	}
	if (draftTransaction.created) {
	changes.created = draftTransaction.created;
	}
	if (draftTransaction.category) {
	changes.category = draftTransaction.category;
	}
	if (draftTransaction.tag) {
	changes.tag = draftTransaction.tag;
	}
	if (draftTransaction.taxCode) {
	changes.taxCode = draftTransaction.taxCode;
	}
	if (typeof draftTransaction.billable === 'boolean') {
	changes.billable = draftTransaction.billable;
	}
	if (typeof draftTransaction.reimbursable === 'boolean') {
	changes.reimbursable = draftTransaction.reimbursable;
	}

A second, important constraint: attendees only apply to a specific subset of expenses. shouldShowAttendees(iouType, policy) returns true only when the policy is CONST.POLICY.TYPE.CORPORATE and isAttendeeTrackingEnabled(policy) is true, and only for submit/create/track expense types — never IOU or invoice. The bulk menu already follows exactly this "only show when applicable" pattern for category/tag/tax (e.g. areCategoriesEnabled = areSelectedTransactionsExpenses && !!policy?.areCategoriesEnabled && ...). So the Attendees row must be gated the same way, otherwise it would surface for selections where attendees don't exist.

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

Add Attendees as a conditionally-shown bulk field that mirrors the existing category/tax pattern end-to-end. First, in SearchEditMultiplePage, compute an areAttendeesEnabled flag from the resolved bulk-edit policy reusing the existing helper rather than new logic — isAttendeeTrackingEnabled(policy) && areSelectedTransactionsExpenses && policy?.type === CONST.POLICY.TYPE.CORPORATE — and spread a new field entry into fields when true, titled with translate('iou.attendees') and routing to a new ROUTES.SEARCH_EDIT_MULTIPLE_ATTENDEES_RHP. Add a new SearchEditMultipleAttendeesPage that renders MoneyRequestAttendeeSelector (the same selector the single-expense flow uses) seeded from draftTransaction?.comment?.attendees, and on finish calls updateBulkEditDraftTransaction({comment: {attendees}}), exactly how SearchEditMultipleCategoryPage persists into the draft. Register the screen/route in ROUTES.ts, SCREENS.ts, config.ts, and ModalStackNavigators/index.tsx alongside the other EDIT_MULTIPLE_* entries.

Then close the write path. In save(), read attendees off the draft into the changes object:

if (draftTransaction?.comment?.attendees) {
    changes.attendees = draftTransaction.comment.attendees;
}

And in updateMultipleMoneyRequests, add an attendees branch in the per-transaction loop guarded by the same applicability check used for category/tag (supportsExpenseFields plus a canEditField gate). Because attendees use the dedicated UpdateMoneyRequestAttendees command, the cleanest approach is to delegate per transaction to the existing updateMoneyRequestAttendees action (passing the per-transaction thread/parent report/policy already resolved in the loop) when changes.attendees is present, rather than trying to fold attendees into the UPDATE_MONEY_REQUEST updates payload. This reuses the proven single-expense optimistic data, violation-limit recompute, and recent-attendees handling instead of duplicating it. The fix is safe because the row only appears for Corporate expense transactions with attendee tracking on, and the per-transaction canEditField/supportsExpenseFields guards already prevent applying it to settled/approved expenses, IOU/invoice reports, or split children.

What alternative solutions did you explore? (Optional)

I considered threading attendees through the existing UPDATE_MONEY_REQUEST updates blob (JSON-stringified) to keep the bulk loop single-command. I rejected it because attendees have their own backend command (UpdateMoneyRequestAttendees) with distinct optimistic handling (over-limit violation recompute, NVP_RECENT_ATTENDEES union, attendee serialization); reusing updateMoneyRequestAttendees per transaction avoids re-implementing and drifting from that logic.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

This is not a regression — bulk-editing Attendees was simply never wired into the "Edit Multiple" flow, while the single-expense editor has fully supported it for a long time.

The "Edit Multiple" action navigates to SearchEditMultiplePage:

App/src/hooks/useSelectedTransactionsActions.ts

Lines 278 to 287 in be8591c

	if (canEditMultiple) {
	options.push({
	text: translate('search.bulkActions.editMultiple'),
	icon: expensifyIcons.Pencil,
	value: CONST.SEARCH.BULK_ACTION_TYPES.EDIT,
	onSelected: () => {
	initBulkEditDraftTransaction(selectedTransactionIDs);
	Navigation.navigate(ROUTES.SEARCH_EDIT_MULTIPLE_TRANSACTIONS_RHP);
	},
	});

That page renders a fixed fields list — Amount, Description, Merchant, Date, Category, Tag, Tax, Billable, Reimbursable. There is no Attendees entry:

App/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx

Lines 237 to 300 in be8591c

	const fields: Array<{description: string; title: string; route: Route; disabled?: boolean; shouldParseTitle?: boolean}> = [
	{
	description: translate('iou.amount'),
	title: draftTransaction?.amount !== undefined ? convertToDisplayStringWithoutCurrency(draftTransaction.amount, currency) : '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_AMOUNT_RHP,
	disabled: hasCustomUnitTransaction || hasPartiallyEditableTransaction || hasSplitTransaction,
	},
	{
	description: translate('common.description'),
	title: draftTransaction?.comment?.comment ?? '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_DESCRIPTION_RHP,
	shouldParseTitle: true,
	},
	{
	description: translate('common.merchant'),
	title: draftTransaction?.merchant ?? '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_MERCHANT_RHP,
	disabled: hasPartiallyEditableMerchantTransaction,
	},
	{
	description: translate('common.date'),
	title: draftTransaction?.created ?? '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_DATE_RHP,
	disabled: hasPartiallyEditableDateTransaction,
	},
	...(areCategoriesEnabled
	? [
	{
	description: translate('common.category'),
	title: draftTransaction?.category ?? '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_CATEGORY_RHP,
	},
	]
	: []),
	...tagFields,
	...(isTaxTrackingEnabled
	? [
	{
	description: policy?.taxRates?.name ?? translate('common.tax'),
	title: draftTransaction?.taxCode ? (getTaxName(policy, draftTransaction) ?? '') : '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_TAX_RHP,
	disabled: hasPartiallyEditableTaxRateTransaction || hasSplitTransaction,
	},
	]
	: []),
	...(areSelectedTransactionsBillable
	? [
	{
	description: translate('common.billable'),
	title: getBooleanTitle(draftTransaction?.billable),
	route: ROUTES.SEARCH_EDIT_MULTIPLE_BILLABLE_RHP,
	},
	]
	: []),
	...(areSelectedTransactionsReimbursable
	? [
	{
	description: translate('common.reimbursable'),
	title: getBooleanTitle(draftTransaction?.reimbursable),
	route: ROUTES.SEARCH_EDIT_MULTIPLE_REIMBURSABLE_RHP,
	},
	]
	: []),
	];

The gap is consistent across all three layers of the bulk-edit pipeline:

1. UI layer — fields (above) has no attendees row, so nothing is rendered. Contrast with the single-expense MoneyRequestView, which shows the attendees field gated by shouldShowAttendees:

   App/src/components/ReportActionItem/MoneyRequestView.tsx

   Line 471 in be8591c

   const shouldShowAttendees = shouldShowAttendeesTransactionUtils(iouType, policy);

   and

   App/src/components/ReportActionItem/MoneyRequestView.tsx

   Lines 1359 to 1393 in be8591c

   	{shouldShowAttendees && (
   	<OfflineWithFeedback pendingAction={getPendingFieldAction('attendees')}>
   	<MenuItemWithTopDescription
   	key="attendees"
   	accessibilityLabel={`${translate('iou.attendees')}, ${getAttendeesTitle}`}
   	description={`${translate('iou.attendees')} ${
   	Array.isArray(actualAttendees) && actualAttendees.length > 1 && formattedPerAttendeeAmount
   	? `${CONST.DOT_SEPARATOR} ${formattedPerAttendeeAmount} ${translate('common.perPerson')}`
   	: ''
   	}`}
   	descriptionTextStyle={styles.textLabelSupportingNormal}
   	titleComponent={
   	Array.isArray(actualAttendees) ? (
   	<UserPills
   	users={actualAttendees.map((a) => ({
   	avatar: a?.avatarUrl,
   	displayName: a?.displayName ?? a?.login ?? a?.email ?? '',
   	accountID: a?.accountID,
   	email: a?.email ?? a?.login,
   	}))}
   	maxVisible={canEdit ? undefined : actualAttendees.length}
   	/>
   	) : undefined
   	}
   	style={[styles.moneyRequestMenuItem]}
   	titleStyle={styles.flex1}
   	onPress={() => {
   	Navigation.navigate(ROUTES.MONEY_REQUEST_ATTENDEE.getRoute(CONST.IOU.ACTION.EDIT, iouType, transaction.transactionID, transactionThreadReport?.reportID));
   	}}
   	brickRoadIndicator={getErrorForField('attendees') ? CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR : undefined}
   	errorText={getErrorForField('attendees')}
   	interactive={canEdit}
   	shouldShowRightIcon={canEdit}
   	copyValue={attendeesCopyValue}
   	copyable={!!attendeesCopyValue}

2. Draft → changes layer — save() copies every supported field from the draft transaction into changes, but never reads attendees:

   App/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx

   Lines 131 to 168 in be8591c

   	const save = () => {
   	if (!draftTransaction || isSaving) {
   	return;
   	}
   	const changes: TransactionChanges = {};
   	if (draftTransaction.amount !== undefined) {
   	changes.amount = draftTransaction.amount;
   	}
   	if (draftTransaction.merchant) {
   	changes.merchant = draftTransaction.merchant;
   	}
   	if (draftTransaction.comment?.comment) {
   	changes.comment = draftTransaction.comment.comment;
   	}
   	if (draftTransaction.created) {
   	changes.created = draftTransaction.created;
   	}
   	if (draftTransaction.category) {
   	changes.category = draftTransaction.category;
   	}
   	if (draftTransaction.tag) {
   	changes.tag = draftTransaction.tag;
   	}
   	if (draftTransaction.taxCode) {
   	changes.taxCode = draftTransaction.taxCode;
   	}
   	if (typeof draftTransaction.billable === 'boolean') {
   	changes.billable = draftTransaction.billable;
   	}
   	if (typeof draftTransaction.reimbursable === 'boolean') {
   	changes.reimbursable = draftTransaction.reimbursable;
   	}
   	if (Object.keys(changes).length === 0) {
   	Navigation.dismissToPreviousRHP();
   	return;
   	}

3. Action layer — updateMultipleMoneyRequests builds transactionChanges/updates field by field and has no branch for changes.attendees:

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

   Lines 172 to 263 in be8591c

   	let transactionChanges: TransactionChanges = {};
   	if (changes.merchant && canEditField(CONST.EDIT_REQUEST_FIELD.MERCHANT)) {
   	transactionChanges.merchant = changes.merchant;
   	}
   	if (changes.created && canEditField(CONST.EDIT_REQUEST_FIELD.DATE)) {
   	transactionChanges.created = changes.created;
   	}
   	if (changes.amount !== undefined && !isSplitChild && canEditField(CONST.EDIT_REQUEST_FIELD.AMOUNT)) {
   	transactionChanges.amount = changes.amount;
   	}
   	// When bulk-editing amount on a taxed expense without also changing taxCode, recompute
   	// taxAmount from the transaction's existing taxCode so offline optimistic data and the
   	// queued payload stay in sync with the new amount. Skip when the rate can't be resolved
   	// (e.g. cross-policy bulk edit where the transaction's own policy is missing from cache)
   	// to avoid silently overwriting a non-zero taxAmount with 0.
   	if (changes.amount !== undefined && !isSplitChild && !changes.taxCode && transaction.taxCode && supportsExpenseFields && canEditField(CONST.EDIT_REQUEST_FIELD.TAX_RATE)) {
   	const taxValue = getTaxValue(transactionPolicy, transaction, transaction.taxCode);
   	if (taxValue) {
   	const decimals = getCurrencyDecimals(getCurrency(transaction));
   	const taxAmount = calculateTaxAmount(taxValue, Math.abs(changes.amount), decimals);
   	transactionChanges.taxAmount = convertToBackendAmount(taxAmount);
   	}
   	}
   	if (changes.currency && !isSplitChild && canEditField(CONST.EDIT_REQUEST_FIELD.CURRENCY)) {
   	transactionChanges.currency = changes.currency;
   	}
   	if (changes.category !== undefined && supportsExpenseFields && canEditField(CONST.EDIT_REQUEST_FIELD.CATEGORY)) {
   	transactionChanges.category = changes.category;
   	}
   	if (changes.tag && supportsExpenseFields && canEditField(CONST.EDIT_REQUEST_FIELD.TAG)) {
   	transactionChanges.tag = changes.tag;
   	}
   	if (changes.comment && canEditField(CONST.EDIT_REQUEST_FIELD.DESCRIPTION)) {
   	transactionChanges.comment = getParsedComment(changes.comment);
   	}
   	if (changes.taxCode && supportsExpenseFields && !isSplitChild && canEditField(CONST.EDIT_REQUEST_FIELD.TAX_RATE)) {
   	transactionChanges.taxCode = changes.taxCode;
   	const taxValue = getTaxValue(transactionPolicy, transaction, changes.taxCode);
   	transactionChanges.taxValue = taxValue;
   	const decimals = getCurrencyDecimals(getCurrency(transaction));
   	const effectiveAmount = transactionChanges.amount !== undefined ? Math.abs(transactionChanges.amount) : Math.abs(getAmount(transaction));
   	const taxAmount = calculateTaxAmount(taxValue, effectiveAmount, decimals);
   	transactionChanges.taxAmount = convertToBackendAmount(taxAmount);
   	}
   	if (changes.billable !== undefined && supportsExpenseFields && canEditField(CONST.EDIT_REQUEST_FIELD.BILLABLE)) {
   	transactionChanges.billable = changes.billable;
   	}
   	if (changes.reimbursable !== undefined && canEditField(CONST.EDIT_REQUEST_FIELD.REIMBURSABLE)) {
   	transactionChanges.reimbursable = changes.reimbursable;
   	}
   	transactionChanges = removeUnchangedBulkEditFields(transactionChanges, transaction, baseIouReport, transactionPolicy);
   	const updates: Record<string, string | number | boolean> = {};
   	if (transactionChanges.merchant) {
   	updates.merchant = transactionChanges.merchant;
   	}
   	if (transactionChanges.created) {
   	updates.created = transactionChanges.created;
   	}
   	if (transactionChanges.currency) {
   	updates.currency = transactionChanges.currency;
   	}
   	if (transactionChanges.category !== undefined) {
   	updates.category = transactionChanges.category;
   	}
   	if (transactionChanges.tag) {
   	updates.tag = transactionChanges.tag;
   	}
   	if (transactionChanges.comment) {
   	updates.comment = transactionChanges.comment;
   	}
   	if (transactionChanges.taxCode) {
   	updates.taxCode = transactionChanges.taxCode;
   	}
   	if (transactionChanges.taxValue) {
   	updates.taxValue = transactionChanges.taxValue;
   	}
   	if (transactionChanges.taxAmount !== undefined) {
   	updates.taxAmount = transactionChanges.taxAmount;
   	}
   	if (transactionChanges.amount !== undefined) {
   	updates.amount = transactionChanges.amount;
   	}
   	if (transactionChanges.billable !== undefined) {
   	updates.billable = transactionChanges.billable;
   	}
   	if (transactionChanges.reimbursable !== undefined) {
   	updates.reimbursable = transactionChanges.reimbursable;
   	}

Note this is a self-contained, cross-platform menu (no .native/.web fork), which is why Attendees is absent on every platform, web included.

So: bulk-edit menu omits attendees → save() never threads attendees into changes → updateMultipleMoneyRequests has no attendees branch → no UI option and no write path → "There is no option to edit Attendees in bulk".

Worth highlighting: the type layer is already prepared — TransactionChanges.attendees?: Attendee[] exists (

App/src/types/onyx/Transaction.ts

Lines 62 to 63 in be8591c

	/** Selected attendees */
	attendees?: Attendee[];

), and the single-expense action already sets transactionChanges = {attendees} and writes via WRITE_COMMANDS.UPDATE_MONEY_REQUEST_ATTENDEES:

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

Lines 370 to 424 in be8591c

	/** Updates the attendees list of an expense */
	function updateMoneyRequestAttendees({
	transactionID,
	transactionThreadReport,
	parentReport,
	attendees,
	policy,
	policyTagList,
	policyCategories,
	violations,
	currentUserAccountIDParam,
	currentUserEmailParam,
	isASAPSubmitBetaEnabled,
	parentReportNextStep,
	isOffline,
	delegateAccountID,
	}: {
	transactionID: string;
	transactionThreadReport: OnyxEntry<OnyxTypes.Report>;
	parentReport: OnyxEntry<OnyxTypes.Report>;
	attendees: Attendee[];
	policy: OnyxEntry<OnyxTypes.Policy>;
	policyTagList: OnyxEntry<OnyxTypes.PolicyTagLists>;
	policyCategories: OnyxEntry<OnyxTypes.PolicyCategories>;
	violations: OnyxEntry<OnyxTypes.TransactionViolations> | undefined;
	currentUserAccountIDParam: number;
	currentUserEmailParam: string;
	isASAPSubmitBetaEnabled: boolean;
	parentReportNextStep: OnyxEntry<OnyxTypes.ReportNextStepDeprecated>;
	isOffline: boolean;
	delegateAccountID: number | undefined;
	}) {
	const transactionChanges: TransactionChanges = {
	attendees,
	};
	const data = getUpdateMoneyRequestParams({
	transactionID,
	transactionThreadReport,
	iouReport: parentReport,
	transactionChanges,
	policy,
	policyTagList,
	// TODO: Replace getPolicyTagsData (https://github.com/Expensify/App/issues/72721) with useOnyx hook
	reportPolicyTags: getPolicyTagsData(parentReport?.policyID),
	policyCategories,
	violations,
	currentUserAccountIDParam,
	currentUserEmailParam,
	isASAPSubmitBetaEnabled,
	iouReportNextStep: parentReportNextStep,
	isOffline,
	delegateAccountID,
	});
	const {params, onyxData} = data;
	API.write(WRITE_COMMANDS.UPDATE_MONEY_REQUEST_ATTENDEES, params, onyxData);

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

Wire attendees through the same three layers, reusing the existing single-expense attendees infrastructure rather than inventing anything new.

1. Gate + render the field. Add an attendees entry to the fields array in SearchEditMultiplePage, conditioned on the resolved bulk-edit policy (already computed at

   App/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx

   Lines 111 to 113 in be8591c

   	const policyID = getSearchBulkEditPolicyID(selectedTransactionIDs, activePolicyID, mergedTransactions, mergedReports);
   	const policy = policyID ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${policyID}`] : undefined;

   ) using the existing shouldShowAttendees helper — the exact gate the single editor uses:

   App/src/libs/TransactionUtils/index.ts

   Lines 502 to 508 in be8591c

   	function shouldShowAttendees(iouType: IOUType, policy: OnyxEntry<Policy>): boolean {
   	if ((iouType !== CONST.IOU.TYPE.SUBMIT && iouType !== CONST.IOU.TYPE.CREATE && iouType !== CONST.IOU.TYPE.TRACK) || !policy?.id || policy?.type !== CONST.POLICY.TYPE.CORPORATE) {
   	return false;
   	}
   	return isAttendeeTrackingEnabledForPolicy(policy);
   	}

   The title can reuse getAttendeesListDisplayString (already used by MoneyRequestView at

   App/src/components/ReportActionItem/MoneyRequestView.tsx

   Line 963 in be8591c

   const getAttendeesTitle = Array.isArray(actualAttendees) ? getAttendeesListDisplayString(actualAttendees) : '';

   ), reading from draftTransaction?.comment?.attendees.

2. Add the RHP route/screen. Add SEARCH_EDIT_MULTIPLE_ATTENDEES_RHP to ROUTES.ts (alongside

   App/src/ROUTES.ts

   Lines 1002 to 1013 in be8591c

   	SEARCH_EDIT_MULTIPLE_AMOUNT_RHP: 'search/edit-multiple/amount',
   	SEARCH_EDIT_MULTIPLE_DESCRIPTION_RHP: 'search/edit-multiple/description',
   	SEARCH_EDIT_MULTIPLE_MERCHANT_RHP: 'search/edit-multiple/merchant',
   	SEARCH_EDIT_MULTIPLE_DATE_RHP: 'search/edit-multiple/date',
   	SEARCH_EDIT_MULTIPLE_CATEGORY_RHP: 'search/edit-multiple/category',
   	SEARCH_EDIT_MULTIPLE_TAG_RHP: {
   	route: 'search/edit-multiple/tag/:tagListIndex',
   	getRoute: (tagListIndex = 0) => `search/edit-multiple/tag/${tagListIndex}` as const,
   	},
   	SEARCH_EDIT_MULTIPLE_BILLABLE_RHP: 'search/edit-multiple/billable',
   	SEARCH_EDIT_MULTIPLE_REIMBURSABLE_RHP: 'search/edit-multiple/reimbursable',
   	SEARCH_EDIT_MULTIPLE_TAX_RHP: 'search/edit-multiple/tax',

   ), the matching SCREENS.SEARCH.EDIT_MULTIPLE_ATTENDEES_RHP (alongside

   App/src/SCREENS.ts

   Lines 100 to 109 in be8591c

   	EDIT_MULTIPLE_TRANSACTIONS_RHP: 'Search_Edit_Multiple_Transactions_RHP',
   	EDIT_MULTIPLE_AMOUNT_RHP: 'Search_Edit_Multiple_Amount_RHP',
   	EDIT_MULTIPLE_DESCRIPTION_RHP: 'Search_Edit_Multiple_Description_RHP',
   	EDIT_MULTIPLE_MERCHANT_RHP: 'Search_Edit_Multiple_Merchant_RHP',
   	EDIT_MULTIPLE_DATE_RHP: 'Search_Edit_Multiple_Date_RHP',
   	EDIT_MULTIPLE_CATEGORY_RHP: 'Search_Edit_Multiple_Category_RHP',
   	EDIT_MULTIPLE_TAG_RHP: 'Search_Edit_Multiple_Tag_RHP',
   	EDIT_MULTIPLE_BILLABLE_RHP: 'Search_Edit_Multiple_Billable_RHP',
   	EDIT_MULTIPLE_REIMBURSABLE_RHP: 'Search_Edit_Multiple_Reimbursable_RHP',
   	EDIT_MULTIPLE_TAX_RHP: 'Search_Edit_Multiple_Tax_RHP',

   ), the linkingConfig mapping, and a thin SearchEditMultipleAttendeesPage modeled on SearchEditMultipleCategoryPage. The selection UI itself can reuse the existing attendees step page (IOURequestStepAttendees) writing the chosen list back to the bulk-edit draft via the existing updateBulkEditDraftTransaction (

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

   Lines 640 to 642 in be8591c

   	function updateBulkEditDraftTransaction(transactionChanges: NullishDeep<OnyxTypes.Transaction>) {
   	Onyx.merge(`${ONYXKEYS.COLLECTION.TRANSACTION_DRAFT}${CONST.IOU.OPTIMISTIC_BULK_EDIT_TRANSACTION_ID}`, transactionChanges);
   	}

   ).

3. Thread attendees into changes. In save() add the missing copy, mirroring the existing field copies:

   if (draftTransaction.comment?.attendees) {
       changes.attendees = draftTransaction.comment.attendees;
   }

   (insert alongside

   App/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx

   Lines 143 to 145 in be8591c

   	if (draftTransaction.comment?.comment) {
   	changes.comment = draftTransaction.comment.comment;
   	}

   )

4. Apply attendees per transaction. In updateMultipleMoneyRequests, add an attendees branch in the change/updates builders (alongside

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

   Lines 205 to 207 in be8591c

   	if (changes.comment && canEditField(CONST.EDIT_REQUEST_FIELD.DESCRIPTION)) {
   	transactionChanges.comment = getParsedComment(changes.comment);
   	}

   ). Attendees flow through comment.attendees and getUpdatedTransaction already handles attendee updates for the optimistic transaction, exactly as the single-expense updateMoneyRequestAttendees does at

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

   Lines 402 to 424 in be8591c

   	const transactionChanges: TransactionChanges = {
   	attendees,
   	};
   	const data = getUpdateMoneyRequestParams({
   	transactionID,
   	transactionThreadReport,
   	iouReport: parentReport,
   	transactionChanges,
   	policy,
   	policyTagList,
   	// TODO: Replace getPolicyTagsData (https://github.com/Expensify/App/issues/72721) with useOnyx hook
   	reportPolicyTags: getPolicyTagsData(parentReport?.policyID),
   	policyCategories,
   	violations,
   	currentUserAccountIDParam,
   	currentUserEmailParam,
   	isASAPSubmitBetaEnabled,
   	iouReportNextStep: parentReportNextStep,
   	isOffline,
   	delegateAccountID,
   	});
   	const {params, onyxData} = data;
   	API.write(WRITE_COMMANDS.UPDATE_MONEY_REQUEST_ATTENDEES, params, onyxData);

   — so the optimistic/pending-field/snapshot machinery already present in BulkEdit.ts requires no structural change, only the new field entry.

Because attendees is a corporate-policy/attendee-tracking-only field, the menu entry should only appear when shouldShowAttendees returns true for the resolved policy, matching single-expense behavior and avoiding showing it for IOU/non-corporate selections.

Exact eligibility nuances for mixed selections (e.g. all transactions must share an attendee-tracking-enabled policy) and minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Folding attendees into the generic UPDATE_MONEY_REQUEST updates JSON that BulkEdit.ts already sends (

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

Lines 579 to 583 in be8591c

	const params = {
	transactionID,
	reportActionID: modifiedExpenseReportActionID,
	updates: JSON.stringify(updates),
	};

). This is rejected because the single-expense flow deliberately uses a dedicated UPDATE_MONEY_REQUEST_ATTENDEES command (

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

Line 424 in be8591c

API.write(WRITE_COMMANDS.UPDATE_MONEY_REQUEST_ATTENDEES, params, onyxData);

); reusing the established command and the getUpdatedTransaction attendee path keeps optimistic data, per-attendee amount recalculation, and backend behavior identical to the proven single-edit path, rather than relying on UpdateMoneyRequest to interpret an attendees payload it isn't built for.

[lorretheboy]

Proposal

What is the root cause of that problem?

The bulk-edit screen builds its menu from a hard-coded fields array, and that array simply has no Attendees entry — Amount, Description, Merchant, Date, Category, Tag, Tax, Billable and Reimbursable are the only fields ever pushed:

App/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx

Lines 237 to 300 in 9b6f2bb

	const fields: Array<{description: string; title: string; route: Route; disabled?: boolean; shouldParseTitle?: boolean}> = [
	{
	description: translate('iou.amount'),
	title: draftTransaction?.amount !== undefined ? convertToDisplayStringWithoutCurrency(draftTransaction.amount, currency) : '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_AMOUNT_RHP,
	disabled: hasCustomUnitTransaction || hasPartiallyEditableTransaction || hasSplitTransaction,
	},
	{
	description: translate('common.description'),
	title: draftTransaction?.comment?.comment ?? '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_DESCRIPTION_RHP,
	shouldParseTitle: true,
	},
	{
	description: translate('common.merchant'),
	title: draftTransaction?.merchant ?? '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_MERCHANT_RHP,
	disabled: hasPartiallyEditableMerchantTransaction,
	},
	{
	description: translate('common.date'),
	title: draftTransaction?.created ?? '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_DATE_RHP,
	disabled: hasPartiallyEditableDateTransaction,
	},
	...(areCategoriesEnabled
	? [
	{
	description: translate('common.category'),
	title: draftTransaction?.category ?? '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_CATEGORY_RHP,
	},
	]
	: []),
	...tagFields,
	...(isTaxTrackingEnabled
	? [
	{
	description: policy?.taxRates?.name ?? translate('common.tax'),
	title: draftTransaction?.taxCode ? (getTaxName(policy, draftTransaction) ?? '') : '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_TAX_RHP,
	disabled: hasPartiallyEditableTaxRateTransaction || hasSplitTransaction,
	},
	]
	: []),
	...(areSelectedTransactionsBillable
	? [
	{
	description: translate('common.billable'),
	title: getBooleanTitle(draftTransaction?.billable),
	route: ROUTES.SEARCH_EDIT_MULTIPLE_BILLABLE_RHP,
	},
	]
	: []),
	...(areSelectedTransactionsReimbursable
	? [
	{
	description: translate('common.reimbursable'),
	title: getBooleanTitle(draftTransaction?.reimbursable),
	route: ROUTES.SEARCH_EDIT_MULTIPLE_REIMBURSABLE_RHP,
	},
	]
	: []),
	];

There is also no route, edit page, or save mapping for attendees: the route list stops at the fields above (no SEARCH_EDIT_MULTIPLE_ATTENDEES_RHP)

App/src/ROUTES.ts

Lines 1001 to 1013 in 9b6f2bb

	SEARCH_EDIT_MULTIPLE_TRANSACTIONS_RHP: 'search/edit-multiple-transactions',
	SEARCH_EDIT_MULTIPLE_AMOUNT_RHP: 'search/edit-multiple/amount',
	SEARCH_EDIT_MULTIPLE_DESCRIPTION_RHP: 'search/edit-multiple/description',
	SEARCH_EDIT_MULTIPLE_MERCHANT_RHP: 'search/edit-multiple/merchant',
	SEARCH_EDIT_MULTIPLE_DATE_RHP: 'search/edit-multiple/date',
	SEARCH_EDIT_MULTIPLE_CATEGORY_RHP: 'search/edit-multiple/category',
	SEARCH_EDIT_MULTIPLE_TAG_RHP: {
	route: 'search/edit-multiple/tag/:tagListIndex',
	getRoute: (tagListIndex = 0) => `search/edit-multiple/tag/${tagListIndex}` as const,
	},
	SEARCH_EDIT_MULTIPLE_BILLABLE_RHP: 'search/edit-multiple/billable',
	SEARCH_EDIT_MULTIPLE_REIMBURSABLE_RHP: 'search/edit-multiple/reimbursable',
	SEARCH_EDIT_MULTIPLE_TAX_RHP: 'search/edit-multiple/tax',

and save never copies draftTransaction.comment?.attendees into the changes object it submits:

App/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx

Lines 136 to 163 in 9b6f2bb

	const changes: TransactionChanges = {};
	if (draftTransaction.amount !== undefined) {
	changes.amount = draftTransaction.amount;
	}
	if (draftTransaction.merchant) {
	changes.merchant = draftTransaction.merchant;
	}
	if (draftTransaction.comment?.comment) {
	changes.comment = draftTransaction.comment.comment;
	}
	if (draftTransaction.created) {
	changes.created = draftTransaction.created;
	}
	if (draftTransaction.category) {
	changes.category = draftTransaction.category;
	}
	if (draftTransaction.tag) {
	changes.tag = draftTransaction.tag;
	}
	if (draftTransaction.taxCode) {
	changes.taxCode = draftTransaction.taxCode;
	}
	if (typeof draftTransaction.billable === 'boolean') {
	changes.billable = draftTransaction.billable;
	}
	if (typeof draftTransaction.reimbursable === 'boolean') {
	changes.reimbursable = draftTransaction.reimbursable;
	}

So Attendees is missing by omission, not by any conditional gate. Single-expense editing supports it via shouldShowAttendees, but that path was never wired into the bulk-edit flow:

App/src/components/ReportActionItem/MoneyRequestView.tsx

Line 471 in 9b6f2bb

const shouldShowAttendees = shouldShowAttendeesTransactionUtils(iouType, policy);

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

Add Attendees as a bulk-editable field, mirroring how single edit handles it:

1. Add a new SEARCH_EDIT_MULTIPLE_ATTENDEES_RHP route and a corresponding edit page/screen (registered in the modal stack navigator alongside the other SearchEditMultiple* pages), reusing the existing attendees selector component.
2. In the fields array of SearchEditMultiplePage, conditionally push an Attendees menu item gated by shouldShowAttendees(iouType, policy) (the same check MoneyRequestView uses), and disable it for transaction types where it doesn't apply (e.g. distance/per-diem), consistent with the other partial-editability gates already in this file.
3. In save, map the draft attendees into the submitted changes (e.g. set changes.attendees from draftTransaction.comment?.attendees) so updateMultipleMoneyRequests persists them.

This fixes the shared convergence point (the bulk-edit page + its route/save), so the option appears wherever "Edit Multiple" is offered (report view and Search) without per-call-site changes.

What alternative solutions did you explore? (Optional)

None — the omission is in one place (the bulk-edit fields/route/save), so the fix belongs there.

[Abdukhamid000]

Proposal

What is the root cause of that problem?

Bulk edit was built with a hard-coded field list that never included Attendees, and the bulk-edit action pipeline doesn't map an attendees change — even though the underlying data model and single-expense editor already support it.

The field menu in [SearchEditMultiplePage](https://github.com/Expensify/App/blob/main/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx#L228-L291) is a fixed array of amount / description / merchant / date / category / tag / tax / billable / reimbursable. There's no Attendees entry, so the row never renders.

Even if a row existed, the write path would drop it. [updateMultipleMoneyRequests](https://github.com/Expensify/App/blob/main/src/libs/actions/IOU/BulkEdit.ts#L88-L268) explicitly enumerates which changes.* keys it forwards into transactionChanges / updates, and attendees isn't one of them — so it would be silently ignored.

This is purely a missing wiring, not a model limitation:

• TransactionChanges already has attendees?: Attendee[] (src/types/onyx/Transaction.ts).
• CONST.SEARCH.TABLE_COLUMNS.ATTENDEES and attendee editing exist for a single expense via [MONEY_REQUEST_ATTENDEE](https://github.com/Expensify/App/blob/main/src/ROUTES.ts#L1551-L1558) → MoneyRequestAttendeeSelector, and the single-edit API path already serializes attendees ([UpdateMoneyRequest.ts:1385-1386](https://github.com/Expensify/App/blob/main/src/libs/actions/IOU/UpdateMoneyRequest.ts#L1385-L1386)).
• shouldShowAttendees(iouType, policy) / isAttendeeTrackingEnabledForPolicy already encode when attendees apply (Control policy, attendee tracking on).

So every piece needed exists; the bulk-edit surface and the bulk-edit reducer were just never extended to cover it.

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

Mirror the existing per-field bulk-edit pattern (the category/tag flow is the closest template).

1. Add the route + screen registration alongside the other bulk-edit RHPs:

// src/ROUTES.ts
 SEARCH_EDIT_MULTIPLE_BILLABLE_RHP: 'search/edit-multiple/billable',
 SEARCH_EDIT_MULTIPLE_REIMBURSABLE_RHP: 'search/edit-multiple/reimbursable',
 SEARCH_EDIT_MULTIPLE_TAX_RHP: 'search/edit-multiple/tax',
+SEARCH_EDIT_MULTIPLE_ATTENDEES_RHP: 'search/edit-multiple/attendees',

2. Add a bulk-edit attendees page that reuses MoneyRequestAttendeeSelector and writes to the bulk draft, mirroring [SearchEditMultipleCategoryPage](https://github.com/Expensify/App/blob/main/src/pages/Search/SearchEditMultiple/SearchEditMultipleCategoryPage.tsx):

function SearchEditMultipleAttendeesPage() {
    const [draftTransaction] = useOnyx(`${ONYXKEYS.COLLECTION.TRANSACTION_DRAFT}${CONST.IOU.OPTIMISTIC_BULK_EDIT_TRANSACTION_ID}`);
    const attendees = draftTransaction?.comment?.attendees ?? [];

    const saveAttendees = (nextAttendees: Attendee[]) => {
        updateBulkEditDraftTransaction({comment: {attendees: nextAttendees}});
        Navigation.goBack();
    };
    // render MoneyRequestAttendeeSelector with attendees + onAttendeesAdded={saveAttendees}
}

3. Add the Attendees field row to SearchEditMultiplePage.fields, gated the same way single-expense attendees are (Control policy + attendee tracking + expense-compatible, non-distance/per-diem/time selection):

+    const areAttendeesEnabled =
+        areSelectedTransactionsExpenses &&
+        !hasCustomUnitTransaction &&
+        !hasPerDiemOrTimeTransaction &&
+        shouldShowAttendees(CONST.IOU.TYPE.SUBMIT, policy);
 ...
+        ...(areAttendeesEnabled
+            ? [
+                  {
+                      description: translate('iou.attendees'),
+                      title: getAttendeesListDisplayString(draftTransaction?.comment?.attendees ?? [], localeCompare),
+                      route: ROUTES.SEARCH_EDIT_MULTIPLE_ATTENDEES_RHP,
+                      disabled: isFieldDisabledForAnyTransaction(CONST.EDIT_REQUEST_FIELD.MERCHANT),
+                  },
+              ]
+            : []),

(Attendees editability follows the same report-state rules as other editable fields; reusing the existing isFieldDisabledForAnyTransaction gate keeps it consistent. If a dedicated EDIT_REQUEST_FIELD.ATTENDEES is wanted, add it to CONST.EDIT_REQUEST_FIELD and canEditFieldOfMoneyRequest.)

4. Thread attendees through save() in SearchEditMultiplePage:

         if (typeof draftTransaction.reimbursable === 'boolean') {
             changes.reimbursable = draftTransaction.reimbursable;
         }
+        if (draftTransaction.comment?.attendees) {
+            changes.attendees = draftTransaction.comment.attendees;
+        }

5. Map it in updateMultipleMoneyRequests so the change actually reaches each transaction:

         if (changes.reimbursable !== undefined && canEditField(CONST.EDIT_REQUEST_FIELD.REIMBURSABLE)) {
             transactionChanges.reimbursable = changes.reimbursable;
         }
+        if (changes.attendees && supportsExpenseFields && canEditField(CONST.EDIT_REQUEST_FIELD.MERCHANT)) {
+            transactionChanges.attendees = changes.attendees;
+        }
 ...
+        if (transactionChanges.attendees) {
+            updates.attendees = JSON.stringify(
+                transactionChanges.attendees.map(({avatarUrl, displayName, email}) => ({avatarUrl, displayName, ...(email ? {email} : {})})),
+            );
+        }

The serialization mirrors exactly what the single-expense path does at [UpdateMoneyRequest.ts:1377-1386](https://github.com/Expensify/App/blob/main/src/libs/actions/IOU/UpdateMoneyRequest.ts#L1377-L1386), so the backend receives the same shape it already accepts.

That's the whole feature: a route, a page that reuses the existing attendee selector, one gated field row, and two small additions to the change reducer.

What alternative solutions did you explore?

• Build a bulk-specific attendee selector instead of reusing MoneyRequestAttendeeSelector. Unnecessary — the existing selector already produces the Attendee[] shape the draft and API expect. Reusing it keeps the UX identical to single-expense editing.
• Skip per-transaction editability gating and apply attendees to all selected. Rejected — attendees only make sense on Control-policy expense transactions with attendee tracking enabled, and not on distance/per-diem/time. Gating with shouldShowAttendees + the existing expense-compatibility checks prevents applying it where it's invalid (and where the backend would reject it).
• Add a dedicated EDIT_REQUEST_FIELD.ATTENDEES for precise editability. Worth doing if reviewers want attendees gated independently of merchant; I kept it on the existing gate to minimize surface area, and called out the cleaner option.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

New Feature — and a write-path correctness point the existing proposals split on.

The bulk-edit (Edit Multiple) menu renders from a hardcoded allow-list, the fields array in SearchEditMultiplePage, which never included an Attendees row:

App/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx

Lines 237 to 300 in be8591c

	const fields: Array<{description: string; title: string; route: Route; disabled?: boolean; shouldParseTitle?: boolean}> = [
	{
	description: translate('iou.amount'),
	title: draftTransaction?.amount !== undefined ? convertToDisplayStringWithoutCurrency(draftTransaction.amount, currency) : '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_AMOUNT_RHP,
	disabled: hasCustomUnitTransaction || hasPartiallyEditableTransaction || hasSplitTransaction,
	},
	{
	description: translate('common.description'),
	title: draftTransaction?.comment?.comment ?? '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_DESCRIPTION_RHP,
	shouldParseTitle: true,
	},
	{
	description: translate('common.merchant'),
	title: draftTransaction?.merchant ?? '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_MERCHANT_RHP,
	disabled: hasPartiallyEditableMerchantTransaction,
	},
	{
	description: translate('common.date'),
	title: draftTransaction?.created ?? '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_DATE_RHP,
	disabled: hasPartiallyEditableDateTransaction,
	},
	...(areCategoriesEnabled
	? [
	{
	description: translate('common.category'),
	title: draftTransaction?.category ?? '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_CATEGORY_RHP,
	},
	]
	: []),
	...tagFields,
	...(isTaxTrackingEnabled
	? [
	{
	description: policy?.taxRates?.name ?? translate('common.tax'),
	title: draftTransaction?.taxCode ? (getTaxName(policy, draftTransaction) ?? '') : '',
	route: ROUTES.SEARCH_EDIT_MULTIPLE_TAX_RHP,
	disabled: hasPartiallyEditableTaxRateTransaction || hasSplitTransaction,
	},
	]
	: []),
	...(areSelectedTransactionsBillable
	? [
	{
	description: translate('common.billable'),
	title: getBooleanTitle(draftTransaction?.billable),
	route: ROUTES.SEARCH_EDIT_MULTIPLE_BILLABLE_RHP,
	},
	]
	: []),
	...(areSelectedTransactionsReimbursable
	? [
	{
	description: translate('common.reimbursable'),
	title: getBooleanTitle(draftTransaction?.reimbursable),
	route: ROUTES.SEARCH_EDIT_MULTIPLE_REIMBURSABLE_RHP,
	},
	]
	: []),
	];

That UI gap is well established. The part the proposals disagree on — and where several are incorrect — is the write path. The bulk loop sends edits through the generic UPDATE_MONEY_REQUEST command with a JSON updates blob:

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

Lines 579 to 585 in be8591c

	const params = {
	transactionID,
	reportActionID: modifiedExpenseReportActionID,
	updates: JSON.stringify(updates),
	};
	API.write(WRITE_COMMANDS.UPDATE_MONEY_REQUEST, params, {

Attendees are not a field of UPDATE_MONEY_REQUEST. Single-expense attendee edits go exclusively through the dedicated UPDATE_MONEY_REQUEST_ATTENDEES command:

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

Lines 402 to 424 in be8591c

	const transactionChanges: TransactionChanges = {
	attendees,
	};
	const data = getUpdateMoneyRequestParams({
	transactionID,
	transactionThreadReport,
	iouReport: parentReport,
	transactionChanges,
	policy,
	policyTagList,
	// TODO: Replace getPolicyTagsData (https://github.com/Expensify/App/issues/72721) with useOnyx hook
	reportPolicyTags: getPolicyTagsData(parentReport?.policyID),
	policyCategories,
	violations,
	currentUserAccountIDParam,
	currentUserEmailParam,
	isASAPSubmitBetaEnabled,
	iouReportNextStep: parentReportNextStep,
	isOffline,
	delegateAccountID,
	});
	const {params, onyxData} = data;
	API.write(WRITE_COMMANDS.UPDATE_MONEY_REQUEST_ATTENDEES, params, onyxData);

So any approach that simply JSON.stringifys attendees into the bulk updates blob (the generic-command camp) would render the row but silently no-op on the backend — the server never persists it. Folding attendees into UPDATE_MONEY_REQUEST would require a backend change.

There are also two pieces of attendee-specific logic that live only inside the dedicated path and are bypassed by the bulk loop: the over-limit-attendee violation recompute (a per-attendee limit, multiplied by attendee count) and the recent-attendees union:

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

Lines 1640 to 1662 in be8591c

	if ('attendees' in transactionChanges) {
	// Update violation limit, if we modify attendees. The given limit value is for a single attendee, if we have multiple attendees we should multiply limit by attendee count
	const overLimitViolation = violations?.find((violation) => violation.name === 'overLimit');
	if (overLimitViolation) {
	const limitForSingleAttendee = overLimitViolation.data?.amount ?? 0;
	if (limitForSingleAttendee * (transactionChanges?.attendees?.length ?? 1) > Math.abs(getAmount(transaction))) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transactionID}`,
	value: violations?.filter((violation) => violation.name !== 'overLimit') ?? [],
	});
	}
	}
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.NVP_RECENT_ATTENDEES,
	value: lodashUnionBy(
	transactionChanges.attendees?.map(({avatarUrl, displayName, email}) => ({avatarUrl, displayName, ...(email ? {email} : {})})) ?? [],
	getRecentAttendees(),
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	(attendee) => attendee.email || attendee.displayName,
	).slice(0, CONST.IOU.MAX_RECENT_ATTENDEES),
	});

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

Add the UI entry like the other bulk fields, but route the write through the existing dedicated attendees action so the backend command, violation recompute, and recent-attendees handling all match single-expense behavior exactly.

1. UI row + RHP page. Add a new SearchEditMultipleAttendeesPage (mirroring SearchEditMultipleCategoryPage) that reuses MoneyRequestAttendeeSelector and writes the picked list to the bulk draft:

const onAttendeesSelected = (attendees: Attendee[]) => {
  updateBulkEditDraftTransaction({ comment: { attendees } });
  Navigation.goBack();
};

Register SEARCH_EDIT_MULTIPLE_ATTENDEES_RHP in SCREENS, ROUTES, linking config, and ModalStackNavigators/index.tsx. Add a gated entry to the fields array, reusing the single-expense gate shouldShowAttendees(CONST.IOU.TYPE.SUBMIT, policy) (

App/src/libs/TransactionUtils/index.ts

Lines 502 to 508 in be8591c

	function shouldShowAttendees(iouType: IOUType, policy: OnyxEntry<Policy>): boolean {
	if ((iouType !== CONST.IOU.TYPE.SUBMIT && iouType !== CONST.IOU.TYPE.CREATE && iouType !== CONST.IOU.TYPE.TRACK) || !policy?.id || policy?.type !== CONST.POLICY.TYPE.CORPORATE) {
	return false;
	}
	return isAttendeeTrackingEnabledForPolicy(policy);
	}

) and the already-computed areSelectedTransactionsExpenses.

2. Thread the draft in save():

if (draftTransaction.comment?.attendees) {
  changes.attendees = draftTransaction.comment.attendees;
}

3. Apply per transaction — delegate, don't fold. In updateMultipleMoneyRequests, when changes.attendees is present and the transaction is attendee-eligible, call the existing updateMoneyRequestAttendees for that transaction (passing the per-transaction transactionThread, iouReport, and resolved transactionPolicy the loop already computes) instead of adding an updates.attendees branch. This reuses the correct UPDATE_MONEY_REQUEST_ATTENDEES command plus its over-limit recompute, recent-attendees union, and optimistic MODIFIED_EXPENSE handling — none of which the generic updates path provides.

Eligibility for mixed selections: the bulk loop already resolves each transaction's own policy (transactionPolicy), so the per-transaction guard should re-check shouldShowAttendees against that policy — not just the single resolved bulk-edit policy from getSearchBulkEditPolicyID. A selection can span policies where some have attendee tracking and some don't; per-transaction gating prevents writing attendees to transactions whose own policy doesn't support them.

What alternative solutions did you explore? (Optional)

• Fold attendees into the generic UPDATE_MONEY_REQUEST updates JSON (the approach in several other proposals here). Rejected — UPDATE_MONEY_REQUEST has no attendees field; the row would appear but the edit would never persist without a backend change, and it would skip the over-limit violation recompute and recent-attendees union that only the dedicated command path performs.

• Reuse the single-expense MONEY_REQUEST_ATTENDEE route directly instead of a dedicated bulk page. Rejected — that route requires a concrete transaction + report context, whereas bulk edit operates on one placeholder draft transaction for the whole selection, so a thin bulk page writing to updateBulkEditDraftTransaction is the consistent pattern (matching the category/tag bulk pages).

[dostonbunyodov0006]

Proposal

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

From Spend > Reports > open report > select multiple expenses > green button > Edit Multiple, you can bulk-edit fields like category, tag, description and date, but Attendees is missing — there is no row to edit attendees across the selected expenses, even though attendees is fully editable on a single expense (staging + production, all platforms, v9.4.17-0).

What is the root cause of that problem?

Bulk edit exists as a separate screen with its own field list, parallel to the single-expense edit view. Because the two are different code paths, the bulk screen only shows the fields someone explicitly re-implemented there — and Attendees was never added. The real defect isn't "one missing row"; it's that bulk edit duplicates the single-expense edit surface instead of reusing it, so the two drift and fields silently go missing.

Single-expense editing already renders a complete, correct field menu (each row knows its own visibility gate — e.g. shouldShowAttendees(...) for attendees — its editor, and its write). The bulk screen ignores all of that and re-curates a shorter list by hand.

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

Don't keep a separate bulk field list. Make bulk edit a mode of the single-expense edit view: render the exact same field menu against a synthetic "selection" transaction (the common/merged view of the selected expenses), and have each field's save fan out to every selected transaction. There is then only one edit surface — Attendees, and every field, appears because single-expense edit already shows it.

-// Separate bulk screen with its own curated field array
-function BulkEditExpensesPage({selectedTransactions}) {
-    return <FieldList fields={BULK_EDITABLE_FIELDS} .../>;   // attendees not in this array
-}
+// Bulk edit = the single-expense edit view, in multi-selection mode
+function MoneyRequestView({transaction, isBulkEdit = false, selectedTransactions}) {
+    // Same rows, same visibility gates (incl. shouldShowAttendees), same editors.
+    // In bulk mode each row renders against the merged selection and saves to all.
+    const onSaveField = (field, value) =>
+        isBulkEdit
+            ? selectedTransactions.forEach((t) => updateField(field, value, t))   // fan-out
+            : updateField(field, value, transaction);
+    ...
+}

The "selection transaction" is just a merged read model: a field shows its shared value when all selected expenses agree, and a "Various" placeholder when they differ — the row's existing gate still decides whether it appears at all. Tapping a row opens the same editor the single expense uses (including the attendees picker), and saving routes the chosen value through the existing per-expense write for each selected transaction. No bulk-specific attendees editor, no bulk-specific field list — the gap that hid Attendees becomes structurally impossible.

What alternative solutions did you explore?

• Add attendees to the existing bulk field array. One-line-style fix, but it preserves the duplicated bulk surface: the lists keep drifting and the next new field is missed again. Treats the symptom, not the duplication.
• Derive the bulk field list from the single-expense field registry (keep two screens). Better than hardcoding, but still maintains a second screen and a bulk-safe filter that can diverge from how single edit gates each field; the merged-value/"Various" UX has to be re-solved separately.
• Build a dedicated bulk-attendees picker + write path. Full control but duplicates the attendees picker and its validation, doubling maintenance for a field that already has a working editor in the single-expense flow.

[aswin-s]

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

When a user selects multiple open expenses and taps "Edit Multiple", the bulk-edit menu (SearchEditMultiplePage) does not include an Attendees field. Every other editable field (Amount, Description, Merchant, Date, Category, Tags, Tax, Billable, Reimbursable) appears in the list, but Attendees is entirely absent, so there is no way to bulk-edit attendees on open expenses.

What is the root cause of that problem?

The fields array in src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx (lines 237–300) is manually constructed and simply never includes an Attendees entry. There is no conditional guard suppressing it — the field was never added. No corresponding route (SEARCH_EDIT_MULTIPLE_ATTENDEES_RHP or equivalent) exists in src/ROUTES.ts, and no attendees edit page exists under src/pages/Search/SearchEditMultiple/. The single-expense attendees edit path (via MoneyRequestConfirmationList/AttendeeField) was never wired into the bulk-edit flow.

Additionally, the save function in SearchEditMultiplePage.tsx (lines 131–196) does not extract draftTransaction.comment?.attendees into the changes object passed to updateMultipleMoneyRequests. Even if it did, the per-transaction loop in updateMultipleMoneyRequests inside src/libs/actions/IOU/BulkEdit.ts (lines 183–265) contains no branch for changes.attendees — neither the transactionChanges assignment block nor the updates object that is JSON-serialised into the API payload. Without both branches, the attendees selection would be visible in the UI but never written to Onyx or sent to the server.

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

1. src/ROUTES.ts — Add a new route constant (e.g. SEARCH_EDIT_MULTIPLE_ATTENDEES_RHP) for the bulk-edit attendees RHP screen, following the same pattern as SEARCH_EDIT_MULTIPLE_CATEGORY_RHP.

2. src/pages/Search/SearchEditMultiple/SearchEditMultipleAttendeesPage.tsx — Create a new page component that lets the user pick attendees for the selection and writes the result into the bulk-edit draft transaction (TRANSACTION_DRAFT attendees field), mirroring the pattern of the existing SearchEditMultipleDatePage / SearchEditMultipleAmountPage.

3. src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx (lines 131–196, save function) — Add a branch that extracts draftTransaction.comment?.attendees into the changes object so the attendees selection is passed to updateMultipleMoneyRequests:

if (draftTransaction.comment?.attendees) {
    changes.attendees = draftTransaction.comment.attendees;
}

4. src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx (lines 237–300, fields array) — Add an Attendees entry, conditionally shown when the policy has attendees enabled (check policy?.isAttendeesEnabled or equivalent flag). Route it to the new SEARCH_EDIT_MULTIPLE_ATTENDEES_RHP:

...(policy?.isAttendeesEnabled
    ? [
          {
              description: translate('iou.attendees'),
              title: draftTransaction?.comment?.attendees?.map((a) => a.displayName).join(', ') ?? '',
              route: ROUTES.SEARCH_EDIT_MULTIPLE_ATTENDEES_RHP,
          },
      ]
    : []),

5. src/libs/actions/IOU/BulkEdit.ts, transactionChanges assignment block (after the reimbursable branch, ~line 227) — Add a branch that copies changes.attendees into transactionChanges:

if (changes.attendees && supportsExpenseFields && canEditField(CONST.EDIT_REQUEST_FIELD.ATTENDEES)) {
    transactionChanges.attendees = changes.attendees;
}

This mirrors the pattern of every other supportsExpenseFields-gated field in the same loop (category, tag, tax, billable).

6. src/libs/actions/IOU/BulkEdit.ts, updates object block (after the reimbursable branch, ~line 265) — Add the corresponding branch that copies transactionChanges.attendees into updates so it is included in the JSON payload sent to the server via API.write(WRITE_COMMANDS.UPDATE_MONEY_REQUEST, ...):

if (transactionChanges.attendees) {
    updates.attendees = JSON.stringify(transactionChanges.attendees);
}

Without this step the transactionChanges.attendees value is computed but never serialised into updates, so the API call carries no attendees data and the server never persists the change.

7. Navigation/router config — Register the new RHP route in the navigation stack (the same config file that registers the other SEARCH_EDIT_MULTIPLE_* screens) so the screen is reachable.

What alternative solutions did you explore? (Optional)

Reusing the existing single-expense IOURequestStepAttendees screen by adapting it to accept a bulk-edit context — but creating a dedicated page keeps the bulk-edit flow self-contained and avoids coupling unrelated IOU request state.

[melvin-bot]

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