[$250] Collapse system messages that happen back-to-back in the report audit trail

[flaviadefaria]

Problem

The report audit trail can become long and hard to scan when there are many activity entries, especially when the same type of system action happens repeatedly back-to-back. Each entry currently takes up multiple rows, adding a lot of visual weight and making it harder to follow the actual conversation/collaboration on a report.

Proposal

Collapse system messages that happen back-to-back in the report audit trail so they can be grouped/collapsed into a single, more compact entry that can be expanded on demand.

As shown in the mockups below:

• Chat messages are never collapsed
• System messages are collapsed by default whenever there is more than one entry back-to-back
• If there's a single system message, then we don't collapse it
• All system messages display without an avatar

Context

This came up from a FullStory session review and also from LaTrobe feedback. Discussion in the team thread covered making the audit trail and comments more compact and improving scanability for reports with a lot of activity.

Reported in Slack.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022082435343442611733
• Upwork Job ID: 2082435343442611733
• Last Price Increase: 2026-07-30

Issue Owner

Current Issue Owner: @KJ21-ENG

[melvin-bot]

Current assignee @dubielzyk-expensify is eligible for the NewFeature assigner, not assigning anyone new.

[melvin-bot]

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

[melvin-bot]

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

[dubielzyk-expensify]

cc @Expensify/design for visibility

[aswin-s]

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

When a report's audit trail contains many consecutive system (non-chat) entries — policy changes, member changes, hold/unhold, dismissed violations, exports, company card connection errors, Plaid balance failures, etc. — the trail becomes long and hard to scan because each entry renders as a full row with an avatar and header. Per the mockups, the goal is: (1) all system messages render without an avatar (and without the name/timestamp header — "Todd Clyde submitted" and "Admin Adminson approved" appear as bare muted text), regardless of how many are present, and (2) runs of two or more consecutive system messages collapse by default into a single expandable summary entry showing a count ("4 changes was done" with a chevron), with the individual entries visible on expansion. Chat messages are never collapsed, and a single standalone system message is not collapsed.

What is the root cause of that problem?

This is a feature request. Neither audit-trail list has any notion of collapsing system message runs.

The mockups show the expense report audit trail — the expense table, Reimbursable/Total rows and report header above the trail place this in MoneyRequestReportView. So the primary surface is src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx, where renderReportAction (line 604) maps every visible action 1:1 to a row and computes displayAsGroup (lines 605–607) from isConsecutiveChronosAutomaticTimerAction + hasNextActionMadeBySameActor. The same pattern exists in the chat view's src/pages/inbox/report/ReportActionsList.tsx renderItem (line 356), which computes displayAsGroup (lines 369–372) from isConsecutiveChronosAutomaticTimerAction + isConsecutiveActionMadeByPreviousActor.

That path only suppresses the avatar on same-actor consecutive messages within a 5-minute window (canActionsBeGrouped, ReportActionsUtils.ts:1070); it never collapses an entire run into one expandable node, and a standalone system message with a different preceding actor still gets displayAsGroup=false and renders through ReportActionItemSingle with a full avatar and header.

The routing happens in src/pages/inbox/report/ReportActionItemFrame.tsx:63–82: displayAsGroup=false → ReportActionItemSingle (avatar + header), displayAsGroup=true → ReportActionItemGrouped (no avatar, no header, indented).

The two lists are ordered in opposite directions, which any run-detection pass has to account for. canActionsBeGrouped's own doc comment (line 1068) calls this out: "isConsecutiveActionMadeByPreviousActor and hasNextActionMadeBySameActor take action lists that are in opposite orders."

• ReportActionsList renders sortedVisibleReportActions descending (newest first) into an InvertedFlashList.
• MoneyRequestReportActionsList builds visibleReportActions ascending via filteredActions.slice().reverse() (line 211) for a non-inverted list.

There is no shared predicate in src/libs/ReportActionsUtils.ts for "is this a system (non-chat) action." Three existing classifiers together cover part of the surface:

• isPolicyChangeLogAction (line 415): covers POLICY_CHANGE_LOG_ARRAY
• isMemberChangeAction (line 678): covers MEMBER_CHANGE_ARRAY (both ROOM_CHANGE_LOG and POLICY_CHANGE_LOG invite/leave actions)
• isSimpleMessageAction (defined in src/pages/inbox/report/actionContents/SimpleMessageContent.tsx:47): HOLD, UNHOLD, MARKED_REIMBURSED, DISMISSED_VIOLATION, DELETED_TRANSACTION, CHANGE_POLICY and others — currently only accessible from that page component, and typed (action: ReportAction) rather than the OnyxInputOrEntry<ReportAction> its sibling predicates in ReportActionsUtils accept

