[CFI] Report Fields should be enable-able when connected to an accounting integration

[melvin-bot]

Problem

When a workspace is connected to an accounting integration (e.g. NetSuite) but isn't importing any report fields from that integration, the Report Fields feature is effectively off, so no report field is shown on reports — even on multi-expense reports. Customers who set up report fields in Classic and rely on them lose access to them in New Expensify.

On Classic, admins can enable and use report fields independently of whether values are imported from the accounting connection. New Expensify should mirror this behavior.

Proposed changes

• Allow Report Fields to be enabled even when the workspace is connected to an accounting integration.
• If a report field value is imported from the accounting connection, prevent that report field from being disabled manually.

Context

• This affects multi-expense reports too, so it isn't specific to the single-expense report view.
• Decision in the thread was to mirror Classic here. As a short-term workaround, the affected workspaces can be manually set to enabled so customers can keep using what they've configured.

Reported in Slack.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022087611442864260671
• Upwork Job ID: 2087611442864260671
• Last Price Increase: 2026-08-12

[MelvinBot]

Proposal

What is the root cause of that problem?

New Expensify gates the entire Report Fields feature behind "no accounting connection." The toggle on the Reports page is force-disabled whenever the workspace has any accounting connection:

• WorkspaceReportsPage.tsx:326 — disabled={hasAccountingConnections || !canWriteReportFields}. When connected, the switch is locked and pressing it just routes to the accounting settings via onDisabledOrganizeSwitchPress.

So if a connected workspace never imported report-field values from its integration, areReportFieldsEnabled stays false and there's no way to turn it on in the UI — hence no report fields show on reports (single- or multi-expense). This mirrors the sibling Organize toggles (Categories/Tags/Taxes) in WorkspaceMoreFeaturesPage, but for report fields Classic intentionally allows admins to enable/use them independently of what the connection imports.

The second half of the request (protecting imported fields) is currently handled with the same blunt flag — the delete action for an individual field is hidden whenever any connection exists, regardless of whether that specific field came from the integration: ReportFieldsSettingsPage.tsx:134.

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

1. Allow enabling Report Fields when connected. In WorkspaceReportsPage.tsx, stop using hasAccountingConnections to disable the main Report Fields toggle — gate it only on !canWriteReportFields (and keep the Control-plan upgrade path). Also drop !hasAccountingConnections from the "Add field" affordance at line 340 so admins can add their own fields while connected.

2. Protect only integration-imported fields from being disabled/deleted. Replace the workspace-wide !hasAccountingConnections guard with a per-field check. Imported fields can be identified via the report field's origin / externalIDs metadata (PolicyReportField — origin is "Automated action or integration that added this report field", and externalIDs are "imported from the integrations"). Add a small helper (e.g. isReportFieldImportedFromIntegration) and use it to:

   • Hide the delete action in ReportFieldsSettingsPage.tsx:134 only for imported fields.
   • Keep manually-created fields fully editable/deletable even when connected.

Open questions / scope notes

• The exact signal for "imported from the accounting connection" needs confirming. origin is the most direct candidate but is barely referenced in App today (only harvest in ReportUtils.ts:2569); externalIDs presence is the alternative. Whoever picks this up should verify which field the backend reliably populates for integration-sourced report fields (NetSuite custom segments/lists, etc.).
• This is a frontend-only change in Expensify/App; enablePolicyReportFields already exists and doesn't block on connections. No backend change appears necessary for part 1.
• The subtitle currently shows "imported from your accounting software" text when connected (getHeaderText); with the toggle now interactive, confirm this copy still reads correctly.
• Short-term workaround (per the issue): manually set areReportFieldsEnabled = true on affected workspaces so customers keep using what they configured, until this ships.

I didn't find any existing open issue that duplicates this request.

---

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

[melvin-bot]

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

[melvin-bot]

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

[trjExpensify]

@MelvinBot in the plan, also don't allow the overall feature reportFields to be disabled if at least one reportField is being imported via the accounting solution.

[MelvinBot]

Got it — updating the plan so the overall Report Fields toggle can't be turned off while at least one report field is imported from the accounting connection.

Proposal (updated)

What is the root cause of that problem?

Same as before: New Expensify gates the whole feature on "no accounting connection" via WorkspaceReportsPage.tsx:326 (disabled={hasAccountingConnections || !canWriteReportFields}). We want the connection to stop blocking enabling, while still protecting integration-imported data from being switched off.

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

1. Enabling — remove hasAccountingConnections from the toggle's disabled condition so admins can turn the feature on while connected (keep !canWriteReportFields and the Control-plan upgrade path). Also drop !hasAccountingConnections from the "Add field" affordance at line 340.

2. Disabling the whole feature — block turning the toggle off when at least one report field is imported from the accounting connection. Concretely, compute hasImportedReportField = Object.values(policy?.fieldList ?? {}).some(isReportFieldImportedFromIntegration) and set the toggle's disabled condition to something like:
   disabled={!canWriteReportFields || (!!policy?.areReportFieldsEnabled && hasImportedReportField)}
   So when it's on and an imported field exists, the switch is locked on; the disabledAction should explain why (imported from the accounting connection) rather than routing to disconnect accounting.

3. Disabling an individual field — replace the workspace-wide !hasAccountingConnections guard on the delete action (ReportFieldsSettingsPage.tsx:134) with the same per-field isReportFieldImportedFromIntegration check — imported fields stay protected, manually-created ones stay deletable.

Open questions / scope notes

• Signal for "imported from the accounting connection" still needs confirming. The PolicyReportField type carries origin ("Automated action or integration that added this report field") and externalIDs ("imported from the integrations or auto generated by us"). Manually-created fields are created with externalIDs: [] (ReportField.ts:203), so origin set to the integration is the most reliable discriminator, but externalIDs alone is ambiguous. The implementer should confirm with the backend which field marks integration-sourced report fields (NetSuite custom segments/lists, etc.) and build isReportFieldImportedFromIntegration around it — this single helper backs points 2 and 3.
• Frontend-only change in Expensify/App; enablePolicyReportFields already exists and doesn't block on connections.
• Confirm the "imported from your accounting software" subtitle copy (getHeaderText) still reads correctly now that the toggle is interactive.
• Short-term workaround: manually set areReportFieldsEnabled = true on affected workspaces until this ships.

---

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