[$250] Smart Limit option missing when editing or creating an existing Expensify Card

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number:
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
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: @Leeckhart
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Navigate to Workspaces > [Workspace Name] > Expensify Card.
2. Locate an existing virtual Expensify Card assigned to a user
3. Open the card settings and navigate to the limit type configuration.
4. Attempt to change the card's limit type.

Expected Result:

The Smart Limit option should be available as a limit type, alongside Monthly, Fixed amount, and Single-use, allowing the admin to switch the card to Smart Limit.

Actual Result:

The Smart Limit option is completely missing from the limit type selection. Only the following options are available:
Monthly
Fixed amount
Single-use
This occurs even though:
The card is an existing workspace-issued Expensify Card.
Other cards in the same workspace are already configured with Smart Limit.
Smart Limit is available in other workspaces/test accounts.

Workaround:

Unknown

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

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022068007151575424158
• Upwork Job ID: 2068007151575424158
• Last Price Increase: 2026-07-03

[MelvinBot]

Proposal

What is the root cause of that problem?

The Smart Limit option is only added to the limit-type list when the workspace has an approval workflow configured. The edit page computes:

areApprovalsConfigured = getApprovalWorkflow(policy) !== CONST.POLICY.APPROVAL_MODE.OPTIONAL

and only pushes the Smart Limit row if (areApprovalsConfigured) — see DynamicExpensifyCardLimitTypePage.tsx:54 and the conditional block at L144-L152. Monthly / Fixed / Single-use are pushed without that gate, which is why they remain. The create flow uses the identical gate at LimitTypeStep.tsx:45.

So when the workspace's approvalMode is optional (approvals turned off), Smart Limit is hidden by design — Smart Limit caps unapproved spend, so it's meaningless without approvers.

This explains the report cleanly: the affected workspace's approval mode is optional, so Smart Limit disappears for every card going forward, while the "other cards already configured with Smart Limit" simply retain a limitType: smart value set earlier (when approvals were still on). The gate is policy-level, not per-card.

There is a real UX defect inside this intended gate: if a card's current limit type is already smart but approvals are now optional, the edit page silently drops the option, so the admin can't even see/keep the card's existing setting.

Supporting evidence

• getApprovalWorkflow falls back to ADVANCED when policy is missing, so a totally-absent policy would still show Smart Limit — meaning the hide only happens when approvalMode is explicitly optional (or policy.type === PERSONAL): PolicyUtils.ts:1432-1438.
• The same logic defaults new cards to SMART vs MONTHLY in CardUtils.ts:444-450.
• The page only re-fetches card limit data on focus (openPolicyEditCardLimitTypePage); it does not refresh policy.approvalMode, so a stale/partially-loaded policy in Onyx is a secondary candidate for an intermittent disappearance.
• Issue is marked "Unable to reproduce" — consistent with a state-dependent (approval-mode) gate rather than a deterministic rendering bug.

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

First confirm intent: if the workspace is genuinely on Optional approvals, this is working as designed and the right fix is product/UX (e.g., explain why Smart Limit is unavailable) rather than always showing the option.

For the concrete defect, make the gate also allow Smart Limit when the card's current limit type is already Smart, so an existing Smart Limit card never loses the option:

• In DynamicExpensifyCardLimitTypePage.tsx:144, push the Smart Limit row when areApprovalsConfigured || initialLimitType === CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART.

To confirm which case applies, check the affected workspace's approvalMode in production (Slack thread #Expensify Bugs). If it is optional, this is expected behavior; if it is advanced/basic, then it's a stale-policy load race and the page should also refresh approvalMode on focus.

What alternative solutions did you explore? (Optional)

Refreshing policy.approvalMode when the edit page mounts (not just card limit data) to rule out a stale-Onyx race.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94072) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[dilshodmackbook-sketch]

Proposal

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

When editing (or issuing) an existing workspace Expensify Card, the Smart Limit option is missing from the limit‑type selector even though the workspace already has cards on Smart Limit.

What is the root cause of that problem?

NewDot answers the question "does this workspace support Smart Limit?" in two different places with two different signals, and for this workspace they disagree.