Walking every muted-text branch of src/pages/inbox/report/actionContents/ActionContentRouter.tsx shows eleven action types rendered as system-style entries that fall outside all three predicates:

• COMPANY_CARD_CONNECTION_BROKEN (line 466), PLAID_BALANCE_FAILURE (line 473), CREATED_REPORT_FOR_UNAPPROVED_TRANSACTIONS (line 483)
• INTEGRATION_SYNC_FAILED (line 457), EXPORTED_TO_INTEGRATION (line 446)
• TAKE_CONTROL / REROUTE / REASSIGN_APPROVER (lines 487–489), SETTLEMENT_ACCOUNT_LOCKED (line 497)
• REMOVED_FROM_APPROVAL_CHAIN (line 323), RENAMED (line 455)

Any isSystemMessageReportAction predicate that omits these will fail to suppress their avatars and will fail to include them in collapsed runs.

Note: CONST.SYSTEM_MESSAGE_ACTION_TYPES does not exist anywhere in the codebase; any predicate referencing it would fail at runtime.

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

1. Move SIMPLE_MESSAGE_ACTION_TYPES and isSimpleMessageAction to src/libs/ReportActionsUtils.ts

They logically belong in the shared utils file alongside isPolicyChangeLogAction and isMemberChangeAction. Widen the signature to OnyxInputOrEntry<ReportAction> with a null guard to match its siblings, and update SimpleMessageContent.tsx to import it instead of defining it locally.

2. Add isSystemMessageReportAction to src/libs/ReportActionsUtils.ts

const ADDITIONAL_SYSTEM_MESSAGE_ACTION_TYPES = new Set<string>([
    CONST.REPORT.ACTIONS.TYPE.COMPANY_CARD_CONNECTION_BROKEN,
    CONST.REPORT.ACTIONS.TYPE.PLAID_BALANCE_FAILURE,
    CONST.REPORT.ACTIONS.TYPE.CREATED_REPORT_FOR_UNAPPROVED_TRANSACTIONS,
    CONST.REPORT.ACTIONS.TYPE.INTEGRATION_SYNC_FAILED,
    CONST.REPORT.ACTIONS.TYPE.EXPORTED_TO_INTEGRATION,
    CONST.REPORT.ACTIONS.TYPE.TAKE_CONTROL,
    CONST.REPORT.ACTIONS.TYPE.REROUTE,
    CONST.REPORT.ACTIONS.TYPE.REASSIGN_APPROVER,
    CONST.REPORT.ACTIONS.TYPE.SETTLEMENT_ACCOUNT_LOCKED,
    CONST.REPORT.ACTIONS.TYPE.REMOVED_FROM_APPROVAL_CHAIN,
    CONST.REPORT.ACTIONS.TYPE.RENAMED,
]);

function isSystemMessageReportAction(reportAction: OnyxInputOrEntry<ReportAction>): boolean {
    if (!reportAction?.actionName || isMessageDeleted(reportAction)) {
        return false;
    }
    return (
        isPolicyChangeLogAction(reportAction) ||
        isMemberChangeAction(reportAction) ||
        isSimpleMessageAction(reportAction) ||
        ADDITIONAL_SYSTEM_MESSAGE_ACTION_TYPES.has(reportAction.actionName)
    );
}

Deliberately an allow-list, not !isAddCommentAction(...). A negation-based classifier would sweep in interactive cards (money-request/report/task previews) and actionable whispers (join requests, mention/invite whispers, card fraud alerts), stripping their avatars and hiding them inside collapsed runs where the user can no longer act on them. The ADDITIONAL_* set is required because those eleven types are rendered as muted audit-trail text by ActionContentRouter but are not covered by any of the three existing classification predicates.

This function is the single source of truth for "is this a collapsible, no-avatar system entry," and being in ReportActionsUtils is what lets both lists adopt it without duplication.

3. Add an order-agnostic run-detection helper to src/libs/ReportActionsUtils.ts

function getSystemMessageRuns(reportActions: ReportAction[], forceExpandedActionIDs?: Set<string>): Map<string, {anchorID: string; memberIDs: string[]}>;

It walks the ordered visible actions, finds maximal runs of adjacent system messages, and marks every member of a run of length ≥ 2 with a shared {anchorID, memberIDs} record. Chat messages and single system messages are never marked, so they pass through untouched.

