[$250] LHN flooded with un-actionable workspace expense chats for threshold-based approvers

[mountiny]

Slack thread: https://expensify.slack.com/archives/C05LX9D6E07/p1773866461763689

Problem

Users who are high-level approvers with threshold-based approval (i.e., they only approve expenses over a certain dollar amount via approvalLimit/overLimitForwardsTo) are seeing all workspace expense chats in their LHN, even for reports that are well below their approval threshold and will never require their action.

This results in:

• LHN clogged with dozens/hundreds of un-actionable expense reports daily
• NewDot becomes unusable -- slows down, messages stop sending
• On mobile, the app becomes unresponsive until reports are manually dismissed via web

Expected Behavior

A REPORT_PREVIEW action should only mark the workspace expense chat as unread for a participant if they are the next person required to take action on that report (i.e., the current managerID). Other participants in the approval chain who are not the current approver should not have the chat marked as unread for them.

Current Behavior

When a report is submitted, every participant of the employee's policy expense chat receives the update. The high-level approver is a participant because they are in the approval chain. On the first submission:

1. The policy expense chat is created with participants including the employee, admins, and all approvers in the chain (including the high-level threshold-based approver)
2. The chat initially starts hidden for non-owners, but makePolicyExpenseChatVisibleForNonAuditorMembers (Report.cpp) flips the notification preference from hidden to always for all non-auditor participants -- regardless of whether the report requires their approval
3. A REPORT_PREVIEW action is created/updated, making the chat unread for the approver
4. The chat appears in LHN (in focus mode because it's unread and not muted; in default mode because it has content)

The approve badge (GBR) is correctly scoped to managerID only, so the approver doesn't see action buttons -- but the workspace chats themselves keep appearing as unread.

Impact

High-volume workspaces with many submitters and a multi-level approval chain are significantly affected. The volume of un-actionable LHN items causes performance degradation and makes the app unusable for the high-level approver.

Issue Owner

Current Issue Owner: @hoangzinh

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022034640384145591407
• Upwork Job ID: 2034640384145591407
• Last Price Increase: 2026-04-02

[melvin-bot]

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

[melvin-bot]

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

[MelvinBot]

Proposal

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

Threshold-based approvers (those with approvalLimit/overLimitForwardsTo configured) see all workspace expense chats in their LHN as unread, even for reports that are well below their approval threshold and will never require their action. This makes NewDot unusable for these users in high-volume workspaces. The GBR (approve/pay badge) is correctly scoped to the current managerID, but the chat unread state and LHN visibility are not.

What is the root cause of that problem?

There are two layers to this problem — a backend trigger and a frontend gap:

1. Backend trigger (makePolicyExpenseChatVisibleForNonAuditorMembers in Report.cpp): When a report is submitted, this function flips the notificationPreference from hidden to always for all non-auditor participants of the workspace expense chat — regardless of whether the report requires their approval. The threshold-based approver is a participant because they are in the approval chain, so their preference gets flipped to always even for reports below their threshold.

2. Frontend gap (isUnread in ReportUtils.ts:9009-9028): The function that determines whether a chat appears as unread (bold) in the LHN compares lastReadTime < lastVisibleActionCreated with zero awareness of managerID or approval chains. It's a pure timestamp comparison. When a REPORT_PREVIEW action is created/updated, lastVisibleActionCreated is bumped for all participants, but lastReadTime is only updated for the acting user. Every other participant sees the chat as unread.

In Focus mode (ReportUtils.ts:9579-9586), the LHN only shows unread + non-muted chats — so these chats appear because they're unread and have always notification preference. In Default mode (ReportUtils.ts:9596-9608), policy expense chats are explicitly exempted from the empty-chat filter (!isPolicyExpenseChat(report) at line 9600), so they always appear if they have any content.

Meanwhile, the GBR badge correctly checks managerID === userAccountID via canApproveIOU (IOU/index.ts:9674), which is why the approve button doesn't show — but the chat itself still appears as unread.

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

The fix should be on the backend in makePolicyExpenseChatVisibleForNonAuditorMembers (Report.cpp):

• When flipping notificationPreference from hidden to always, only do so for participants who are the current managerID (i.e., the next person who needs to take action on the report), not all approvers in the chain.
• When a report is forwarded to the next approver in the chain (e.g., the threshold-based approver after the report exceeds their approvalLimit), flip that approver's notificationPreference to always at that point.

This ensures the chat only becomes visible and unread for each approver when it's actually their turn to act.

What alternative solutions did you explore? (Optional)

Frontend-only fix: Modify reasonForReportToBeInOptionList in ReportUtils.ts to check, for policy expense chats, whether the current user is the managerID for any outstanding child expense report before treating the chat as unread. This would require iterating REPORT_PREVIEW actions and checking managerID on each linked expense report — feasible but adds complexity to a hot path that runs for every report in the LHN.

Auto-read approach: Have the backend automatically advance lastReadTime for participants who are not the current managerID whenever a REPORT_PREVIEW is created/updated. This would prevent the chat from appearing as unread without changing the notification preference, but it's a workaround rather than addressing the root cause.

The backend fix is preferred because it addresses the root cause directly — the notification preference should not be flipped for participants who don't yet need to act on the report.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[twilight2294]

Proposal

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

Threshold-based approvers (those configured with approvalLimit/overLimitForwardsTo) see all workspace expense chats flooded in their LHN as unread, even for reports well below their approval threshold that will never require their action. The GBR badge is correctly scoped, but the chat visibility is not.

What is the root cause of that problem?

The issue has two layers. First, when a report is submitted, the API sets the notificationPreference from hidden to always for all non-auditor participants of the policy expense chat — including threshold-based approvers who are participants solely because they exist in the approval chain via overLimitForwardsTo. This happens regardless of whether the report will ever reach their approval threshold, so the API should only flip the preference for the current managerID.

Second, on the frontend, reasonForReportToBeInOptionList() in ReportUtils treats these chats as visible because they are both unread (the REPORT_PREVIEW action bumps lastVisibleActionCreated) and not muted (preference is now always). In focus mode, the condition isUnread(report) && preference !== MUTE passes, so the chat appears.

Meanwhile, canApproveIOU() in IOU/index correctly checks managerID === userAccountID — which is why the GBR badge doesn't show. But the chat itself still appears as unread because chat visibility has no awareness of managerID or approval chains.

In default mode, policy expense chats are explicitly exempted from the empty-chat filter at line ~9593 via !isPolicyExpenseChat(report), causing them to always appear regardless of whether the user has any actionable items.

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

Apply a frontend fix in reasonForReportToBeInOptionList() in ReportUtils that leverages the existing correctly-scoped GBR logic. The key insight is that by the time execution passes the GBR check at line ~9531, we know the user has no actionable items on this report. For policy expense chats the user doesn't own, we can safely suppress them in focus mode:

// After the existing GBR check (~line 9533), add:
if (isPolicyExpenseChat(report) && !report.isOwnPolicyExpenseChat && isInFocusMode) {
    return null;
}

This works because:

• If the user IS the current managerID, requiresAttentionFromCurrentUser() already returned HAS_GBR earlier
• If execution reaches this point, the user has no action to take — safe to hide in focus mode

For default mode, tighten the policy expense chat exemption at line ~9593:

- !isPolicyExpenseChat(report) &&
+ (!isPolicyExpenseChat(report) || (!report.isOwnPolicyExpenseChat && !hasOutstandingChildRequest(report))) &&

This ensures non-owner policy expense chats only appear in default mode if they actually have outstanding child requests requiring action.

What alternative solutions did you explore? (Optional)

The existing MelvinBot proposal suggests fixing this purely on the API side by only setting notificationPreference to always for the current managerID. While that's the correct long-term fix, a frontend-only fix is preferable as an immediate solution because:

1. It can be shipped entirely within the App repo without API changes
2. It leverages the already-correct GBR logic (canApproveIOU / requiresAttentionFromCurrentUser) rather than duplicating approval-chain awareness
3. It provides immediate relief for affected users
4. The API fix can be filed separately and done in parallel

An auto-read approach (advancing lastReadTime for non-managerID participants) was also considered but rejected as a workaround rather than addressing the visibility logic directly.

[czarflix]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @czarflix Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.