[Payment due ASAP] [CFI] [$250] Feature Request: Add “Approver” column to Category and Tag list views

[m-natarajan]

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.3.25-13
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @abbagail
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

Problem:

Currently, when category or tag-level approvers are configured, there is no way to see them at a glance in the list view.
To determine whether a category or tag has an approver assigned, users must:
Click into each individual category or tag
Inspect the approver setting manually

Expected Result:

Admins can quickly see which categories/tags have approvers assigned.

Actual Result:

To determine whether a category or tag has an approver assigned, users must:
Click into each individual category or tag

Workaround:

Unknown

Requested Enhancement

Add an “Approver” column to:
Category list view
Tag list view
Column should display:
Assigned approver (if present)
Empty/null if none set
This column would only appear if:
The workspace has category/tag approvers enabled.

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Recording.2422.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @dylanexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022026414572237085882
• Upwork Job ID: 2026414572237085882
• Last Price Increase: 2026-02-24

EXFY-20167

[melvin-bot]

Triggered auto assignment to @dylanexpensify (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details. Please add this Feature request to a GH project, as outlined in the SO. Remember to draft any necessary HelpDot updates by following the instructions here.

[melvin-bot]

Triggered auto assignment to @sonialiap (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Triggered auto assignment to Design team member for new feature review - @dubielzyk-expensify (NewFeature)

[MelvinBot]

Proposal

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

When category or tag-level approvers are configured on a workspace, there is no way to see them at a glance in the list view. Admins must click into each individual category or tag and inspect the approver setting manually. This is tedious, especially for workspaces with many categories/tags.

What is the root cause of that problem?

The category and tag list views (WorkspaceCategoriesPage.tsx and WorkspaceTagsPage.tsx) build their list items without including any approver information, even though the data is available in policy.rules.approvalRules.

Specifically:

• Categories — WorkspaceCategoriesPage.tsx:204-264 builds each list item with only text (name), rightElement (GL Code + Switch), and metadata fields. No approver info is included.
• Tags — WorkspaceTagsPage.tsx:268-317 follows the same pattern — name, GL Code, Switch toggle, no approver.

The approver data is not stored on the category/tag objects themselves. Instead, it lives in policy.rules.approvalRules as ApprovalRule[] objects, each with an approver (email) and applyWhen conditions that match a category or tag name. Existing utilities already resolve this:

• getCategoryApproverRule() — looks up the approval rule for a category name
• getTagApproverRule() — looks up the approval rule for a tag name
• getPersonalDetailByEmail() — resolves the approver email to a display name

The detail pages (CategorySettingsPage.tsx:117-121, TagSettingsPage.tsx:57-59) already use this exact pattern to show the approver — it just needs to be replicated in the list views.

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

Use the existing alternateText field on TableListItem (which already renders secondary text below the item name — see TableListItem.tsx:125-131) to display the approver name. This pattern is already used by WorkspaceTaxesPage and PolicyDistanceRatesPage.

Changes needed:

1. WorkspaceCategoriesPage.tsx — In the list item builder (~line 204), for each category:

   • Look up the approver via getCategoryApproverRule(policy?.rules?.approvalRules ?? [], categoryName)
   • Resolve to display name via getPersonalDetailByEmail(approverEmail)?.displayName ?? approverEmail
   • Set alternateText on the list item (only when policy?.areRulesEnabled and an approver exists)

2. WorkspaceTagsPage.tsx — In the single-level tag list item builder (~line 268), for each tag:

   • Look up the approver via getTagApproverRule(policy, tagName)
   • Resolve to display name the same way
   • Set alternateText on the list item (only when policy?.areRulesEnabled, not multi-level tags, and an approver exists)

3. Optionally, on wide-screen Control policy layouts, add an "Approver" column header to the custom headers in both pages (WorkspaceCategoriesPage.tsx:298-328 and WorkspaceTagsPage.tsx:386-399) for visual clarity.

Conditions for visibility (matching existing behavior in detail pages):

• policy.areRulesEnabled must be true
• For tags: only single-level tags (not multi-level), consistent with TagSettingsPage.tsx:215

What alternative solutions did you explore? (Optional)

• Separate column approach: Instead of alternateText, add the approver as a distinct column in rightElement (like GL Code). This gives more visual separation but adds complexity to the layout and may crowd the row on narrow screens. The alternateText approach is simpler and follows the established pattern.
• Tooltip on hover: Show approver on hover over the category/tag name. This would be less discoverable and doesn't work well on mobile.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.