The anchor is always the first array element of the run. Because the chat list is descending and the expense list is ascending, that is the run's newest action in one and its oldest in the other — but in both it is the position where the collapsed summary row belongs visually, so callers do not need to reason about direction. A lookahead-based loop that assumes one ordering silently picks the wrong anchor in the other list.

Any action in forceExpandedActionIDs suppresses collapsing for its whole run (see step 5).

4. Derive the rendered array by filtering, and keep expansion state in the list component

In each list, memoize the collapsed array from the visible actions plus expansion state:

const [expandedRunIDs, setExpandedRunIDs] = useState(() => new Set<string>());
const systemMessageRuns = useMemo(() => getSystemMessageRuns(visibleActions, forceExpandedActionIDs), [visibleActions, forceExpandedActionIDs]);

const listData = useMemo(() => {
    if (systemMessageRuns.size === 0) {
        return visibleActions;
    }
    return visibleActions.filter((action) => {
        const run = systemMessageRuns.get(action.reportActionID);
        if (!run || expandedRunIDs.has(run.anchorID)) {
            return true;
        }
        return run.anchorID === action.reportActionID;
    });
}, [visibleActions, systemMessageRuns, expandedRunIDs]);

Hidden run members are removed from the array the list renders, rather than returning null for them from renderItem. Returning null keeps N virtualized cells alive to be measured and recycled, which produces blank gaps and desynchronises the scroll-index math; filtering keeps the data array 1:1 with rendered rows. This mirrors how ReportActionsList already derives renderedVisibleReportActions by injecting the synthetic Concierge draft action (line 202), so it is an established shape in this file rather than a new mechanism.

5. Rebase every index that is derived from the rendered array

This is the part that is easy to miss and breaks silently. Once rows are removed, an index from renderItem no longer indexes the source array, and anything comparing the two goes subtly wrong. In ReportActionsList all of these must resolve against listData, not renderedVisibleReportActions:

• actionBadgeTargetIndex (line 258) — drives scrollToActionBadgeTarget
• unreadMarkerReportActionIndex — useUnreadMarker indexes it against sortedVisibleReportActions; it feeds viewport tracking in useReportUnreadMessageScrollTracking and must be re-resolved
• the renderedVisibleReportActions passed to useReportActionsScroll (line 280) and useFollowActionBadgeTarget (line 328), both of which do findIndex/length against the FlashList data
• isConsecutiveChronosAutomaticTimerAction / isConsecutiveActionMadeByPreviousActor (lines 370–371), since index is an index into the rendered array
• shouldUseThreadDividerLine's oldest-action lookup (line 339) and shouldDisplayReplyDivider (line 375)

MoneyRequestReportActionsList needs the equivalent treatment for hasNextActionMadeBySameActor and the array handed to MoneyRequestReportTransactionList via visibleReportActions (line 796).

To keep the unread marker and comment permalinks pointing at a row that actually exists, pass the unread-marker action ID, the deep-linked linkedReportActionID, and the action-badge target ID as forceExpandedActionIDs so their run renders expanded rather than collapsed.

6. Suppress avatar and header for ALL system messages

In both lists, OR the classifier into displayAsGroup:

displayAsGroup={
    isSystemMessageReportAction(reportAction) ||
    (!isConsecutiveChronosAutomaticTimerAction(listData, index, chatIncludesChronosWithID(reportAction?.reportID), isOffline) &&
        isConsecutiveActionMadeByPreviousActor(listData, index, isOffline))
}

This routes a single standalone system message (not in any run, so not satisfying the consecutive-actor predicate) through ReportActionItemGrouped, giving the avatar-less, header-less muted row the mockups show. Doing it here rather than inside ReportActionItemFrame matters: ReportActionItemFrame is shared with Search (ChatListItem.tsx:89) and Debug (DebugReportActionPreview.tsx:29), which render a standalone action with displayAsGroup={false} and no adjacent timeline context. Patching the frame would strip the avatar there too; scoping the change to the two timeline lists cannot regress those surfaces.

7. Keep attribution on chat comments adjacent to a system message

Since system messages are now header-less, a chat comment next to one has no visible name to inherit. Today if the same actor submits a report (system) and then comments within 5 minutes, canActionsBeGrouped returns true and the comment renders through ReportActionItemGrouped — losing its avatar and its name, so it appears unattributed. Guard it in the shared predicate so grouping never spans the chat/system boundary in either direction:

if (isSystemMessageReportAction(adjacentAction) !== isSystemMessageReportAction(currentAction)) {
    return false;
}

The system message itself is still forced header-less by step 6, so this only affects the chat comment's own header, matching the mockups.

