[$250] Add card status to Expensify Card table

[joekaufmanexpensify]

Coming from this Slack thread, we want to add a card status column to the Expensify Card table, alongside the proposed Remaining Limit column (#95036).

Details

• We have received feedback from customers that they want to be able to easily tell whether a card is active, awaiting order, in transit, etc., directly from the Expensify Card table.
• To do this, let's add a "Status" column to the Expensify Card table with the following values, mapped from CONST.EXPENSIFY_CARD.STATE:
  • Pending order — STATE_NOT_ISSUED (2), physical only
  • Shipped — NOT_ACTIVATED (4), physical only
  • Active — OPEN (3), physical + virtual
  • Inactive — STATE_SUSPENDED (7), physical + virtual — covers any scenario where a card can't be used (i.e., frozen, flagged for potential fraud, limit set to $0, bank account locked, etc.)
• States 5 (STATE_DEACTIVATED) and 6 (CLOSED) are already excluded from this table by filterInactiveCardsForWorkspace and don't need handling.
• The stat is already available in Onyx, so I don't think we need any backend changes.
• With this column and the Remaining Limit column both being added, the table will need the column-hide-on-narrow-screens pattern already used elsewhere. We're thinking it's fine to hide status on a narrow screen.

Current Expensify Card table

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022074910004196374312
• Upwork Job ID: 2074910004196374312
• Last Price Increase: 2026-07-08

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

This is a new feature, not a bug. The Expensify Card table renders a fixed set of columns (name, type, limitType, lastFour, limit, actions) and has no Status column, so there's no way to tell a card's state (pending order, shipped, active, inactive) directly from the table.

The columns array is fixed here:

App/src/components/Tables/WorkspaceExpensifyCardsTable/index.tsx

Lines 107 to 142 in 29bb19f

	const columns: Array<TableColumn<WorkspaceExpensifyCardTableColumnKey>> = [
	{
	key: 'name',
	label: translate('workspace.expensifyCard.name'),
	sortable: true,
	},
	{
	key: 'type',
	label: translate('common.type'),
	sortable: true,
	},
	{
	key: 'limitType',
	label: translate('workspace.card.issueNewCard.limitType'),
	sortable: true,
	},
	{
	key: 'lastFour',
	label: translate('workspace.expensifyCard.lastFour'),
	sortable: true,
	},
	{
	key: 'limit',
	label: translate('workspace.expensifyCard.limit'),
	sortable: true,
	styling: {
	containerStyles: [styles.justifyContentEnd],
	},
	},
	{
	key: 'actions',
	label: '',
	sortable: false,
	width: variables.tableCaretColumnWidth,
	},
	];

The row-data shape (WorkspaceExpensifyCardTableRowData) and its column-key union carry no status:

App/src/components/Tables/WorkspaceExpensifyCardsTable/index.tsx

Lines 31 to 50 in 29bb19f

	type WorkspaceExpensifyCardTableColumnKey = 'name' | 'type' | 'limitType' | 'lastFour' | 'limit' | 'actions';
	type WorkspaceExpensifyCardTableRowData = TableData & {
	cardID: number;
	card: Card;
	lastFourPAN: string;
	name: string;
	cardholder?: PersonalDetails | null;
	limit: number;
	currency?: string;
	isVirtual: boolean;
	limitType: CardLimitType | undefined;
	frozenByDisplayName?: string;
	frozenByAccountID?: number;
	frozenDate?: string;
	errors?: OnyxCommon.Errors;
	pendingAction?: OnyxCommon.PendingAction;
	action: () => void;
	onClose: () => void;
	};

And the row-building useMemo never derives one from card.state:

App/src/pages/workspace/expensifyCard/WorkspaceExpensifyCardListPage.tsx

Lines 126 to 157 in 29bb19f

	const cardRows = useMemo<WorkspaceExpensifyCardTableRowData[]>(
	() =>
	allCards.map((card) => {
	const frozenByDisplayName = card.nameValuePairs?.frozen?.byAccountID
	? temporaryGetDisplayNameOrDefault({
	passedPersonalDetails: personalDetails?.[card.nameValuePairs.frozen.byAccountID],
	defaultValue: '',
	shouldFallbackToHidden: false,
	translate,
	}) || undefined
	: undefined;
	return {
	keyForList: String(card.cardID),
	cardID: card.cardID,
	card,
	lastFourPAN: card.lastFourPAN ?? '',
	name: card.nameValuePairs?.cardTitle ?? '',
	cardholder: personalDetails?.[card.accountID ?? CONST.DEFAULT_NUMBER_ID],
	limit: card.nameValuePairs?.unapprovedExpenseLimit ?? 0,
	currency: settlementCurrency,
	isVirtual: !!card.nameValuePairs?.isVirtual,
	limitType: card.nameValuePairs?.limitType,
	frozenByDisplayName,
	frozenByAccountID: card.nameValuePairs?.frozen?.byAccountID,
	frozenDate: card.nameValuePairs?.frozen?.date,
	errors: card.errors,
	pendingAction: card.pendingAction,
	action: () => Navigation.navigate(ROUTES.WORKSPACE_EXPENSIFY_CARD_DETAILS.getRoute(policyID, card.cardID.toString())),
	onClose: () => clearDeletePaymentMethodError(`${ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST}${defaultFundID}_${CONST.EXPENSIFY_CARD.BANK}`, card.cardID),
	};
	}),

card.state is already in Onyx and maps to CONST.EXPENSIFY_CARD.STATE, so no backend work is needed:

App/src/CONST/index.ts

Lines 4444 to 4451 in 29bb19f

	STATE: {
	STATE_NOT_ISSUED: 2,
	OPEN: 3,
	NOT_ACTIVATED: 4,
	STATE_DEACTIVATED: 5,
	CLOSED: 6,
	STATE_SUSPENDED: 7,
	},

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

Add a status column whose label is derived from card.state, following the exact pattern already used for limitType (getTranslationKeyForLimitType + compareItems).

1. A helper in CardUtils that maps state → label, honoring the physical/virtual split (Pending order/Shipped are physical-only; a virtual card is never shipped, so it reads Active):

function getTranslationKeyForCardStatus(state: number | undefined, isVirtual: boolean): TranslationPaths {
    switch (state) {
        case CONST.EXPENSIFY_CARD.STATE.STATE_NOT_ISSUED:
            return isVirtual ? 'workspace.expensifyCard.statusActive' : 'workspace.expensifyCard.statusPendingOrder';
        case CONST.EXPENSIFY_CARD.STATE.NOT_ACTIVATED:
            return isVirtual ? 'workspace.expensifyCard.statusActive' : 'workspace.expensifyCard.statusShipped';
        case CONST.EXPENSIFY_CARD.STATE.STATE_SUSPENDED:
            return 'workspace.expensifyCard.statusInactive';
        default:
            return 'workspace.expensifyCard.statusActive'; // OPEN
    }
}

States 5 (STATE_DEACTIVATED) and 6 (CLOSED) never reach this table — filterInactiveCardsForWorkspace already drops them — so the default safely means OPEN/Active.

2. Register the column between lastFour and limit, sortable like its neighbors:

{
    key: 'status',
    label: translate('workspace.expensifyCard.status'),
    sortable: true,
},

Remaining supporting changes (kept in text, not diffed):

• Add status: string to WorkspaceExpensifyCardTableRowData and 'status' to the column-key union.
• Populate it in the row useMemo: status: translate(getTranslationKeyForCardStatus(card.state, !!card.nameValuePairs?.isVirtual)).
• Render it in WorkspaceExpensifyCardsTableRow inside a !shouldUseNarrowTableLayout block, mirroring the existing type/limitType cells, and append it to accessibilityLabel. This gives us the agreed narrow-screen behavior (status hidden when the screen is narrow) for free.
• Add a status branch to compareItems (localeCompare on the two status strings), matching how limitType sorts.
• Add the five keys (status, statusPendingOrder, statusShipped, statusActive, statusInactive) under workspace.expensifyCard in en.ts and es.ts.

What alternative solutions did you explore? (Optional)

• Render status as a colored badge/pill instead of plain text — more scannable, but heavier and inconsistent with the table's all-text cells; better as a follow-up.
• Derive the status inside the row component straight from item.card.state and skip the new row field — but compareItems sorts on row data, not on the card, so the column wouldn't sort. Deriving it once in the useMemo keeps sorting and rendering consistent.

[Harxhit]

Proposal

What is the root cause of the problem?

The Expensify Card table currently doesn't expose a card's status, even though the information already exists in Onyx (CONST.EXPENSIFY_CARD.STATE).

Because the table only displays card details and not the underlying state, admins can't quickly distinguish whether a card is pending order, shipped, active, or inactive without opening the card details. This makes managing multiple cards unnecessarily difficult and is the reason customers requested a dedicated Status column.

Since inactive (STATE_DEACTIVATED) and closed (CLOSED) cards are already filtered out by filterInactiveCardsForWorkspace, the table only needs to handle the remaining visible states.

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

Add a Status column to the Expensify Card table and derive its value from the existing CONST.EXPENSIFY_CARD.STATE stored in Onyx.

Map the states as follows:

• STATE_NOT_ISSUED → Pending order (physical cards)
• NOT_ACTIVATED → Shipped (physical cards)
• OPEN → Active (physical and virtual cards)
• STATE_SUSPENDED → Inactive (physical and virtual cards)

No backend changes are required since the card state is already available on the client.

Because this issue is being implemented alongside the Remaining Limit column, the table should follow the existing responsive column behavior and hide the Status column on narrow screens, consistent with other tables in the app.

What alternative solutions did you explore?

I considered computing the status from other card properties (such as activation or shipping information), but the card state already exists in Onyx and is the canonical source of truth. Using CONST.EXPENSIFY_CARD.STATE avoids duplicating business logic and keeps the UI consistent with the existing card lifecycle.

[joekaufmanexpensify]

@shawnborton this one's straightforward, so I'm thinking we can skip mocks and go straight to the PR. Let me know if you feel differently, though.

[samranahm]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.