[Due for payment 2025-08-26] Prioritize `Approve` button over `Remove hold` for approvers/admins

[JmillsExpensify]

We recently added a Remove hold button to the report based on the following design spec.

In the case that an expense is held, the member holding the expense sees:

• A Remove hold primary action for the person who held the expense. This update adds consistency across all warn violations, which use a green button in the report header to nudge the user to resolve (note: the green button doesn’t trigger GBR in the LHN)
• A More button that minimally has options for Download, Change workspace, and View details. (Delete if their own expense)

If an approver views a one-expense report with a held expense, the header will prioritize the green Approve button, but Review will still appear in the workspace chat and Reports.

This ended up causing confusion in implementation, because it doesn't clearly call out the behavior for approvers on "batched" multi-expense reports. The intention is that we always prioritize the Approve button over Remove hold button. After all, whether one or every expense on a report is held, you could Approve and instantly unhold everything and approve in one go.

I'll go ahead and assign myself to this issue in case there are any additional questions.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021952424896041140242
• Upwork Job ID: 1952424896041140242
• Last Price Increase: 2025-08-04

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @JmillsExpensify

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Current assignee @JmillsExpensify is eligible for the Bug assigner, not assigning anyone new.

[sofi-a]

Proposal

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

Prioritize Approve button over Remove hold for approvers/admins

What is the root cause of that problem?

Feature enhancement.

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

Refactor the getReportPrimaryActionMove function in ReportPrimaryActionUtils by moving the following condition,

App/src/libs/ReportPrimaryActionUtils.ts

Lines 330 to 332 in fa244f2

	if (isApproveAction(report, reportTransactions, policy)) {
	return CONST.REPORT.PRIMARY_ACTIONS.APPROVE;
	}

above this one.

App/src/libs/ReportPrimaryActionUtils.ts

Lines 322 to 324 in fa244f2

	if (isRemoveHoldAction(report, chatReport, reportTransactions) || isPayActionWithAllExpensesHeld) {
	return CONST.REPORT.PRIMARY_ACTIONS.REMOVE_HOLD;
	}

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

N/A

What alternative solutions did you explore? (Optional)

N/A

[devhamzanaveed]

Proposal

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

The Remove hold button implementation is creating confusion for approvers when they view multi-expense reports with held expenses. While the design spec clearly defines that approvers should see an "Approve" button for single-expense reports, it doesn't specify what should happen for multi-expense reports where some or all expenses are held. This ambiguity is causing inconsistent button prioritisation, making it unclear whether approvers should see "Remove hold" or "Approve" as the primary action.

What is the root cause of that problem?

The design specification was incomplete - it only addressed the button hierarchy for single-expense reports but failed to define the expected behavior for multi-expense reports with held expenses. This gap in the specification led to unclear implementation requirements, where developers had to make assumptions about which button should take priority when approvers view batched reports containing held expenses.

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

We should implement a consistent, role-based button prioritization system that always shows the most efficient action for each user type:

For all approvers (regardless of report type):

1. Always show "Approve" as the primary green button
2. This allows them to approve and unhold everything in a single action
3. Works for both single-expense and multi-expense reports

For expense holders (the person who submitted/holds the expense):

1. Continue showing "Remove hold" as the primary action
2. Maintain current behavior for consistency

Update the button logic to check user role first:

1. If user has approval permissions for this report → show "Approve"
2. If user is the expense holder → show "Remove hold"
3. Keep "More" button with appropriate secondary actions

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

1. Single-expense held report (approver view): Verify "Approve" button appears as primary action
2. Multi-expense report with partially held expenses (approver view): Verify "Approve" button appears as primary action
3. Multi-expense report with all expenses held (approver view): Verify "Approve" button appears as primary action
4. Any report with held expenses (expense holder view): Verify "Remove hold" button appears as primary action
5. Button functionality: Test that "Approve" action properly removes holds and approves the report
6. More menu content: Verify correct secondary options appear based on user role and permissions

What alternative solutions did you explore?

Conditional prioritization based on hold status: Show "Remove hold" when all expenses are held, "Approve" when mixed. Rejected because it creates inconsistent UX and the approve action handles both scenarios effectively.
Dual primary buttons: Display both "Approve" and "Remove hold" as equal primary actions. Rejected because it clutters the interface and creates decision paralysis for users.
Smart button labeling: Change button text to "Approve & Remove Hold" when holds are present. Rejected because it makes the button text inconsistent and potentially confusing.