[Due for payment 2026-07-16] [$250] Report custom fields disappear after the report is approved

[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.9-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: @danieldoglas
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Setup 2 accounts, an approver and an employee, with a workspace that has a custom field for reports
2. Create a new single expense report
3. Confirm that you can select the custom field
4. Submit that report
5. Confirm that the custom field is still available
6. With the other account, approve that report
7. Observe the custom field as submitter

Expected Result:

Custom report field displayed and should not disappear

Actual Result:

Custom report field disappear

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.3032.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067255317217049775
• Upwork Job ID: 2067255317217049775
• Last Price Increase: 2026-07-01

Issue Owner

Current Issue Owner: @Pujan92

[MelvinBot]

Proposal

What is the root cause of that problem?

When a single-expense report is approved, its custom report field disappears for the submitter because the combined report view hides the entire report-fields section once the only remaining editable field is the title.

The visibility of the section is gated on isOnlyTitleFieldEnabled, which is derived from enabledReportFields — a list filtered by editability, not by presence:

• isReportFieldDisabled returns true for every field when a non-admin views an approved report (!isAdmin && isApproved).
• enabledReportFields keeps only fields where !isReportFieldDisabled(...) or type === FORMULA. After approval, the custom field (text/date/list) is disabled and dropped, but the title field (type FORMULA) survives.
• That leaves enabledReportFields = [titleField], so isOnlyTitleFieldEnabled flips to true.
• For a single-expense report isCombinedReport is true, so the render guard (!isCombinedReport || !isOnlyTitleFieldEnabled) evaluates to false and the whole block — including the still-present, read-only custom field — is not rendered. See MoneyReportView.tsx:190-193.

The field's data is not lost (the approval optimistic update never touches fieldList) — it's purely a display gate. The bug conflates "field is editable" with "field should be shown". Disabled fields should still display as read-only after approval.

Why it's submitter-only, single-expense-only, and reproduces in prod

• Submitter only: isReportFieldDisabled returns false for policy admins, so admins keep enabledReportFields populated and never trip the guard.
• Single-expense only: the multi-transaction table renderer MoneyRequestViewReportFields has no isCombinedReport/isOnlyTitleFieldEnabled guard, so multi-expense reports are unaffected.
• Always reproduces (staging + prod): this is deterministic frontend logic keyed off stateNum/statusNum === APPROVED, not a backend/data issue.
• Note the divider guard shouldShowReportField already uses the correct presence-based check !sortedPolicyReportFields.every(shouldHideSingleReportField) — only the field render block uses the buggy isOnlyTitleFieldEnabled.

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

Make the "only the title field is present" determination depend on which fields exist/are visible, not on which are editable. Concretely, compute isOnlyTitleFieldEnabled from sortedPolicyReportFields (the full, presence-based list) instead of enabledReportFields. With a title + one custom field the list length stays 2 both before and after approval, so the section keeps rendering and the custom field shows as read-only. A workspace whose only configured field is the title still correctly hides the redundant section.

This keeps the existing intent (don't render an empty/redundant title-only section in the combined view) while no longer hiding genuinely-present custom fields just because approval made them non-editable.

What alternative solutions did you explore? (Optional)

Align the field render guard with the already-correct shouldShowReportField predicate (which uses !sortedPolicyReportFields.every(shouldHideSingleReportField)) so the divider and the fields use one consistent, presence-based condition.

---

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

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

A single‑expense report is rendered through the "combined" branch of MoneyReportContentCreated, which mounts MoneyReportView with the isCombinedReport prop set — this is the component that renders the report's custom fields ("Test" in the video) above the expense details:

App/src/pages/inbox/report/MoneyReportContentCreated.tsx

Lines 60 to 66 in 7761403

	<MoneyReportView
	report={report}
	policy={policy}
	isCombinedReport
	pendingAction={action?.pendingAction}
	shouldShowTotal={!!transaction && getCurrency(transaction) !== report?.currency}
	shouldHideThreadDividerLine={false}

Inside MoneyReportView, the whole report‑fields block is gated by (!isCombinedReport || !isOnlyTitleFieldEnabled):

App/src/components/ReportActionItem/MoneyReportView.tsx

Lines 190 to 193 in 7761403

	{(isGroupPolicyExpenseReport || isInvoiceReport) &&
	!!policy?.areReportFieldsEnabled &&
	(!isCombinedReport || !isOnlyTitleFieldEnabled) &&
	sortedPolicyReportFields.map((reportField) => {

Because isCombinedReport is true here, the block only renders when !isOnlyTitleFieldEnabled. And isOnlyTitleFieldEnabled is derived from editable fields, not displayed fields:

App/src/components/ReportActionItem/MoneyReportView.tsx

Lines 150 to 153 in 7761403

	const enabledReportFields = sortedPolicyReportFields.filter(
	(reportField) => !isReportFieldDisabled(report, reportField, policy) || reportField.type === CONST.REPORT_FIELD_TYPES.FORMULA,
	);
	const isOnlyTitleFieldEnabled = enabledReportFields.length === 1 && isReportFieldOfTypeTitle(enabledReportFields.at(0));

Note enabledReportFields keeps every FORMULA field unconditionally, but keeps a non‑formula field only while it is not disabled. The workspace's default Report Title is a title field of type FORMULA ({report:type} {report:startdate} → "Expense Report 2026-06-17"), so it is always present in this set.

When the report is approved, isReportFieldDisabled early‑returns true for the submitter (a non‑admin) for every field via the isApproved branch:

App/src/libs/ReportUtils.ts

Lines 4644 to 4646 in 7761403

	if (!isAdmin && (isReportSettled || isReportClosed || isApproved || isForwardedForSubmitter)) {
	return true;
	}

So the custom "Test" field (type TEXT) is now disabled and drops out of enabledReportFields, while the FORMULA title stays. enabledReportFields collapses to [title] → length === 1 && isReportFieldOfTypeTitle(...) (isReportFieldOfTypeTitle) → isOnlyTitleFieldEnabled flips to true → the combined gate becomes false → the entire fields block (including the still‑relevant custom field) is not rendered.

Before approval the custom field is editable, so enabledReportFields has 2 entries (title + custom) → isOnlyTitleFieldEnabled is false → the block renders. That is exactly the before/after seen in the video.

So: single‑expense report → MoneyReportView rendered as combined → approval disables the non‑formula custom field → enabledReportFields collapses to the lone FORMULA title → isOnlyTitleFieldEnabled becomes true → combined‑view gate hides the whole report‑fields section → the custom field disappears.

Root cause in one line: isOnlyTitleFieldEnabled conflates "editable" with "displayable" — it is meant to suppress a combined‑view block that contains only the title (the title is already shown in the header), but it computes "only title" from editability, so once the other fields become read‑only (approved / settled / closed / forwarded) they are treated as absent and the block collapses to title‑only.

Contrast with the working case: multi‑expense reports render through MoneyRequestReportView → MoneyRequestViewReportFields, which is mounted without isCombinedReport (defaults to false), so its gate degrades to (... || !isCombinedReport) = always true and the fields keep showing — which is why only the single‑expense (combined) view reproduces the bug.

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

Base the combined‑view "hide when only the title is here" decision on the fields that are actually displayed, not the ones that are editable. The display filter already exists and is already in scope: shouldHideSingleReportField (imported at L42 and used in the render at L194) already returns true for title fields and for list fields with no enabled option.

So replace the editability‑based isOnlyTitleFieldEnabled check with a "is there any displayable (non‑title) field" check, e.g.:

const hasDisplayableReportField = sortedPolicyReportFields.some((field) => !shouldHideSingleReportField(field));

and gate the block with (!isCombinedReport || hasDisplayableReportField) (at L162 and L192). This preserves the original intent (don't render a lone‑title block in the combined view, since the title is already in the header) while no longer collapsing the section when non‑title custom fields exist but are read‑only.

The identical enabledReportFields / isOnlyTitleFieldEnabled pattern exists in the new report‑view sibling MoneyRequestViewReportFields:

App/src/components/MoneyRequestReportView/MoneyRequestViewReportFields.tsx

Lines 118 to 121 in 7761403

	const enabledReportFields = sortedPolicyReportFields.filter(
	(reportField) => !isReportFieldDisabled(report, reportField, policy) || reportField.type === CONST.REPORT_FIELD_TYPES.FORMULA,
	);
	const isOnlyTitleFieldEnabled = enabledReportFields.length === 1 && isReportFieldOfTypeTitle(enabledReportFields.at(0));

It is currently inert there because that component is always mounted with isCombinedReport defaulting to false (usages), but the same change should be applied there for consistency and to be safe against future combined usage.

Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Keep enabledReportFields but also count read‑only non‑formula fields (i.e. include fields that are disabled only because of report state). This works, but enabledReportFields is used solely for this single visibility check, so introducing a "displayable" predicate via the already‑imported shouldHideSingleReportField is cleaner and matches the predicate the render loop itself uses one line later, avoiding a second, divergent definition of "which fields count".

[lorretheboy]

Proposal

What is the root cause of that problem?

Both report‑field views render their list from one shared source — getReportFieldMaps, which delegates to getAvailableReportFields:

App/src/libs/ReportUtils.ts

Lines 13062 to 13076 in 968eccd

	function getReportFieldMaps(report: OnyxEntry<Report>, fieldList: Record<string, PolicyReportField>): {fieldValues: Record<string, string>; fieldsByName: Record<string, PolicyReportField>} {
	const fields = getAvailableReportFields(report, Object.values(fieldList ?? {}));
	const fieldValues: Record<string, string> = {};
	const fieldsByName: Record<string, PolicyReportField> = {};
	for (const field of fields) {
	if (field.name) {
	const key = field.name.toLowerCase();
	fieldValues[key] = field.value ?? field.defaultValue ?? '';
	fieldsByName[key] = field;
	}
	}
	return {fieldValues, fieldsByName};
	}

While the report is open/submitted, getAvailableReportFields merges the policy’s field definitions (policy.fieldList) with the values stored on the report (report.fieldList), so a custom field is visible to the submitter even if its definition only lives on the policy. But once the report reaches a finalized/settled state it takes an early return and gives back only report.fieldList, discarding every policy‑defined field:

App/src/libs/ReportUtils.ts

Lines 4741 to 4779 in 968eccd

	function getAvailableReportFields(report: OnyxEntry<Report>, policyReportFields: PolicyReportField[]): PolicyReportField[] {
	// Get the report fields that are attached to a report. These will persist even if a field is deleted from the policy.
	const reportFields = Object.values(report?.fieldList ?? {});
	const reportIsSettled = isSettled(report?.reportID);
	// If the report is settled, we don't want to show any new field that gets added to the policy.
	if (reportIsSettled) {
	return reportFields;
	}
	// If the report is unsettled, we want to merge the new fields that get added to the policy with the fields that
	// are attached to the report.
	const mergedFieldIds = Array.from(new Set([...policyReportFields.map(({fieldID}) => fieldID), ...reportFields.map(({fieldID}) => fieldID)]));
	const fields = mergedFieldIds.map((id) => {
	const field = report?.fieldList?.[getReportFieldKey(id)];
	const policyReportField = policyReportFields.find(({fieldID}) => fieldID === id);
	if (field) {
	return {
	...field,
	...(policyReportField
	? {
	disabledOptions: policyReportField.disabledOptions,
	values: policyReportField.values,
	}
	: {}),
	};
	}
	if (policyReportField) {
	return policyReportField;
	}
	return null;
	});
	return fields.filter(Boolean) as PolicyReportField[];
	}

So the causal chain is: the report is finalized after approval → getAvailableReportFields stops merging policy.fieldList and returns only what is physically stored on the submitter’s copy of report.fieldList → the custom field (whose definition the submitter had via the policy, not persisted onto their report copy) is no longer in the returned list → both consumers receive an empty/short list and the field vanishes.

The two consumers that inherit this are:

App/src/components/MoneyRequestReportView/MoneyRequestViewReportFields.tsx

Lines 90 to 116 in 968eccd

	const sortedPolicyReportFields = useMemo<EnrichedPolicyReportField[]>((): EnrichedPolicyReportField[] => {
	const {fieldValues, fieldsByName} = getReportFieldMaps(report, policy?.fieldList ?? {});
	const fields = Object.values(fieldsByName);
	return fields
	.filter((field) => field.target === report?.type)
	.filter((reportField) => !shouldHideSingleReportField(reportField))
	.sort(({orderWeight: firstOrderWeight}, {orderWeight: secondOrderWeight}) => firstOrderWeight - secondOrderWeight)
	.map((field): EnrichedPolicyReportField => {
	const fieldValue = resolveReportFieldValue(field, report, policy, fieldValues, fieldsByName);
	const isFieldDisabled = isReportFieldDisabledForUser(report, field, policy, currentUserAccountID);
	const isDeletedFormulaField = field.type === CONST.REPORT_FIELD_TYPES.FORMULA && field.deletable;
	const fieldKey = getReportFieldKey(field.fieldID);
	const violation = isFieldDisabled ? undefined : getFieldViolation(field);
	const violationTranslation = getFieldViolationTranslation(field, violation);
	return {
	...field,
	fieldValue,
	isFieldDisabled: isFieldDisabled && !isDeletedFormulaField,
	fieldKey,
	violation,
	violationTranslation,
	};
	});
	}, [policy, report, currentUserAccountID]);

App/src/components/ReportActionItem/MoneyReportView.tsx

Lines 142 to 148 in 968eccd

	const {sortedPolicyReportFields, fieldValues, fieldsByName} = useMemo(() => {
	const {fieldValues: values, fieldsByName: byName} = getReportFieldMaps(report, policy?.fieldList ?? {});
	const sorted = Object.values(byName)
	.filter((field) => field.target === report?.type)
	.sort(({orderWeight: a}, {orderWeight: b}) => a - b);
	return {sortedPolicyReportFields: sorted, fieldValues: values, fieldsByName: byName};
	}, [policy?.fieldList, report]);

Separately, isReportFieldDisabled marks the field disabled for any non‑admin once the report is approved, which is why even when it does render it’s no longer interactive for the submitter:

App/src/libs/ReportUtils.ts

Lines 4634 to 4653 in 968eccd

	function isReportFieldDisabled(report: OnyxEntry<Report>, reportField: OnyxEntry<PolicyReportField>, policy: OnyxEntry<Policy>): boolean {
	if (isInvoiceReport(report)) {
	return true;
	}
	const isReportSettled = isSettled(report?.reportID);
	const isReportClosed = isClosedReport(report);
	const isTitleField = isReportFieldOfTypeTitle(reportField);
	const isAdmin = isPolicyAdmin(policy);
	const isApproved = isReportApproved({report});
	const isForwardedForSubmitter = isReportOwner(report) && isExpenseReport(report) && isProcessingReport(report) && !isAwaitingFirstLevelApproval(report);
	if (!isAdmin && (isReportSettled || isReportClosed || isApproved || isForwardedForSubmitter)) {
	return true;
	}
	if (isTitleField) {
	return !reportField?.deletable;
	}
	return reportField?.type === CONST.REPORT_FIELD_TYPES.FORMULA;
	}

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

Fix the single convergence point — getAvailableReportFields. The settled early‑return exists only to avoid surfacing brand‑new policy fields on a finalized report, but it currently throws away fields the submitter was already seeing. Instead of returning bare report.fieldList, keep merging, but restrict the merge to fields that already exist on the report (or in the policy) rather than dropping policy definitions wholesale. In practice: run the same merge for settled reports, and when settled, exclude only policy fields whose fieldID is not present in report.fieldList.

That keeps the “don’t show newly added fields after settling” behavior while ensuring a field the submitter had selected (or that was already attached) continues to display read‑only after approval.

Because both MoneyRequestViewReportFields and MoneyReportView read through getReportFieldMaps/getAvailableReportFields, this one change fixes every entry point.

What alternative solutions did you explore? (Optional)

Keep the data layer as‑is and instead make sure approved reports stay viewable by relaxing the approval branch in isReportFieldDisabled so submitters see their fields read‑only — but that only restores interactivity state, not the missing field, so it does not address the actual disappearance.

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]

Proposal

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

After a report is approved (and subsequently moves to a settled/terminal state), the custom report fields that were visible on the report stop being displayed. Only fields that physically live on the report's own fieldList survive; policy-defined custom fields disappear.

What is the root cause of that problem?

getAvailableReportFields short-circuits as soon as the report is settled and returns only the fields stored on report.fieldList, skipping the merge with the policy's fieldList:

App/src/libs/ReportUtils.ts

Lines 4744 to 4749 in 7761403

	const reportIsSettled = isSettled(report?.reportID);
	// If the report is settled, we don't want to show any new field that gets added to the policy.
	if (reportIsSettled) {
	return reportFields;
	}

A custom report field only ends up in report.fieldList once it has been given a per-report value. A custom field that was shown via the policy definition (no explicit per-report value, or value resolved from the policy) is therefore dropped the moment the report reaches the terminal state, because the early return reportFields never reaches the merge branch below it. MoneyReportView renders straight from this list (via getReportFieldMaps), so the fields silently vanish from the UI:

App/src/components/ReportActionItem/MoneyReportView.tsx

Lines 142 to 148 in 7761403

	const {sortedPolicyReportFields, fieldValues, fieldsByName} = useMemo(() => {
	const {fieldValues: values, fieldsByName: byName} = getReportFieldMaps(report, policy?.fieldList ?? {});
	const sorted = Object.values(byName)
	.filter((field) => field.target === report?.type)
	.sort(({orderWeight: a}, {orderWeight: b}) => a - b);
	return {sortedPolicyReportFields: sorted, fieldValues: values, fieldsByName: byName};
	}, [policy?.fieldList, report]);

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

Do not discard the policy fields for settled reports — still merge policy report fields with the report's own fields so every custom field continues to render (read-only is already enforced separately by isReportFieldDisabled). In getAvailableReportFields, drop the settled early-return and always run the merge path, or have the settled branch union policy fields the same way:

// instead of: if (reportIsSettled) { return reportFields; }
const mergedFieldIds = Array.from(new Set([
    ...policyReportFields.map(({fieldID}) => fieldID),
    ...reportFields.map(({fieldID}) => fieldID),
]));
// ...build merged list (reportField value takes precedence over policy default)

Regression note: keep the existing precedence so a settled report still shows the value that was locked in on the report (report fieldList wins over the policy definition); we are only restoring fields that have no per-report entry, not changing stored values.

[Abdukhamid000]

Proposal

What is the root cause of that problem?

The report-field pipeline conflates two different questions: "is this field editable right now?" and "is this field enabled on the report?". [isReportFieldDisabled](https://github.com/Expensify/App/blob/main/src/libs/ReportUtils.ts#L4418-L4437) answers the first but is used to compute the second.

function isReportFieldDisabled(report, reportField, policy): boolean {
    ...
    const isApproved = isReportApproved({report});
    const isForwardedForSubmitter = isReportOwner(report) && isExpenseReport(report) && isProcessingReport(report) && !isAwaitingFirstLevelApproval(report);
    if (!isAdmin && (isReportSettled || isReportClosed || isApproved || isForwardedForSubmitter)) {
        return true;
    }
    ...
}

For a non-admin submitter, the moment the report is approved (isApproved true), this returns true for every field. That's correct for editability — you shouldn't be able to edit fields after approval. The problem is that the field-display components reuse this same function to decide which fields count as "enabled," and the section's visibility hinges on that count.

In [MoneyRequestViewReportFields](https://github.com/Expensify/App/blob/main/src/components/MoneyRequestReportView/MoneyRequestViewReportFields.tsx#L113-L124) (and the equivalent block in [MoneyReportView](https://github.com/Expensify/App/blob/main/src/components/ReportActionItem/MoneyReportView.tsx#L137-L149)):

const enabledReportFields = sortedPolicyReportFields.filter(
    (reportField) => !isReportFieldDisabled(report, reportField, policy) || reportField.type === CONST.REPORT_FIELD_TYPES.FORMULA,
);
const isOnlyTitleFieldEnabled = enabledReportFields.length === 1 && isReportFieldOfTypeTitle(enabledReportFields.at(0));
...
const shouldDisplayReportFields = (isPaidGroupPolicyExpenseReport || isInvoiceReport) && !!policy?.areReportFieldsEnabled && (!isOnlyTitleFieldEnabled || !isCombinedReport);

After approval, isReportFieldDisabled returns true for all non-formula fields, so enabledReportFields empties out. Combined with the combined-report path (!isOnlyTitleFieldEnabled || !isCombinedReport) and the per-field render guards, the submitter ends up with the custom field excluded from the "enabled" set — the field the submitter could see before approval no longer surfaces.

The bug is using an editability signal (isReportFieldDisabled, which goes true on approval) to answer an enablement question (is this field configured/active on this report). Approval should make the field read-only, not make it count as "not enabled."

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

Separate "enabled on the report" from "editable in the current state." Introduce a narrow check that answers only "is this field active/enabled" — independent of approval/settled/closed state — and use that for the enabledReportFields / visibility computation, while keeping isReportFieldDisabled for interactivity.

+/**
+ * Whether a report field is enabled on the report/policy, independent of whether the
+ * current report state (approved/settled/closed) makes it read-only. Used for deciding
+ * what to *display*; use isReportFieldDisabled to decide what's editable.
+ */
+function isReportFieldEnabled(reportField: OnyxEntry<PolicyReportField>): boolean {
+    if (!reportField) {
+        return false;
+    }
+    if (isReportFieldOfTypeTitle(reportField)) {
+        return !!reportField.deletable;
+    }
+    if (reportField.type === CONST.REPORT_FIELD_TYPES.LIST) {
+        return reportField.disabledOptions.some((option) => !option);
+    }
+    return true;
+}

Then in both field-display components, compute enabledReportFields from enablement rather than editability:

 const enabledReportFields = sortedPolicyReportFields.filter(
-    (reportField) => !isReportFieldDisabled(report, reportField, policy) || reportField.type === CONST.REPORT_FIELD_TYPES.FORMULA,
+    (reportField) => isReportFieldEnabled(reportField) || reportField.type === CONST.REPORT_FIELD_TYPES.FORMULA,
 );

The per-field interactivity stays as-is — the render still calls isReportFieldDisabledForUser to grey out / disable the row after approval, so an approved report's fields are correctly shown read-only. The only behavior that changes is that an approved report no longer reports "zero enabled fields," so the section and the custom field remain visible to the submitter.

What alternative solutions did you explore?

• Drop the isApproved clause from isReportFieldDisabled. Wrong — that would make fields editable after approval, which is a real regression. Approval must keep fields read-only; it just shouldn't hide them.
• Special-case approved reports in each display component (if (isApproved) skip the enabledReportFields filter). Scatters the same state check across two components and any future consumer. Centralizing "enabled vs editable" in a helper keeps the rule in one place.
• Treat this as a backend/data issue (field stripped from the approved report payload). I checked getAvailableReportFields — for an approved-but-not-reimbursed report it still merges policy.fieldList, so the field data is present. The disappearance is driven by the client's editability-as-enablement conflation, which is fixable in App.

[melvin-bot]

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

[x-dev90]

Proposal

What is the root cause of that problem?

getAvailableReportFields() only freezes report fields when the report is settled/reimbursed. For any non-settled report, it merges the fields attached to the report with the current policy field list:

App/src/libs/ReportUtils.ts

Lines 4741 to 4753 in 687b8b0

	function getAvailableReportFields(report: OnyxEntry<Report>, policyReportFields: PolicyReportField[]): PolicyReportField[] {
	// Get the report fields that are attached to a report. These will persist even if a field is deleted from the policy.
	const reportFields = Object.values(report?.fieldList ?? {});
	const reportIsSettled = isSettled(report?.reportID);
	// If the report is settled, we don't want to show any new field that gets added to the policy.
	if (reportIsSettled) {
	return reportFields;
	}
	// If the report is unsettled, we want to merge the new fields that get added to the policy with the fields that
	// are attached to the report.
	const mergedFieldIds = Array.from(new Set([...policyReportFields.map(({fieldID}) => fieldID), ...reportFields.map(({fieldID}) => fieldID)]));

An approved report is not settled because isSettled() only returns true for reimbursed reports, while approved reports use stateNum: APPROVED and statusNum: APPROVED:

App/src/libs/ReportUtils.ts

Lines 1530 to 1534 in 687b8b0

	function isReportApproved({report, parentReportAction = undefined}: {report: OnyxInputOrEntry<Report>; parentReportAction?: OnyxEntry<ReportAction> | undefined}): boolean {
	if (!report) {
	return parentReportAction?.childStateNum === CONST.REPORT.STATE_NUM.APPROVED && parentReportAction?.childStatusNum === CONST.REPORT.STATUS_NUM.APPROVED;
	}
	return report?.stateNum === CONST.REPORT.STATE_NUM.APPROVED && report?.statusNum === CONST.REPORT.STATUS_NUM.APPROVED;

At the same time, report fields are already treated as non-editable for non-admin users once the report is approved:

App/src/libs/ReportUtils.ts

Lines 4630 to 4645 in 687b8b0

	* For non title fields, its considered disabled if:
	* 1. The user is not admin of the report
	* 2. Report is settled, closed, approved, or submitted and already forwarded for review
	*/
	function isReportFieldDisabled(report: OnyxEntry<Report>, reportField: OnyxEntry<PolicyReportField>, policy: OnyxEntry<Policy>): boolean {
	if (isInvoiceReport(report)) {
	return true;
	}
	const isReportSettled = isSettled(report?.reportID);
	const isReportClosed = isClosedReport(report);
	const isTitleField = isReportFieldOfTypeTitle(reportField);
	const isAdmin = isPolicyAdmin(policy);
	const isApproved = isReportApproved({report});
	const isForwardedForSubmitter = isReportOwner(report) && isExpenseReport(report) && isProcessingReport(report) && !isAwaitingFirstLevelApproval(report);
	if (!isAdmin && (isReportSettled || isReportClosed || isApproved || isForwardedForSubmitter)) {
	return true;

So after approval, the submitter is viewing a finalized report-field state, but the display helper still depends on live policy fields. When those policy fields are not available in the submitter’s post-approval view, the custom report field disappears instead of being displayed from report.fieldList.

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

Treat approved reports the same way as settled reports inside getAvailableReportFields().

Required changes:

• Update getAvailableReportFields() to return only report.fieldList when isSettled(report?.reportID) or isReportApproved({report}) is true.
• Keep the current merge behavior for open/submitted reports so newly added policy fields still appear while the report is editable.
• Add a focused unit test for approved reports to confirm policy-only fields are not merged and attached report fields remain visible.

Tests that should be added:

• getAvailableReportFields returns only report.fieldList for an approved report, even when the policy has additional fields.

I considered preserving or injecting fields in the approval action, but the display bug is caused by the shared field-selection helper treating approved reports as mergeable/editable. Fixing getAvailableReportFields() keeps the behavior centralized for both report details and money report views.

What alternative solutions did you explore? (Optional)

[dilshodmackbook-sketch]

Proposal

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

Custom report fields disappear from a single‑expense report after the report is approved.

What is the root cause of that problem?

A single‑expense report (one that has a transaction thread) is rendered with isCombinedReport set to true:

App/src/pages/inbox/report/MoneyReportContentCreated.tsx

Lines 60 to 68 in 968eccd

	<MoneyReportView
	report={report}
	policy={policy}
	isCombinedReport
	pendingAction={action?.pendingAction}
	shouldShowTotal={!!transaction && getCurrency(transaction) !== report?.currency}
	shouldHideThreadDividerLine={false}
	shouldShowAnimatedBackground={false}
	/>

In MoneyReportView, the report‑fields block is only rendered when (!isCombinedReport || !isOnlyTitleFieldEnabled):

App/src/components/ReportActionItem/MoneyReportView.tsx

Lines 150 to 163 in 968eccd

	const enabledReportFields = sortedPolicyReportFields.filter(
	(reportField) => !isReportFieldDisabled(report, reportField, policy) || reportField.type === CONST.REPORT_FIELD_TYPES.FORMULA,
	);
	const isOnlyTitleFieldEnabled = enabledReportFields.length === 1 && isReportFieldOfTypeTitle(enabledReportFields.at(0));
	const isClosedExpenseReportWithNoExpenses = isClosedExpenseReportWithNoExpensesReportUtils(report);
	const isGroupPolicyExpenseReport = isGroupPolicyExpenseReportUtils(report);
	const isInvoiceReport = isInvoiceReportUtils(report);
	const shouldShowReportField =
	!isClosedExpenseReportWithNoExpenses &&
	(isGroupPolicyExpenseReport || isInvoiceReport) &&
	!!policy?.areReportFieldsEnabled &&
	(!isCombinedReport || !isOnlyTitleFieldEnabled) &&
	!sortedPolicyReportFields.every(shouldHideSingleReportField);

isOnlyTitleFieldEnabled is derived from enabledReportFields, which uses isReportFieldDisabled to decide which fields are "enabled":

App/src/libs/ReportUtils.ts

Lines 4634 to 4653 in 968eccd

	function isReportFieldDisabled(report: OnyxEntry<Report>, reportField: OnyxEntry<PolicyReportField>, policy: OnyxEntry<Policy>): boolean {
	if (isInvoiceReport(report)) {
	return true;
	}
	const isReportSettled = isSettled(report?.reportID);
	const isReportClosed = isClosedReport(report);
	const isTitleField = isReportFieldOfTypeTitle(reportField);
	const isAdmin = isPolicyAdmin(policy);
	const isApproved = isReportApproved({report});
	const isForwardedForSubmitter = isReportOwner(report) && isExpenseReport(report) && isProcessingReport(report) && !isAwaitingFirstLevelApproval(report);
	if (!isAdmin && (isReportSettled || isReportClosed || isApproved || isForwardedForSubmitter)) {
	return true;
	}
	if (isTitleField) {
	return !reportField?.deletable;
	}
	return reportField?.type === CONST.REPORT_FIELD_TYPES.FORMULA;
	}

The problem is that enabledReportFields conflates "editable" with "present". Once the report is approved, isReportApproved is true, so for the (non‑admin) submitter isReportFieldDisabled returns true for every field. The || reportField.type === FORMULA escape hatch keeps the default title field (which is a formula) in the list, while the custom (non‑formula) field is dropped. So enabledReportFields collapses to just the title field, isOnlyTitleFieldEnabled flips to true, and because the report is treated as combined the whole block is hidden — the still‑present custom field disappears.

The same pattern exists in the new report view:

App/src/components/MoneyRequestReportView/MoneyRequestViewReportFields.tsx

Lines 118 to 129 in 968eccd

	const enabledReportFields = sortedPolicyReportFields.filter(
	(reportField) => !isReportFieldDisabled(report, reportField, policy) || reportField.type === CONST.REPORT_FIELD_TYPES.FORMULA,
	);
	const isOnlyTitleFieldEnabled = enabledReportFields.length === 1 && isReportFieldOfTypeTitle(enabledReportFields.at(0));
	const isGroupPolicyExpenseReport = isGroupPolicyExpenseReportUtils(report);
	const isInvoiceReport = isInvoiceReportUtils(report);
	const shouldDisplayReportFields = (isGroupPolicyExpenseReport || isInvoiceReport) && !!policy?.areReportFieldsEnabled && (!isOnlyTitleFieldEnabled || !isCombinedReport);
	if (!shouldDisplayReportFields || !sortedPolicyReportFields.length) {
	return null;
	}

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

Visibility of the report‑fields block should depend on whether a renderable non‑title field exists, not on whether it is currently editable. We already have shouldHideSingleReportField, which returns true for the title field and for fields with no enabled options — i.e. it exactly identifies the fields that get rendered. So we should compute the "only title" check from that, independent of approval/disabled state.

In MoneyReportView, replace the enabledReportFields / isOnlyTitleFieldEnabled computation with:

const hasNonTitleReportField = sortedPolicyReportFields.some((reportField) => !shouldHideSingleReportField(reportField));

and use it in both the shouldShowReportField gate and the inline render condition, e.g. (!isCombinedReport || hasNonTitleReportField) in place of (!isCombinedReport || !isOnlyTitleFieldEnabled).

We should apply the identical change in MoneyRequestViewReportFields (shouldDisplayReportFields at the lines linked above).

With this, an approved report still has a custom field that is not hidden by shouldHideSingleReportField, so hasNonTitleReportField stays true and the block keeps rendering (the field is simply shown as non‑editable, which is the correct behavior post‑approval).

Note: this also makes the || reportField.type === FORMULA workaround unnecessary for this decision, since presence is no longer derived from the disabled state.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Add a test for MoneyReportView/MoneyRequestViewReportFields with isCombinedReport true and a custom (non‑title) report field, asserting the field stays rendered when the report state is APPROVED (and also REIMBURSED/CLOSED) for a non‑admin submitter, and that a report with only the title field still hides the block in combined view.

What alternative solutions did you explore? (Optional)

Alternatively, we could keep enabledReportFields but extend the filter so non‑editable‑yet‑present fields are not dropped when the report is approved/settled (e.g. only treat a field as "not enabled" when it is hidden, not when it is merely read‑only). That converges on the same idea; deriving the check directly from shouldHideSingleReportField is simpler and removes the need for the FORMULA special‑case.