8. Add the collapsed summary row

A new CollapsedSystemMessagesRow in src/pages/inbox/report/, rendered inside ReportActionItemGrouped so it lines up with the avatar-less entries it replaces: muted count text plus a chevron, wrapped in PressableWithFeedback with accessibilityRole="button" and accessibilityState={{expanded}}. It stays visible when expanded with the chevron flipped, so the run can be collapsed again. renderItem/renderReportAction renders it for the run anchor; when the run is expanded it renders above the anchor's normal row.

9. Add the translation copy

report.collapsedSystemMessages in en.ts and es.ts, count-based with singular/plural. Note the mockup copy "4 changes was done" is ungrammatical — suggest "4 changes were done" / "1 change was done", pending design confirmation.

Behavior matrix:

Sequence	Before	After
1 system message	full entry with avatar + header	muted entry, no avatar, no header
≥2 consecutive system messages	N full entries with avatar	1 collapsed summary row + count; expand to see all N (still avatar-less)
chat messages (any count)	full entries	full entries (unchanged)
system → chat → system	3 full entries	system: no avatar; chat: unchanged; system: no avatar (no run)
system + chat by same actor <5min	chat grouped, may lose its header	chat keeps its own avatar + name header
run containing unread marker / deep link	N full entries	rendered expanded, so the marker and permalink still resolve

Scope: the mockups are the expense report trail, so MoneyRequestReportActionsList is the primary surface, but because the classifier and run-detection live in ReportActionsUtils both lists adopt them from the same helpers — the only per-list work is the index rebasing in step 5, which differs because the two arrays are ordered oppositely.

Tests:

• Unit coverage for isSystemMessageReportAction: each of the eleven ADDITIONAL_* types classifies as a system message; ADD_COMMENT, REPORT_PREVIEW, IOU, actionable whispers and CREATED do not; undefined returns false.
• Unit coverage for getSystemMessageRuns: a single system message is not grouped; chat runs are not grouped; a run of ≥2 groups with the correct anchor and members; a chat message splits two runs; a run at the end of the array closes correctly; a forceExpandedActionIDs member suppresses its whole run; the same run anchors to the first array element in both ascending and descending input.
• Retain the existing canActionsBeGrouped / isConsecutiveActionMadeByPreviousActor tests (same-actor 5-minute window, delegate, human agent, pending-delete/offline, Chronos) to prove chat grouping is unchanged, plus a new case asserting a comment adjacent to a system message is not grouped.
• Extend tests/ui/ReportActionsListTest.tsx for the collapsed default, the accessible expand/collapse control, all members rendering avatar-less after expansion, and unread/deep-linked runs rendering expanded.

What alternative solutions did you explore? (Optional)

Returning null from renderItem for hidden run members. Rejected. FlashList still allocates and measures those cells, causing blank gaps and recycling glitches, and it desynchronises the scroll-index math that pagination, the unread marker and the action-badge scroll all depend on. Filtering the data array keeps it 1:1 with rendered rows.

Overloading displayAsGroup / isConsecutiveActionMadeByPreviousActor to do the collapsing. Rejected. That predicate keys on same-actor identity and only selects a wrapper for an already-rendered action — it cannot hide member rows, own expansion state, or represent a run. It also imposes the 5-minute and same-actor constraints the consecutive-system rule does not have.

Defining "system message" by negation (!isAddCommentAction). Rejected. The timeline also carries interactive previews and actionable whispers that must keep their full framing and stay individually visible; a negation would strip their avatars and bury them in collapsed runs.

Patching ReportActionItemFrame to check the classifier directly. Rejected. That frame is shared with Search's ChatListItem and Debug's DebugReportActionPreview, which render standalone actions with displayAsGroup={false} and would lose their avatars. Scoping the change to the two timeline lists keeps those surfaces untouched.

Collapsing at the data layer (inside the visible-actions selectors or isActionVisibleOnMoneyRequestReport). Rejected. Expansion is transient per-user UI state and belongs in the view; those selectors are shared with notifications, LHN and Search.

Referencing CONST.SYSTEM_MESSAGE_ACTION_TYPES. Rejected. This constant does not exist in the codebase. Composing the three existing classification functions plus an explicit set for the remaining muted-text types in ActionContentRouter is correct today and keeps the gap list reviewable in one place.

[lorretheboy]

Proposal

What is the root cause of that problem?

This is a feature request, not a regression — there is simply no collapsing mechanism in the report view. Every entry in visibleReportActions is rendered 1:1 as its own row through renderReportAction:

App/src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx

Lines 604 to 631 in 7718b5e

	const renderReportAction = useCallback(
	(reportAction: OnyxTypes.ReportAction, indexWithinReportActions: number) => {
	const displayAsGroup =
	!isConsecutiveChronosAutomaticTimerAction(visibleReportActions, indexWithinReportActions, chatIncludesChronosWithID(reportAction?.reportID), isOffline) &&
	hasNextActionMadeBySameActor(visibleReportActions, indexWithinReportActions, isOffline);
	const shouldDisableContextMenuForConciergeDraft = isDraftPendingCompletion && draftReportActionID === reportAction.reportActionID;
	return (
	<ReportActionIndexContext.Provider value={indexWithinReportActions}>
	<ReportActionsListItemRenderer
	reportAction={reportAction}
	parentReportAction={parentReportAction}
	parentReportActionForTransactionThread={EmptyParentReportActionForTransactionThread}
	report={reportStable}
	transactionThreadReport={transactionThreadReport}
	chatReport={chatReport}
	displayAsGroup={displayAsGroup}
	shouldDisplayNewMarker={reportAction.reportActionID === unreadMarkerReportActionID}
	shouldDisplayReplyDivider={visibleReportActions.length > 1}
	isFirstVisibleReportAction={firstVisibleReportActionID === reportAction.reportActionID}
	shouldHideThreadDividerLine
	linkedReportActionID={linkedReportActionID}
	isHarvestCreatedExpenseReport={shouldShowHarvestCreatedAction}
	shouldDisableContextMenuForConciergeDraft={shouldDisableContextMenuForConciergeDraft}
	/>
	</ReportActionIndexContext.Provider>
	);
	},

The only "grouping" concept that exists today is displayAsGroup, driven by canActionsBeGrouped, which merely hides the avatar/header when consecutive messages come from the same actor within 5 minutes — it never reduces the number of rows and makes no distinction between chat comments (ADD_COMMENT) and system messages (submitted, approved, exported, field changes, etc.):

App/src/libs/ReportActionsUtils.ts

Lines 1070 to 1119 in 7718b5e

	function canActionsBeGrouped(currentAction?: ReportAction, adjacentAction?: ReportAction): boolean {
	// It's OK for there to be no previous action, and in that case, false will be returned
	// so that the comment isn't grouped
	if (!currentAction || !adjacentAction) {
	return false;
	}
	// Comments are only grouped if they happen within 5 minutes of each adjacent
	if (new Date(currentAction?.created).getTime() - new Date(adjacentAction.created).getTime() > CONST.REPORT.ACTIONS.MAX_GROUPING_TIME) {
	return false;
	}
	// Do not group if adjacent action was a created action
	if (adjacentAction.actionName === CONST.REPORT.ACTIONS.TYPE.CREATED) {
	return false;
	}
	// Do not group if adjacent or current action was a renamed action
	if (adjacentAction.actionName === CONST.REPORT.ACTIONS.TYPE.RENAMED || currentAction.actionName === CONST.REPORT.ACTIONS.TYPE.RENAMED) {
	return false;
	}
	// Do not group if the delegate account ID is different
	if (adjacentAction.delegateAccountID !== currentAction.delegateAccountID) {
	return false;
	}
	if (getHumanAgentAccountIDFromReportAction(currentAction) !== getHumanAgentAccountIDFromReportAction(adjacentAction)) {
	return false;
	}
	// Do not group if one of previous / adjacent action is report preview and another one is not report preview
	if ((isReportPreviewAction(adjacentAction) && !isReportPreviewAction(currentAction)) || (isReportPreviewAction(currentAction) && !isReportPreviewAction(adjacentAction))) {
	return false;
	}
	const currentActionActorAccountID = getReportActionActorAccountID(currentAction, undefined, undefined);
	const adjacentActionActorAccountID = getReportActionActorAccountID(adjacentAction, undefined, undefined);
	if (isSubmittedAction(currentAction) || isSubmittedAndClosedAction(currentAction)) {
	const currentActionAdminAccountID = currentAction.adminAccountID;
	return typeof currentActionAdminAccountID === 'number' ? currentActionAdminAccountID === adjacentActionActorAccountID : currentActionActorAccountID === adjacentActionActorAccountID;
	}
	if (isSubmittedAction(adjacentAction) || isSubmittedAndClosedAction(adjacentAction)) {
	return typeof adjacentAction.adminAccountID === 'number'
	? currentActionActorAccountID === adjacentAction.adminAccountID
	: currentActionActorAccountID === adjacentActionActorAccountID;
	}
	return currentActionActorAccountID === adjacentActionActorAccountID;

So a long run of back-to-back system actions always renders as N full rows, which is what makes the audit trail hard to scan.

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

1. Add two small helpers in ReportActionsUtils: isChatMessageAction (true only for ADD_COMMENT) and getCollapsibleSystemActionGroups(actions) which walks the visible actions in order and returns a list of items — either a single action, or a "run" of 2+ consecutive system actions (chat messages and single system messages are never grouped). Putting this in the shared util means the chat view's ReportActionsList can adopt it later with no duplication.

2. In MoneyRequestReportActionsList, derive the grouped items from visibleReportActions in a memo, and keep an expandedGroupIDs state (Set keyed by the run's first reportActionID). Runs render collapsed by default as one compact row — a summary line with a count (e.g. "8 updates", new translation key) and a chevron; tapping it expands the run in place, rendering the individual actions through the existing renderReportAction.

3. For the "no avatar on system messages" part of the design: pass displayAsGroup as true for every system message in an expanded run — ReportActionItemFrame already renders an avatar-less compact row through ReportActionItemGrouped for that flag, so no new frame component is needed:

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

Lines 63 to 82 in 7718b5e

	if (!displayAsGroup) {
	return (
	<ReportActionItemSingle
	action={action}
	showHeader={!isEditingInline}
	wrapperStyle={{
	...(isOnSearch && styles.p0),
	...(isWhisper && styles.pt1),
	}}
	report={report}
	iouReport={iouReport}
	isHovered={hovered}
	isActive={isActive}
	>
	{children}
	</ReportActionItemSingle>
	);
	}
	return <ReportActionItemGrouped wrapperStyle={isWhisper ? styles.pt1 : {}}>{children}</ReportActionItemGrouped>;

4. Edge cases: auto-expand a run when it contains the unread-marker action or a deep-linked linkedReportActionID (both are already available in the list component), so the "new messages" marker and comment links keep working.

What alternative solutions did you explore? (Optional)

Doing the collapsing purely visually inside ReportActionsListItemRenderer (rendering height-0 rows for collapsed actions). Rejected: it keeps N virtualized rows alive, complicates scroll/index math in the unified list, and scatters the logic across renderers instead of one grouping pass over the data.

[dilshodmackbook-sketch]

Proposal

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

In the report audit trail every system/activity action (created, submitted, approved, forwarded, renamed, member/policy changes, exports, integration/card errors, etc.) renders as its own full-height row with an avatar and header. Long back-to-back runs of these add vertical noise and bury the actual conversation. Per the mockups we want: (1) all system messages to render avatar-less and header-less, and (2) a run of two or more consecutive system messages to collapse by default into one compact, expandable summary row. Chat comments are never collapsed, and a single standalone system message is not collapsed.

What is the root cause of that problem?

This is a feature request — there is no notion of a collapsible "system message run" anywhere in the timeline.

The mockup is the multi-expense expense report trail, which is rendered by MoneyRequestReportView → MoneyRequestReportActionsList (not the inbox ReportActionsList):

App/src/components/MoneyRequestReportView/MoneyRequestReportView.tsx

Lines 172 to 173 in a0d8671

	const shouldDisplayMoneyRequestActionsList = !!isEmptyTransactionReport || shouldDisplayReportTableView(report, visibleTransactions ?? []);

There renderReportAction maps every visible action 1:1 to a row and the only grouping it computes is displayAsGroup, which merely hides the avatar/header for same-actor consecutive messages within 5 minutes — it never merges rows or hides anything behind an expander:

App/src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx

Lines 604 to 631 in a0d8671

	const renderReportAction = useCallback(
	(reportAction: OnyxTypes.ReportAction, indexWithinReportActions: number) => {
	const displayAsGroup =
	!isConsecutiveChronosAutomaticTimerAction(visibleReportActions, indexWithinReportActions, chatIncludesChronosWithID(reportAction?.reportID), isOffline) &&
	hasNextActionMadeBySameActor(visibleReportActions, indexWithinReportActions, isOffline);
	const shouldDisableContextMenuForConciergeDraft = isDraftPendingCompletion && draftReportActionID === reportAction.reportActionID;
	return (
	<ReportActionIndexContext.Provider value={indexWithinReportActions}>
	<ReportActionsListItemRenderer
	reportAction={reportAction}
	parentReportAction={parentReportAction}
	parentReportActionForTransactionThread={EmptyParentReportActionForTransactionThread}
	report={reportStable}
	transactionThreadReport={transactionThreadReport}
	chatReport={chatReport}
	displayAsGroup={displayAsGroup}
	shouldDisplayNewMarker={reportAction.reportActionID === unreadMarkerReportActionID}
	shouldDisplayReplyDivider={visibleReportActions.length > 1}
	isFirstVisibleReportAction={firstVisibleReportActionID === reportAction.reportActionID}
	shouldHideThreadDividerLine
	linkedReportActionID={linkedReportActionID}
	isHarvestCreatedExpenseReport={shouldShowHarvestCreatedAction}
	shouldDisableContextMenuForConciergeDraft={shouldDisableContextMenuForConciergeDraft}
	/>
	</ReportActionIndexContext.Provider>
	);
	},

Two things are missing:

• There is no shared predicate for "is this a system/audit action." Classification only exists implicitly inside ActionContentRouter, split across isPolicyChangeLogAction, isMemberChangeAction and the page-local isSimpleMessageAction, plus ~11 muted-text types (exports, INTEGRATION_SYNC_FAILED, COMPANY_CARD_CONNECTION_BROKEN, PLAID_BALANCE_FAILURE, RENAMED, etc.) that none of those three cover.
• A standalone system action that is not displayAsGroup routes through ReportActionItemSingle, which draws the avatar/header — contrary to the mockup:

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

Lines 63 to 82 in a0d8671

	if (!displayAsGroup) {
	return (
	<ReportActionItemSingle
	action={action}
	showHeader={!isEditingInline}
	wrapperStyle={{
	...(isOnSearch && styles.p0),
	...(isWhisper && styles.pt1),
	}}
	report={report}
	iouReport={iouReport}
	isHovered={hovered}
	isActive={isActive}
	>
	{children}
	</ReportActionItemSingle>
	);
	}
	return <ReportActionItemGrouped wrapperStyle={isWhisper ? styles.pt1 : {}}>{children}</ReportActionItemGrouped>;

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

Proof of concept (working branch): main...dilshodmackbook-sketch:collapse-system-messages-poc — implements the allow-list classifier, order-agnostic run detection, the collapse/expand summary row and avatar-less system messages on MoneyRequestReportActionsList. Typecheck, lint and React Compiler pass.

1. Add an allow-list classifier isSystemMessageAction in ReportActionsUtils. Deliberately an allow-list, not !isAddCommentAction(...): a negation would sweep in interactive previews (money-request/report/task) and actionable whispers, strip their avatars and bury them inside collapsed runs where the user can no longer act on them, and would silently absorb any new action type. Compose the three existing classifiers and an explicit set for the muted-text types they miss:

const ADDITIONAL_SYSTEM_MESSAGE_ACTION_TYPES = new Set<string>([
    CONST.REPORT.ACTIONS.TYPE.EXPORTED_TO_INTEGRATION,
    CONST.REPORT.ACTIONS.TYPE.INTEGRATION_SYNC_FAILED,
    CONST.REPORT.ACTIONS.TYPE.COMPANY_CARD_CONNECTION_BROKEN,
    CONST.REPORT.ACTIONS.TYPE.PLAID_BALANCE_FAILURE,
    CONST.REPORT.ACTIONS.TYPE.CREATED_REPORT_FOR_UNAPPROVED_TRANSACTIONS,
    CONST.REPORT.ACTIONS.TYPE.TAKE_CONTROL,
    CONST.REPORT.ACTIONS.TYPE.REROUTE,
    CONST.REPORT.ACTIONS.TYPE.REASSIGN_APPROVER,
    CONST.REPORT.ACTIONS.TYPE.SETTLEMENT_ACCOUNT_LOCKED,
    CONST.REPORT.ACTIONS.TYPE.REMOVED_FROM_APPROVAL_CHAIN,
    CONST.REPORT.ACTIONS.TYPE.RENAMED,
]);

function isSystemMessageAction(reportAction: OnyxInputOrEntry<ReportAction>): boolean {
    if (!reportAction?.actionName || isDeletedAction(reportAction)) {
        return false;
    }
    return (
        isPolicyChangeLogAction(reportAction) ||
        isMemberChangeAction(reportAction) ||
        isSimpleMessageAction(reportAction) ||
        ADDITIONAL_SYSTEM_MESSAGE_ACTION_TYPES.has(reportAction.actionName)
    );
}

Move isSimpleMessageAction (and its SIMPLE_MESSAGE_ACTION_TYPES) from SimpleMessageContent.tsx into ReportActionsUtils, widening its signature to OnyxInputOrEntry<ReportAction> with a null guard to match its siblings, and re-import it in SimpleMessageContent. This single predicate is what lets both lists adopt the behavior with no duplication.

2. Collapse a run into one synthetic group item, reusing the existing synthetic-item mechanism. ReportActionsList already injects a synthetic entry (the Concierge draft) into renderedVisibleReportActions, so this is an established shape rather than a new mechanism. I derive the rendered array the same way — walk the visible actions, find maximal runs of adjacent isSystemMessageAction, and when a run has length ≥ 2 and is not expanded, replace the whole run with one synthetic collapsed-group item carrying its members; single system messages and chat comments pass through untouched:

const [expandedGroupIDs, setExpandedGroupIDs] = useState(() => new Set<string>());
const groupedReportActions = useMemo(
    () => buildSystemMessageGroups(visibleReportActions, expandedGroupIDs, forceExpandedActionIDs),
    [visibleReportActions, expandedGroupIDs, forceExpandedActionIDs],
);

Collapsing the run into a single item (rather than filtering members out and returning null from renderItem) is what keeps the FlashList data 1:1 with rendered rows: the group is one cell, so keyExtractor, deep-link index lookups and viewable-index math see it as a single row and need no per-member rebasing. keyExtractor gets a branch keyed off the run anchor's reportActionID; renderItem renders a new avatar-less CollapsedSystemMessages summary row ("X updates" + chevron) that toggles the anchor ID in expandedGroupIDs. When expanded, the members render individually (still avatar-less, per step 3) with the chevron flipped so the run can be re-collapsed.

buildSystemMessageGroups anchors each run to its first array element. Because ReportActionsList is descending (newest first) and MoneyRequestReportActionsList is ascending, that element is the newest in one and the oldest in the other, but in both it is where the summary row belongs visually — so the helper is order-agnostic and both lists reuse it directly.

3. Force runs expanded when they carry the unread marker or a deep link. Pass the unread-marker action ID and the deep-linked linkedReportActionID (both already in the list component) as forceExpandedActionIDs; buildSystemMessageGroups leaves that run expanded so the "new messages" marker and comment permalinks still resolve to a row that actually exists.

4. Render all system messages without an avatar — scoped to the two timeline lists, not the frame. OR the classifier into displayAsGroup where each list computes it, so a standalone system message routes through ReportActionItemGrouped (avatar-less, header-less) instead of ReportActionItemSingle:

const displayAsGroup =
    isSystemMessageAction(reportAction) ||
    (!isConsecutiveChronosAutomaticTimerAction(...) && hasNextActionMadeBySameActor(...));

Doing it here rather than inside ReportActionItemFrame matters: that frame is shared with Search's ChatListItem and Debug's DebugReportActionPreview, which render standalone actions with displayAsGroup={false} and would lose their avatars. Scoping the change to the two lists cannot regress those surfaces.

5. Keep attribution on a chat comment adjacent to a system message. Since system messages are now header-less, a same-actor chat comment grouped next to one would inherit no visible name. Guard canActionsBeGrouped so grouping never spans the chat/system boundary in either direction:

if (isSystemMessageAction(previousAction) !== isSystemMessageAction(currentAction)) {
    return false;
}

6. Add translation copy report.collapsedSystemMessages in en.ts/es.ts, count-based with singular/plural (the mockup's "4 changes was done" is ungrammatical — suggest "4 changes were done" / "1 change was done", pending design).

Net behavior: chat comments unchanged; a lone system message renders compact and avatar-less; ≥2 back-to-back system messages collapse into one expandable summary; runs holding the unread marker or a deep link render expanded.

What alternative solutions did you explore? (Optional)

• Return null for the non-anchor rows of a run instead of a synthetic group item. Rejected: FlashList still allocates/measures those cells (blank gaps, recycling glitches) and desynchronises the scroll/deep-link/unread index math. Collapsing the run into one synthetic item keeps the data array 1:1 with rendered rows and mirrors the existing draft-action injection.
• Define "system message" by negation (!isAddCommentAction). Rejected: the timeline also carries interactive previews and actionable whispers that must keep their framing and stay individually visible; a negation strips their avatars, hides them in runs, and silently absorbs any new action type. The allow-list keeps the covered set reviewable in one place.
• Patch ReportActionItemFrame to check the classifier. Rejected: it is shared with Search's ChatListItem and Debug's DebugReportActionPreview, which would lose their avatars. Scoping avatar suppression to the two timeline lists avoids that.
• Group by actionName similarity (only collapse identical repeats). Rejected: the mockups collapse mixed runs, so the trigger is "consecutive system messages," not "consecutive identical messages."