Custom field 1 and Custom field 2 do not update after editing custom field and opening Spend

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.25-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90937
Email or phone of affected tester (no customers): nsjoijojosdjosjosj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Create a Control workspace.
• Add value to Custom field 1 and Custom field 2 in your profile via workspace settings > Members.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create two expenses.
4. Go to Spend > Expenses.
5. Click Display > Edit columns.
6. Select Custom field 1 and Custom field 2 > Save.
7. Go to workspace settings > Members.
8. Click on your profile.
9. Edit Custom field 1 and Custom field 2.
10. Go to Spend tab.

Expected Result:

Custom field 1 and Custom field 2 will update after opening Spend.

Actual Result:

Custom field 1 and Custom field 2 do not update after opening Spend.
It only updates after opening Inbox and returning to Spend or opening the expense.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7195342_1782821667523.2.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7195342

Issue Owner

Current Issue Owner: @shubham1206agra

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/d066ff5b50bc214f507553facc2c58c48e8bada6de0f431e322d7d31ca4ca739

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #90937

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

Root Cause: The Spend > Expenses table renders Custom field 1/2 from report.submitterUserID / report.submitterPayrollID, which are only ever populated by the backend Search response into the snapshot_<hash> Onyx data. Editing a member's custom field writes to a completely different Onyx location — policy_<id>.employeeList[login].employeeUserID / employeePayrollID — and nothing on the client recomputes the report fields from it. So the columns stay stale until the Search API re-runs (which happens on screen re-focus), which is exactly why navigating to Inbox and back, or opening the expense, fixes it.

PR #90937 introduced this by intentionally rendering only from the report fields with no policy.employeeList fallback (stated in the PR description), so optimistic member edits never reach the table.

What is the root cause of that problem?

Two disjoint data sources:

• Edit writes to: Policy.ts updateMemberCustomField → policy.employeeList[login].employeeUserID/employeePayrollID (mapping in CONST.CUSTOM_FIELD_KEYS).
• Table reads from: report.submitterUserID/submitterPayrollID (TransactionItemRowWide.tsx:136-138, ExpenseReportListItemRowWide.tsx:53-54), sourced from the Search snapshot.

These report fields have no client-side writer — a grep of src/ shows submitterUserID/submitterPayrollID are only read, never written by any optimistic update. They refresh only when search() re-runs, which is triggered on Search screen re-focus in Search/index.tsx:360-396.

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

In the row components that render the columns, derive Custom field 1/2 from the live policy member data and fall back to the report field, so optimistic edits to policy.employeeList are reflected immediately:

1. Resolve the report submitter's login (from ownerAccountID via personal details).
2. Read policy.employeeList[submitterLogin].employeeUserID / employeePayrollID (via CONST.CUSTOM_FIELD_KEYS) reactively (the policy collection is already in Onyx).
3. Use that value, falling back to report.submitterUserID / submitterPayrollID when the member data isn't available.

This re-adds the policy.employeeList fallback that PR #90937 deliberately omitted, which is the source of the staleness. Apply it in both TransactionItemRowWide.tsx and ExpenseReportListItemRowWide.tsx (and the equivalent logic in ReportUtils.getReportCustomColumnValue if shared).

What alternative solutions did you explore? (Optional)

• Have updateMemberCustomField also optimistically update the report/snapshot fields for the member's reports. More complex — it must find every report submitted by that member and merge submitterUserID/submitterPayrollID into both live reports and active snapshots; the display-layer fallback is simpler and inherently reactive.
• Backend fix: confirm whether UpdatePolicyMembersCustomFields returns onyx updates for the affected reports/snapshots. If the intended design is for the column to mirror live member data, the client fallback is still the cleaner path.
• Revert PR feat: add three report custom columns to expense tables #90937 to clear the deploy blocker if a fix can't land quickly.

Investigation details & evidence

Confidence: High — two independent investigations agreed; fully explained by static analysis of disjoint Onyx data sources.

Data flow:

1. User edits Custom field 1/2 → updateMemberCustomField optimistically merges into policy_<id>.employeeList[login].employeeUserID/employeePayrollID only.
2. Table renders report.submitterUserID/submitterPayrollID from the Search snapshot (SearchUIUtils.getReportSections ~:2805, getTransactionsSections ~:2081).
3. The two Onyx keys are unrelated and nothing recomputes the report fields from policy data → columns stay stale.
4. Re-focusing the Search screen re-runs search() → Search API rewrites the snapshot with fresh values → table updates. (Same effect from opening the expense / re-fetching the report.)

Field definitions are display-only: Report.ts:101-108 document submitterUserID = "Custom field 1 value for the report submitter" and submitterPayrollID = "Custom field 2 value".

This is entirely within the App repo (the display layer reads the wrong/stale source), so a client-side fix is viable without backend changes.

---

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