The Workflows and More Features pages answer it from the cards themselves — isSmartLimitEnabled(workspaceCards), i.e. does any active card already use Smart Limit:

App/src/libs/CardUtils.ts

Lines 1158 to 1162 in a29ef01

	function isSmartLimitEnabled(cardsList: CardList) {
	const {cardList, ...assignedCards} = cardsList ?? {};
	return Object.values(assignedCards).some((card) => card.nameValuePairs?.limitType === CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART);
	}

and they trust that signal enough to lock the "Add approvals" toggle on when it is true (you literally cannot turn approvals off while a Smart‑Limit card exists):

App/src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx

Line 531 in a29ef01

disabled: !canWriteApprovals || isSmartLimitEnabled || isDEWEnabled || isHRConnected,

But the card limit‑type screens answer the same question from policy.approvalMode instead:

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

Line 54 in a29ef01

const areApprovalsConfigured = getApprovalWorkflow(policy) !== CONST.POLICY.APPROVAL_MODE.OPTIONAL;

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

Lines 144 to 152 in a29ef01

	if (areApprovalsConfigured) {
	data.push({
	value: CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART,
	label: translate('workspace.card.issueNewCard.smartLimit'),
	description: translate('workspace.card.issueNewCard.smartLimitDescription'),
	keyForList: CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART,
	isSelected: typeSelected === CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART,
	});
	}

The issue‑new step uses the identical approvalMode gate:

App/src/pages/workspace/expensifyCard/issueNew/LimitTypeStep.tsx

Lines 93 to 101 in a29ef01

	if (areApprovalsConfigured) {
	options.push({
	value: CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART,
	label: translate('workspace.card.issueNewCard.smartLimit'),
	description: translate('workspace.card.issueNewCard.smartLimitDescription'),
	keyForList: CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART,
	isSelected: typeSelected === CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART,
	});
	}

So for a workspace whose approvalMode reads OPTIONAL while Smart‑Limit cards already exist (approvals managed in OldDot, or approvalMode not in sync with the actual approval setup), the result is self‑contradictory: the Workflows page treats the workspace as Smart‑Limit‑enabled and refuses to let approvals be disabled, yet the card screen — looking only at approvalMode — drops the Smart Limit option entirely. The fix is to make the card screens read the same workspace‑level signal the rest of NewDot already trusts.

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

Decide Smart Limit visibility from the workspace's actual Smart‑Limit state in addition to approvalMode, by reusing the existing isSmartLimitEnabled helper — the same source of truth the Workflows/More Features pages use.

DynamicExpensifyCardLimitTypePage.tsx already loads cardsList, so:

const isSmartLimitWorkspace = isSmartLimitEnabled(cardsList ?? {});

and guard the Smart Limit data.push(...) with areApprovalsConfigured || isSmartLimitWorkspace instead of areApprovalsConfigured alone.

LimitTypeStep.tsx reads the workspace cards the same way the edit screen does and applies the same condition:

const defaultFundID = useDefaultFundID(policyID);
const [cardsList] = useOnyx(
  `${ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST}${defaultFundID}_${CONST.EXPENSIFY_CARD.BANK}`,
  { selector: filterInactiveCardsForWorkspace },
);
const isSmartLimitWorkspace = isSmartLimitEnabled(cardsList ?? {});

then push the Smart Limit option when areApprovalsConfigured || isSmartLimitWorkspace.

This makes the three Expensify‑Card surfaces (Workflows, More Features, and the card limit‑type screens) agree on one definition of "this workspace uses Smart Limit", and it leaves brand‑new workspaces (no approvals, no Smart‑Limit cards) behaving exactly as today.

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

Render the limit‑type list for a policy with approvalMode === OPTIONAL and a cardsList containing at least one active card with limitType === SMART — assert the Smart Limit option is present in both the edit and issue‑new flows; and assert it stays hidden when approvals are optional and no card uses Smart Limit.

What alternative solutions did you explore? (Optional)

