Workspace - Expensify card from another workspace appears on profile RHP in Submit workspace

[applause-bot]

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.4.0-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90995
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Log in with Expensifail account (applausetester+ssndjois2jd1@applause.expensifail.com).
• Enable Expensify card in workspace settings and assign yourself a virtual card.
• User is invited to Submit workspace.

1. Go to staging.new.expensify.com
2. Go to Submit workspace settings > Members.
3. Click on your profile.
4. Click on the card.

Expected Result:

In Step 3, Expensify card from another workspace will not appear on profile RHP in Submit workspace.

Actual Result:

In Step 3, Expensify card from another workspace appears on profile RHP in Submit workspace.
In Step 4, after clicking on the card, it redirects to More features page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7173629_1780763569961.22.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7173629

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/1702d727d9f27139be8e98950902fe6ed5eb5b0f95ef564a780363d1d8f32ef9

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #90995

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

🤖 Automated analysis — high confidence on the root cause. Note: this is not caused by the diff in #90995 (the PR this deploy blocker was auto-assigned to). That PR only changed the Role row's upgrade redirect in WorkspaceMemberDetailsPage.tsx; it does not touch the card section. This is a pre-existing card-scoping bug exposed by a member belonging to both an Expensify-Card workspace and a Submit workspace.

What is the root cause of that problem?

The "Assigned cards" section on the member profile pulls cards via getAllCardsForWorkspace, then filters by card.accountID === accountID. The card from workspace A leaks into workspace B through two compounding issues:

1. useExpensifyCardFeeds(policyID_B) is not scoped to B alone. It treats a settings entry as a match when B's policyID appears in workspace A's linkedPolicyIDs (isDomainFeed branch) — true whenever the member belongs to both workspaces. See useExpensifyCardFeeds.ts:14-20.
2. Substring key matching in getAllCardsForWorkspace. Workspace A's settings feed A's domain ID into expensifyCardsDomainIDs, and isExpensifyDomainCards then substring-matches A's Onyx key cards_{acctID_A}_Expensify Card — see CardUtils.ts:1141-1148. isWorkspaceAccountCards correctly does NOT match (B's policyAccountID differs / is 0 for a new Submit workspace).

The "redirects to More features" symptom is a downstream effect: tapping the card calls navigateToDetails, routing to WORKSPACE_EXPENSIFY_CARD_DETAILS for workspace B — which has no Expensify Card feature, so the route guard bounces to the More Features page.

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

Two layers (either alone fixes the visible bug; both are recommended for defense-in-depth):

• Gate the card section in WorkspaceMemberDetailsPage.tsx on the workspace actually having the feature enabled (e.g. policy?.areExpensifyCardsEnabled / areCompanyCardsEnabled) before rendering "Assigned cards". A Submit workspace with no card feature should never show this section.
• Tighten matching in getAllCardsForWorkspace so the Expensify-domain branch uses an exact key match (key === `cards_${workspaceAccountID}_${CONST.EXPENSIFY_CARD.BANK}` ) instead of key.includes(...), so cross-workspace linkedPolicyIDs can't pull another workspace's cards in.

Investigation details & evidence

• WORKSPACE_CARDS_LIST key format cards_{domainOrWorkspaceAccountID}_{bankName}: ONYXKEYS.ts:855, constructed at CompanyCards.ts:342.
• Linked-policy expansion (root + nested US/CURRENT/GB/TRAVEL_US program blocks): CardUtils.ts:1383-1399.
• The card section render is gated only on memberCards.length > 0, with no feature check: WorkspaceMemberDetailsPage.tsx:384.
• Alternative considered: that PR [Submit] Editor role + invite flows (Wave 2) #90995 introduced it — ruled out; its only change to this file is the Role-row redirect, unrelated to the card list.
• Related issue: [$250] Assigning Expensify Card in One Workspace Automatically Adds User to Another Workspace #91014 (Assigning Expensify Card in One Workspace Automatically Adds User to Another Workspace) appears to share the same cross-workspace card-linkage root and is worth cross-checking.

---

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

[iwiznia]

Not a blocker since this is under beta