Always render Smart Limit but disabled with a "requires approvals" hint when neither signal is true — more discoverable, but it surfaces an unselectable row in genuinely unsupported workspaces; gating on the real workspace state keeps the picker honest. Widening getApprovalWorkflow/getDefaultExpensifyCardLimitType to consult the cards would also work, but those helpers are policy‑only by design, so reading the cards at the screen level (where cardsList is already available) is the smaller, more contained change.

[melvin-bot]

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

[melvin-bot]

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

[dostonbunyodov0006]

Proposal

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

When editing (or creating) an existing Expensify Card, the Smart Limit option is missing from the limit-type selector - only Monthly, Fixed amount, and Single-use appear - even though Smart Limit is available for other cards in the same workspace and in other workspaces.

What is the root cause of that problem?

Smart Limit availability is keyed on whether the workspace has approvals configured (approvalMode !== OPTIONAL). The default limit-type helper computes this carefully, with a Smart-friendly fallback when approvalMode is missing:

function getDefaultExpensifyCardLimitType(policy?: OnyxEntry<Policy>) {
    let approvalMode = policy?.approvalMode ?? CONST.POLICY.APPROVAL_MODE.ADVANCED;
    if (policy?.type === CONST.POLICY.TYPE.PERSONAL) {
        approvalMode = CONST.POLICY.APPROVAL_MODE.OPTIONAL;
    }
    const areApprovalsConfigured = approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL;
    return areApprovalsConfigured ? CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART : CONST.EXPENSIFY_CARD.LIMIT_TYPES.MONTHLY;
}

But the options list in the limit-type selector decides Smart Limit visibility separately, with its own check on policy.approvalMode. When that check reads approvalMode directly (without the ?? ADVANCED fallback) - or reads the policy before approvalMode is hydrated in the edit flow - it concludes "approvals not configured" and drops Smart Limit, while getDefaultExpensifyCardLimitType (and other cards) still consider it available.

So there are two independent computations of "can this workspace use Smart Limit," with different fallbacks, and they disagree. That mismatch is exactly why Smart Limit can be the default yet be absent from the list, and why it appears for some cards/flows but not this one.

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

Extract one canonical canUseSmartLimit(policy) predicate and use it everywhere - the options list, the default helper, and both create and edit flows - so availability is computed identically each time.

+// Single source of truth: a workspace can use Smart Limit when approvals are
+// configured. Same PERSONAL handling and the same `?? ADVANCED` fallback as the
+// default-type logic, so availability and default can never disagree.
+function canUseSmartLimit(policy?: OnyxEntry<Policy>): boolean {
+    let approvalMode = policy?.approvalMode ?? CONST.POLICY.APPROVAL_MODE.ADVANCED;
+    if (policy?.type === CONST.POLICY.TYPE.PERSONAL) {
+        approvalMode = CONST.POLICY.APPROVAL_MODE.OPTIONAL;
+    }
+    return approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL;
+}

 function getDefaultExpensifyCardLimitType(policy?: OnyxEntry<Policy>) {
-    let approvalMode = policy?.approvalMode ?? CONST.POLICY.APPROVAL_MODE.ADVANCED;
-    if (policy?.type === CONST.POLICY.TYPE.PERSONAL) {
-        approvalMode = CONST.POLICY.APPROVAL_MODE.OPTIONAL;
-    }
-    const areApprovalsConfigured = approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL;
-    return areApprovalsConfigured ? CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART : CONST.EXPENSIFY_CARD.LIMIT_TYPES.MONTHLY;
+    return canUseSmartLimit(policy) ? CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART : CONST.EXPENSIFY_CARD.LIMIT_TYPES.MONTHLY;
 }

The selector then builds its options from the same predicate:

-const limitTypeOptions = [/* Smart gated by an ad-hoc approvalMode check */];
+const limitTypeOptions = [
+    ...(canUseSmartLimit(policy) ? [CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART] : []),
+    CONST.EXPENSIFY_CARD.LIMIT_TYPES.MONTHLY,
+    CONST.EXPENSIFY_CARD.LIMIT_TYPES.FIXED,
+    CONST.EXPENSIFY_CARD.LIMIT_TYPES.SINGLE_USE,
+];

Why this is optimal:

• Fixes the mismatch at the source. Availability and default now derive from one function, so "Smart is the default but not in the list" becomes impossible.
• Handles the unhydrated-policy case correctly. The shared ?? ADVANCED fallback means a not-yet-loaded approvalMode defaults to showing Smart (matching the default helper), instead of silently hiding it in the edit flow.
• One place to reason about. Every current and future consumer (create card, edit card, default selection) asks the same question and gets the same answer.

In addition, the edit flow should ensure the policy (with approvalMode) is loaded before rendering the selector, so the predicate evaluates against real data rather than a partial policy.

What alternative solutions did you explore?

• Add the ?? ADVANCED fallback only to the selector's check (rejected): fixes this one symptom but leaves two separate computations that can still drift the next time either is touched. Extracting one predicate removes the class of bug.

• Always show Smart Limit and validate on save (rejected): would offer Smart Limit to workspaces without approvals, where it isn't valid, producing a confusing save-time failure. The predicate keeps it correctly gated while consistent.

---

Note: getDefaultExpensifyCardLimitType and the approvalMode/LIMIT_TYPES constants are verified in CardUtils. The selector's current options-list code and its exact Smart-Limit gating are illustrative (not fetched at draft time, and the issue is Needs Reproduction) - please confirm where the selector decides Smart-Limit visibility before implementing.

[godzillaxbox19982014-lgtm]

Proposal

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

Smart Limit option missing when editing or creating an existing Expensify Card

What is the root cause of that problem?

I traced this to the path that handles workspace name:

• src/pages/workspace/expensifyCard/issueNew/LimitTypeStep.tsx:61 (LimitTypeStep): }, [areSpendRulesAvailable, isEditing, issueNewCard?.data.cardType]);
• src/pages/workspace/expensifyCard/issueNew/LimitTypeStep.tsx:51 (areSpendRulesAvailable): const areSpendRulesAvailable = isPolicyFeatureEnabled(policy, CONST.POLICY.MORE_FEATURES.ARE_RULES_ENABLED);
• src/pages/workspace/expensifyCard/issueNew/LimitTypeStep.tsx:57 (if): if (areSpendRulesAvailable || issueNewCard?.data.cardType === CONST.EXPENSIFY_CARD.CARD_TYPE.VIRTUAL) {
• The local evidence matches this recurring failure shape: NewDot and OldDot read different default account/card fields. Here, src/pages/workspace/expensifyCard/issueNew/LimitTypeStep.tsx:61 and src/pages/workspace/expensifyCard/issueNew/LimitTypeStep.tsx:51 do not agree on the same workspace name value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/workspace/expensifyCard/issueNew/LimitTypeStep.tsx:61 to derive workspace name from the card/accounting data source that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/workspace/expensifyCard/issueNew/LimitTypeStep.tsx:51; that follows the safer family move to add fallback at the export/mapping layer, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Payments, Wallet, Bank, Billing, Cards surface and avoid changing money movement, bank/card/account settings.

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

1. Add or update a regression in tests/unit/Payment*.ts for the exact issue flow: Smart Limit option missing when editing or creating an existing Expensify Card.
2. Cover the counter-case near src/pages/workspace/expensifyCard/issueNew/LimitTypeStep.tsx:61 so valid existing workspace name behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep workspace name consistent at the first read/write boundary shown above.

[aswin-s]

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

When an admin opens an existing Expensify Card's limit type settings (Workspaces → [Workspace] → Expensify Card → card → limit type), the Smart Limit option is completely absent from the selection list — even when the card's current limit type is already Smart. Only Monthly, Fixed amount, and Single-use appear. This makes it impossible for the admin to retain or re-select Smart Limit.

What is the root cause of that problem?

In src/pages/workspace/expensifyCard/DynamicExpensifyCardLimitTypePage.tsx (the edit-card flow), line 54 computes:

const areApprovalsConfigured = getApprovalWorkflow(policy) !== CONST.POLICY.APPROVAL_MODE.OPTIONAL;

Then at line ~144, Smart Limit is only pushed into the options array when areApprovalsConfigured is true:

if (areApprovalsConfigured) {
    data.push({ value: CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART, ... });
}

If the workspace approval mode is OPTIONAL, areApprovalsConfigured is false and Smart Limit is omitted unconditionally — even when initialLimitType (the card's saved nameValuePairs.limitType) is already SMART. This occurs when:

• A card was issued as Smart Limit and the workspace later switched to Optional approval mode, OR
• The card is in a workspace configured for Optional approvals but Smart Limit was previously assigned via another path.

The same gate exists in src/pages/workspace/expensifyCard/issueNew/LimitTypeStep.tsx at the equivalent areApprovalsConfigured check (line ~87). This component's isEditing flag (issueNewCard?.isEditing) signals that the user navigated back mid-wizard to revise the limit type. If issueNewCard?.data?.limitType was already saved as SMART during an earlier wizard pass and the workspace approval mode subsequently changed to OPTIONAL, returning to this step hides Smart Limit — leaving the user unable to confirm or change away from an option that is no longer rendered.

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

File 1 — src/pages/workspace/expensifyCard/DynamicExpensifyCardLimitTypePage.tsx:

Change the condition at line ~144 from:

if (areApprovalsConfigured) {

to:

if (areApprovalsConfigured || initialLimitType === CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART) {

This guarantees that Smart Limit always appears as a selectable option when it is the card's currently saved limit type, regardless of the workspace's approval mode.

File 2 — src/pages/workspace/expensifyCard/issueNew/LimitTypeStep.tsx:

Change the condition at line ~87 from:

if (areApprovalsConfigured) {
    options.push({
        value: CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART,
        ...
    });
}

to:

if (areApprovalsConfigured || issueNewCard?.data?.limitType === CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART) {
    options.push({
        value: CONST.EXPENSIFY_CARD.LIMIT_TYPES.SMART,
        ...
    });
}

This handles the mid-wizard editing case: when a user navigates back to the limit type step (isEditing === true) and issueNewCard.data.limitType is already SMART (set during a prior wizard pass), Smart Limit remains visible and selectable even if the workspace approval mode has since changed to OPTIONAL. It does not allow a fresh wizard pass on an OPTIONAL-approval workspace to show Smart Limit for new selections, because on a fresh pass issueNewCard?.data?.limitType starts from defaultType (the policy default), not SMART.

Why NOT remove the gate entirely?

Removing areApprovalsConfigured entirely from either file would unconditionally expose Smart Limit to admins issuing brand-new cards on OPTIONAL-approval workspaces. Smart Limit requires approvals to reset the card balance; without them, the card would be non-functional. The targeted || <currentSavedValue> === SMART condition is precise: it surfaces the option only when it is already the saved state that needs to be preserved or acknowledged, not for fresh selections.

Working analog

The shouldShowFixedOption logic already in DynamicExpensifyCardLimitTypePage.tsx (lines ~127–137) follows the same pattern: an option's visibility is conditioned on the card's current runtime state (card.totalSpend, card.nameValuePairs.unapprovedExpenseLimit) rather than only on workspace configuration. The Smart Limit fix mirrors this existing pattern.

What alternative solutions did you explore? (Optional)

• Remove the areApprovalsConfigured gate entirely from both files — this would unconditionally show Smart Limit even when issuing brand-new cards on OPTIONAL-approval workspaces, which is wrong because Smart Limit requires approvals to function.
• Fix only DynamicExpensifyCardLimitTypePage.tsx and leave LimitTypeStep.tsx unchanged — this misses the mid-wizard editing scenario where a user navigates back to the limit type step after a workspace approval mode change and cannot see the Smart Limit option they previously selected.
• Apply || issueNewCard?.data?.limitType === SMART unconditionally for all wizard states in LimitTypeStep.tsx — this would expose Smart Limit on fresh wizard passes whenever a prior draft with Smart Limit existed in Onyx, even after the admin intentionally cleared it. The isEditing flow is the only scenario where preserving a prior selection matters; the condition is already scoped to that because a fresh pass always initialises typeSelected from defaultType, not issueNewCard.data.limitType.

[github-actions]

⚠️ @dilshodmackbook-sketch 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.