[$250] Duplicate Chase Feed Options Displayed When Adding Cards to a New Workspace

[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: 9.4.27-2
Reproducible in staging?: Needs Reproduction (Unable to reproduce in staging)
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: @PedroEspinoza1999
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Admin opened a workspace where cards needed to be assigned.
2. Admin navigated to Company Cards > Add Cards.
3. The system displayed multiple Chase feed from other workspace feed options.
4. Admin checked the original workspace under Company Cards.
5. In the original workspace, only one Chase feed was visible.
6. Admin selected the top Chase feed option in the new workspace and confirmed that it appeared to contain the expected cards.
7. The same duplicate feed options continued appearing across additional workspaces.

Expected Result:

When adding cards to a workspace, the system should display only one option for the existing Chase feed if there is only one actual feed available.

Actual Result:

The system displayed multiple Chase feed options when adding cards to a new workspace, despite only one Chase feed being visible from the original workspace. This created confusion for the admin and made it unclear which feed should be selected.

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/~022074488642724462654
• Upwork Job ID: 2074488642724462654
• Last Price Increase: 2026-07-07

[MelvinBot]

Proposal

What is the root cause of that problem?

The "From other workspaces" list in the card‑feed selector is built by getVisibleCompanyCardFeedsForSelector in CardFeedUtils.ts. It walks every sharedNVP_private_domain_member_<fundID> Onyx entry and dedupes rows using a Set keyed on ${fundID}_${feed} (CardFeedUtils.ts:701).

Because the dedup key includes fundID (the domain/policy account), a single physical Chase connection that has been shared into multiple domains/workspaces appears once per fund — each with a distinct ${fundID}_${feed} id but the same display name ("Chase"). Nothing collapses rows that point at the same underlying bank connection, so the admin sees several identical "Chase" options while the source workspace only shows one.

Evidence / data flow

1. WorkspaceCompanyCardFeedSelectorPage.tsx:184-208 renders one row per entry in otherFeeds.
2. otherFeeds comes from useOtherFeedsForFeedSelector.tsx:55-113, which reads ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER and only filters out feeds linked to / already available in the active policy. It does not dedupe across funds.
3. The list itself is produced by getVisibleCompanyCardFeedsForSelector; dedup Set is keyed on ${fundID}_${feed} only.

Confidence: Medium. The code path clearly produces one row per fund for a shared feed, which matches the report ("only one Chase feed in the original workspace, multiple in the new one"). What I can't confirm from code alone is which mechanism dominates for this specific reporter — the same feed shared across multiple funds/domains (the duplicate case), versus genuinely distinct numbered feed keys (chase, chase2) that legitimately represent two separate connections. An Onyx dump of sharedNVP_private_domain_member_* for the affected admin would distinguish them. Note the fix must not collapse genuinely-distinct connections.

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

De‑duplicate the selector list on bank‑connection identity rather than on fundID + feed. When the same underlying feed (same institution/connection) is visible under multiple funds/domains, collapse it into a single "From other workspaces" row. The cleanest place is getVisibleCompanyCardFeedsForSelector (CardFeedUtils.ts:655) — extend/replace the seenFeedIDs key with a stable connection identifier (e.g. bank name + institution/Plaid id), while preserving genuinely separate connections (numbered feeds like chase vs chase2 within a fund).

What alternative solutions did you explore? (Optional)

Dedupe by bank in the consumer hook useOtherFeedsForFeedSelector before pushing rows. This keeps the enumerator generic but risks other callers of the enumerator still seeing duplicates.

Possibly related issues

• [$250] Duplicate Chase Company Card Feed Created When Re-authenticating from a Different Workspace #95492 — Duplicate Chase Company Card Feed Created When Re‑authenticating from a Different Workspace
• [$250] Domain card feeds shown duplicated (and other domain feeds missing) in the card feed selector #93925 — Domain card feeds shown duplicated (and other domain feeds missing) in the card feed selector

---

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

[alazarlemma02]

Proposal

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

When an admin goes to a workspace’s Company Cards page and tries to add cards from an existing Chase feed, the “From other workspaces” section can show the same Chase feed multiple times.

This is confusing because the original workspace only has one actual Chase feed, and selecting any of the duplicate rows appears to point to the same underlying card feed.

What is the root cause of that problem?

The “from other workspaces” list is built by flattening feeds grouped by policy, but it does not dedupe feeds by the actual feed identity.

getCardFeedsForDisplayPerPolicy() intentionally indexes a feed under each linked policy:

for (const linkedPolicyID of validLinkedPolicyIDs) {
    (cardFeedsForDisplayPerPolicy[linkedPolicyID] ||= []).push(feedEntry);
}

That grouping is useful elsewhere, but useOtherFeedsForFeedSelector() then loops through every policy bucket and pushes each feed directly into the selector list:

for (const [feedPolicyID, cardFeeds] of Object.entries(cardFeedsByPolicy ?? {})) {
    for (const feed of cardFeeds) {
        ...
        otherPolicyFeeds.push({
            value: feed.id as CompanyCardFeedWithDomainID,
            feed: feedName as CompanyCardFeedWithNumber,
            fundID: Number(feed.fundID),
            ...
            keyForList: `${feedPolicyID}_${feed.id}`,
        });
    }
}

So if the same Chase feed is associated with multiple other workspaces, the same feed.id can be rendered multiple times. The composite keyForList makes those duplicate rows look like separate list items, even though selecting them calls the same linking path:

linkCardFeedToPolicy(feed.fundID, policyID, CONST.COMPANY_CARD.LINK_FEED_TYPE.COMPANY_CARD, feed?.country, feed.feed)

The root issue is not multiple Chase feeds existing in the source workspace. It is duplicate rendering of the same feed after flattening policy-grouped feed data.

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

Deduplicate the “from other workspaces” list in src/hooks/useOtherFeedsForFeedSelector.tsx by the feed’s real identity before rendering.

Steps of changes:

1. Keep getCardFeedsForDisplayPerPolicy() unchanged, because other screens need feeds grouped by policy.

2. In useOtherFeedsForFeedSelector(), track feed IDs that were already added to otherPolicyFeeds.

 const getOtherFeeds = () => {
     const otherPolicyFeeds: CardFeedListItem[] = [];
+    const addedFeedIDs = new Set<string>();

     for (const [feedPolicyID, cardFeeds] of Object.entries(cardFeedsByPolicy ?? {})) {
         for (const feed of cardFeeds) {
             if (feed?.linkedPolicyIDs?.includes(policyID)) {
                 continue;
             }
+
+            const feedKey = `${feed.id}_${feed.country ?? ''}`;
+            if (addedFeedIDs.has(feedKey)) {
+                continue;
+            }
+            addedFeedIDs.add(feedKey);
+
             const feedName = feed.feed;

3. Use that same deduped identity as the rendered row key.

-            keyForList: `${feedPolicyID}_${feed.id}`,
+            keyForList: feedKey,

This keeps one selectable row per actual feed while preserving the existing behavior when the feed is selected.

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

• A single Chase feed linked to multiple other workspaces should appear only once in the “From other workspaces” section.

• If the current workspace is already linked to the feed, that feed should still be excluded from “From other workspaces”.

• Selecting the deduped Chase feed should still call the same linking flow and update the selected feed with getCardFeedWithDomainID(feed.feed, feed.fundID).

• Existing feeds already visible in the current workspace’s main feed list should remain unaffected.

• Two genuinely different feeds with different feed.id values should still render as separate options.

What alternative solutions did you explore? (Optional)

I considered changing getCardFeedsForDisplayPerPolicy() to avoid indexing the same feed under multiple linked policies, but that is broader than needed and could affect other views that depend on policy-grouped feed data.

The safer fix is to dedupe only in useOtherFeedsForFeedSelector(), because the bug is specifically in the flattened selector UI.

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 13:48:23 UTC.

Proposal

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

When an admin opens a workspace and goes to Company Cards > Add Cards, the "From other workspaces" section shows the same Chase feed several times, even though only one Chase feed actually exists. The admin can't tell the rows apart and doesn't know which one to pick.

What is the root cause of that problem?

The duplicate rows are in the "From other workspaces" list, which is built by useOtherFeedsForFeedSelector (src/hooks/useOtherFeedsForFeedSelector.tsx:42). That hook calls getVisibleCompanyCardFeedsForSelector (src/libs/CardFeedUtils.ts:655), which walks every sharedNVP_private_domain_member_<fundID> entry and dedups on the key id = ${fundID}_${feed} (CardFeedUtils.ts:701-705).

That key is the problem. It's scoped to the fund, not to the feed itself. So when the same physical Chase feed is enumerated under more than one fundID (the admin administers several domains/workspaces that all surface it), each fundID produces its own row and the dedup never collapses them. Every row resolves to the label "Chase" through getCustomOrFormattedFeedName, and the subtitle that's supposed to tell them apart, alternateText = domainName ?? linkedPolicy?.name ?? firstLinkedPolicyID (useOtherFeedsForFeedSelector.tsx:90), comes back empty when the domain email and linked policy aren't resolvable. The result is a stack of identical "Chase" rows with no subtitle.

Worth flagging: this whole selector was rewritten recently in #93928 ("Drive card feed selectors off linkedPolicyIDs"), and the seenFeedIDs dedup is new code from that rewrite. The reporter is on 9.4.27-2, which may predate part of it, so this should be re-tested on latest main first. One caveat on the source of the data — sharedNVP_private_domain_member_* is server-populated and linkCardFeedToPolicy (src/libs/actions/CompanyCards.ts:1305) is a pure server call with no optimistic write, so if the backend is genuinely returning the same feed under multiple fund keys, that payload is the real origin and the client is only rendering what it's handed.

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

Two parts, both in useOtherFeedsForFeedSelector. First, collapse rows that represent the same physical feed by deduping otherPolicyFeeds on a feed-identity key (feed name plus the resolved domain/institution) rather than relying on the fund-scoped ${fundID}_${feed} key upstream. Second, guarantee a distinguishing subtitle so any feeds that really are separate stay separable: fall back alternateText to the workspace/domain that owns the feed instead of leaving it blank.

That keeps the fix minimal and on the display layer, where the "one row per real feed" intent from #93928 already lives, without touching the shared getVisibleCompanyCardFeedsForSelector used by the available list. Since this is a Needs Reproduction issue, before landing anything we should confirm from a repro whether the duplicate rows carry the same or different fundID/subtitle values, which tells us whether this is one feed enumerated twice or genuinely distinct feeds that just look alike.

I'd also add a test to tests/unit/CardUtilsTest.ts for the missing case: the same feed name appearing under multiple fundIDs in the payload should render one row. The existing selector tests only cover single-fund dedup.

What alternative solutions did you explore? (Optional)

Deduping inside getVisibleCompanyCardFeedsForSelector by loosening its ${fundID}_${feed} key. I rejected that because that function feeds both the available list and the other-workspaces list, and collapsing across funds there risks hiding a feed that legitimately belongs to a different workspace. Scoping the change to the other-workspaces hook is safer. I also considered only fixing the empty subtitle so the rows are at least distinguishable, but that leaves the actual duplicates on screen when they are the same feed, so it treats the symptom rather than the cause.

[abbasifaizan70]

Proposal

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

When an admin opens Company Cards > Add Cards on a workspace, the "From other workspaces" section shows several duplicate Chase feed options, even though the admin's original workspace only has one real Chase feed. More duplicates keep appearing as the admin visits additional workspaces.

What is the root cause of that problem?

The "From other workspaces" list on the feed selector page is built from useOtherFeedsForFeedSelector, which sources its data from getVisibleCompanyCardFeedsForSelector. That function walks every sharedNVP_private_domain_member_<X> Onyx entry and, as its own doc comment states, a feed can be discovered through two different storage keys for the same underlying feed: once via the domain's own account ID, and once via X being any workspace's policyAccountID that the admin manages (the workspace-level "Company cards" flow caches a copy of the domain's shared feed data under the current workspace's own key).

App/src/libs/CardFeedUtils.ts

Lines 641 to 654 in 68df9cd

	/**
	* Returns the company card feeds that should be visible to the current user in the feed selector,
	* enumerated exactly once per feed (keyed by `${fundID}_${feed}`).
	*
	* A feed is gathered from one of two sources:
	* 1. A domain the user is an admin of (the domain's account ID matches the feed's fundID).
	* 2. A policy the user is an admin of whose `policyAccountID` matches the feed's fundID.
	*
	* Whether a feed shows as an available feed or under "From other workspaces" is decided by the
	* caller using `linkedPolicyIDs` (active policy in `linkedPolicyIDs` → available, otherwise other).
	* There is intentionally no decision based on `preferredPolicy`.
	*
	* Note: "Expensify Card" feeds are not included (handled by the Expensify card selector).
	*/

The loop extracts fundID purely from the storage key suffix (domainKey.split('_').at(-1)), and then dedupes visible feeds with id = \${fundID}_${feed}`. Because the *same* physical Chase feed can be cached under a different storage key per workspace the admin administers, each of those copies produces a different fundID, so seenFeedIDs` never recognizes them as the same feed — one real feed shows up once per workspace the admin has visited/administers.

App/src/libs/CardFeedUtils.ts

Lines 676 to 715 in 68df9cd

	for (const [domainKey, cardFeeds] of Object.entries(allCardFeeds ?? {})) {
	// sharedNVP_private_domain_member_123456 -> 123456
	const fundID = domainKey.split('_').at(-1);
	if (!fundID) {
	continue;
	}
	const numericFundID = Number(fundID);
	// Visibility: the user must be an admin of the feed's domain or of a policy backed by this fund.
	const domain = getDomainByFundID(domains, numericFundID);
	const isDomainAdmin = isAdminSelector(currentUserAccountID)(domain);
	const isWorkspaceAdmin = adminPolicyFundIDs.has(numericFundID);
	if (!isDomainAdmin && !isWorkspaceAdmin) {
	continue;
	}
	for (const [key, feedData] of Object.entries(getOriginalCompanyFeeds(cardFeeds, feedKeysWithCards, numericFundID))) {
	// `getOriginalCompanyFeeds` is keyed by `CardFeedWithNumber`, but `Object.entries` widens the key to
	// `string`. Narrow it back with a type guard instead of an unsafe `as` assertion.
	if (!isCardFeedWithNumber(key)) {
	continue;
	}
	const country = feedData && 'country' in feedData ? (feedData.country ?? '') : '';
	const linkedPolicyIDs = feedData && 'linkedPolicyIDs' in feedData ? feedData.linkedPolicyIDs : undefined;
	const feed = key;
	const id = `${fundID}_${feed}`;
	if (seenFeedIDs.has(id)) {
	continue;
	}
	seenFeedIDs.add(id);
	visibleFeeds.push({
	id,
	feed,
	country,
	fundID,
	linkedPolicyIDs,
	name: getCustomOrFormattedFeedName(translate, feed, cardFeeds?.settings?.companyCardNicknames?.[feed], false) ?? feed,
	});
	}
	}

The feed data itself already carries the true, stable identifier for the owning domain — domainID — independent of which storage key it was read from, but this field is never used for deduplication:

App/src/types/onyx/CardFeeds.ts

Lines 105 to 106 in 68df9cd

	/** The id of the domain the feed relates to */
	domainID?: number;

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

Use the feed's own canonical domainID (when present) instead of the storage-key-derived fundID to build the dedup identity and the fundID returned for each visible feed. This way, the same domain-level feed cached under multiple workspace-scoped storage keys always collapses to a single entry, regardless of how many workspaces the admin manages.

App/src/libs/CardFeedUtils.ts

Lines 692 to 715 in 68df9cd

	for (const [key, feedData] of Object.entries(getOriginalCompanyFeeds(cardFeeds, feedKeysWithCards, numericFundID))) {
	// `getOriginalCompanyFeeds` is keyed by `CardFeedWithNumber`, but `Object.entries` widens the key to
	// `string`. Narrow it back with a type guard instead of an unsafe `as` assertion.
	if (!isCardFeedWithNumber(key)) {
	continue;
	}
	const country = feedData && 'country' in feedData ? (feedData.country ?? '') : '';
	const linkedPolicyIDs = feedData && 'linkedPolicyIDs' in feedData ? feedData.linkedPolicyIDs : undefined;
	const feed = key;
	const id = `${fundID}_${feed}`;
	if (seenFeedIDs.has(id)) {
	continue;
	}
	seenFeedIDs.add(id);
	visibleFeeds.push({
	id,
	feed,
	country,
	fundID,
	linkedPolicyIDs,
	name: getCustomOrFormattedFeedName(translate, feed, cardFeeds?.settings?.companyCardNicknames?.[feed], false) ?? feed,
	});
	}
	}

const country = feedData && 'country' in feedData ? (feedData.country ?? '') : '';
const linkedPolicyIDs = feedData && 'linkedPolicyIDs' in feedData ? feedData.linkedPolicyIDs : undefined;
const feed = key;
// The same domain-level feed can be cached under multiple `sharedNVP_private_domain_member_<X>` keys
// (once per workspace the admin manages), so dedupe by the feed's own domainID rather than the storage key.
const canonicalDomainID = (feedData && 'domainID' in feedData ? feedData.domainID : undefined) ?? numericFundID;
const id = `${canonicalDomainID}_${feed}`;
if (seenFeedIDs.has(id)) {
    continue;
}
seenFeedIDs.add(id);
visibleFeeds.push({
    id,
    feed,
    country,
    fundID: String(canonicalDomainID),
    linkedPolicyIDs,
    name: getCustomOrFormattedFeedName(translate, feed, cardFeeds?.settings?.companyCardNicknames?.[feed], false) ?? feed,
});

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 13:44:56 UTC.

Proposal

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

When an admin opens Company cards → Add cards in a workspace, the feed selector's "From other workspaces" section lists the same Chase feed several times, even though only one Chase feed actually exists (the original workspace correctly shows exactly one).

What is the root cause of that problem?

The structural cause: production builds the "From other workspaces" list by flattening a per-policy index of feeds — a map that deliberately contains the same feed object once per associated workspace — without deduplicating by feed identity. One real feed associated with N workspaces renders as N identical rows.

The report is against production 9.4.27-2. The evidence chain in that code (permalinks pinned to the 9.4.27-0 version cut, the code production runs):

1. useOtherFeedsForFeedSelector builds the list from cardFeedsByPolicy and pushes one row per (policy, feed) pair — the outer loop iterates policy entries, the inner loop pushes every feed in each entry:
   

   App/src/hooks/useOtherFeedsForFeedSelector.tsx

   Lines 53 to 55 in 353ea4e

   	for (const [feedPolicyID, cardFeeds] of Object.entries(cardFeedsByPolicy ?? {})) {
   	for (const feed of cardFeeds) {
   	if (feed?.linkedPolicyIDs?.includes(policyID)) {

2. That map comes from getCardFeedsForDisplayPerPolicy, which indexes the same feedEntry under every linked policy ("Index the feed under each linked policy so it appears for all of them"):
   

   App/src/libs/CardFeedUtils.ts

   Lines 597 to 602 in 353ea4e

   	const validLinkedPolicyIDs = linkedPolicyIDs?.filter(Boolean);
   	if (validLinkedPolicyIDs?.length) {
   	// Index the feed under each linked policy so it appears for all of them
   	for (const linkedPolicyID of validLinkedPolicyIDs) {
   	(cardFeedsForDisplayPerPolicy[linkedPolicyID] ||= []).push(feedEntry);
   	}

   
   and, for a feed with no linkedPolicyIDs/preferredPolicy, under every policy whose policyAccountID matches the feed's fundID — so the duplicate count grows as more workspaces are created on the fund:
   

   App/src/libs/CardFeedUtils.ts

   Lines 605 to 620 in 353ea4e

   	} else {
   	// Orphan feed: no linkedPolicyIDs and no preferredPolicy.
   	// Find policies whose policyAccountID matches the fundID so the feed
   	// still appears under the correct workspace.
   	const numericFundID = Number(fundID);
   	const matchingPolicies = Object.values(policies ?? {}).filter((policy) => policy?.policyAccountID === numericFundID);
   	if (matchingPolicies.length) {
   	for (const policy of matchingPolicies) {
   	if (policy?.id) {
   	(cardFeedsForDisplayPerPolicy[policy.id] ||= []).push(feedEntry);
   	}
   	}
   	} else {
   	// Still store under empty key so the feed is not silently lost
   	(cardFeedsForDisplayPerPolicy[''] ||= []).push(feedEntry);
   	}

3. The old code even acknowledged the collision instead of fixing it — the row key was made composite "so rows stay distinct if the same feed id appears under multiple policies":
   

   App/src/hooks/useOtherFeedsForFeedSelector.tsx

   Lines 72 to 73 in 353ea4e

   	// Composite key so rows stay distinct if the same feed id appears under multiple policies
   	keyForList: `${feedPolicyID}_${feed.id}`,

Affected surfaces (all consume this one hook, so all show the duplicates):

• Feed selector RHP opened from Add cards:

  App/src/pages/workspace/companyCards/WorkspaceCompanyCardFeedSelectorPage.tsx

  Line 81 in 353ea4e

  const otherFeeds = useOtherFeedsForFeedSelector(policyID);

• Company cards empty state (new workspace):

  App/src/pages/workspace/companyCards/WorkspaceCompanyCardPageEmptyState.tsx

  Line 52 in 353ea4e

  const otherFeeds = useOtherFeedsForFeedSelector(policyID);

• The Expensify Card feed selector had the same per-policy duplication class (ExpensifyCardFeedSelectorUtils.ts).

This chain explains every symptom detail:

• Original workspace shows one Chase feed: feeds linked to the active policy are skipped from "other" (L55) and shown once as available — which also proves only ONE feed object exists in the data (if the backend had duplicated the feed, the original workspace would show duplicates too).
• Top duplicate "contained the expected cards": every row is the same feed.
• Duplicates "continued appearing across additional workspaces": every workspace not linked to the feed renders one row per indexed policy.
• "Unable to reproduce in staging": staging already runs the fix — see below.

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

This exact mechanism was already fixed on main by PR #93928 (merged 2026-07-05): the hook now enumerates feeds via getVisibleCompanyCardFeedsForSelector, which walks the domain-member collection directly and emits each feed exactly once, deduplicated by its true identity ${fundID}_${feed}, then partitions available vs "From other workspaces" purely by linkedPolicyIDs membership plus a cross-list membership check:

App/src/libs/CardFeedUtils.ts

Lines 692 to 708 in f1182da

	for (const [key, feedData] of Object.entries(getOriginalCompanyFeeds(cardFeeds, feedKeysWithCards, numericFundID))) {
	// `getOriginalCompanyFeeds` is keyed by `CardFeedWithNumber`, but `Object.entries` widens the key to
	// `string`. Narrow it back with a type guard instead of an unsafe `as` assertion.
	if (!isCardFeedWithNumber(key)) {
	continue;
	}
	const country = feedData && 'country' in feedData ? (feedData.country ?? '') : '';
	const linkedPolicyIDs = feedData && 'linkedPolicyIDs' in feedData ? feedData.linkedPolicyIDs : undefined;
	const feed = key;
	const id = `${fundID}_${feed}`;
	if (seenFeedIDs.has(id)) {
	continue;
	}
	seenFeedIDs.add(id);
	visibleFeeds.push({
	id,
	feed,

App/src/hooks/useOtherFeedsForFeedSelector.tsx

Lines 61 to 73 in f1182da

	for (const feed of visibleFeeds) {
	// Feeds linked to the active policy are shown as available feeds, not under "From other workspaces".
	// Linked policy IDs can differ in casing, so compare case-insensitively (matches the Expensify-card path).
	if (feed?.linkedPolicyIDs?.filter(Boolean).some((linkedPolicyID) => linkedPolicyID.toUpperCase() === upperPolicyID)) {
	continue;
	}
	// Skip feeds already present in the active policy's available list to avoid duplicate rows across the two lists.
	// `companyCardFeeds` is keyed at runtime by the domain-ID-suffixed feed value (`${feed}${separator}${fundID}`),
	// so a membership check on that value avoids an unsafe assertion to the narrower `CompanyCardFeedWithNumber` key type.
	const feedValueForActivePolicy = getCardFeedWithDomainID(feed.feed, Number(feed.fundID));
	if (companyCardFeeds && feedValueForActivePolicy in companyCardFeeds) {
	continue;
	}

That PR shipped in 9.4.28-0 (cut 2026-07-06, currently staging) and was not cherry-picked to production 9.4.27-2 (no CP label) — which is exactly why QA could not reproduce on staging while the customer still sees it on production.

So the change needed in this repo is already merged; what remains is: (a) verify on staging ≥ 9.4.28-0 (Chase feed used across ≥2 workspaces → open Add cards in a fresh workspace → exactly one Chase row), then close this as resolved by #93928 once 9.4.28 deploys to production, or (b) cherry-pick #93928 to production if this needs fixing before the regular deploy. Regression safety in one sentence: #93928 landed with unit tests for both selectors (tests/unit/CardFeedUtilsTest.ts, tests/unit/hooks/useOtherFeedsForFeedSelector.test.tsx), and the available-feeds list and Expensify Card selector share the same single-enumeration path, so no sibling flow changes behavior further.

Why the obvious spot fix does not work: deduping rows by bank/display name inside the selector collapses genuinely distinct feeds — one Chase login can legitimately back two separate feeds for two legal entities (exactly this reporter's setup described in issue #92092), and those must remain separate rows; the only safe identity is (fundID, feed), which is what the merged fix dedupes on. Likewise, any new patch written against today's main targets code where the bug no longer exists.

One caveat: if duplicates still appear for this customer on ≥ 9.4.28, the remaining source is server-side duplicated Chase feed objects created by the reconnect loop tracked in #92092 (backend data, not this selector).

What alternative solutions did you explore? (Optional)

1. Name-based dedup in useOtherFeedsForFeedSelector — unsafe: merges two real feeds that share a bank name (multi-entity Chase logins), and hides which workspace a feed belongs to.
2. Dedup at render via SelectionList keys — masks the row count at the wrong layer and leaves selection ambiguous.
3. CP #93928 to production now — the right call only if customer impact can't wait for the 9.4.28 production deploy.

[samranahm]

Proposal

What is the root cause of that problem?

When an admin opens Company Cards, then Add Cards on a new workspace, the feed picker lists the same Chase feed several times even though only one real Chase feed exists.

The feed options shown in Add Cards are derived from buildFeedKeysWithAssignedCards in Card.ts, which walks the entire allWorkspaceCards collection and builds a Record<string, true> of feed keys that have assigned cards:

App/src/selectors/Card.ts

Line 20 in f1182da

const buildFeedKeysWithAssignedCards = (allWorkspaceCards: OnyxCollection<WorkspaceCardsList>): Record<string, true> => {

The collection is keyed per workspace card list (each policy/workspace stores its own WorkspaceCardsList). Because the function records the raw per-workspace card-list keys rather than a normalized bank/feed identifier, the same underlying Chase connection that is present across multiple workspaces yields multiple distinct keys. Each of those keys becomes its own row in the Add Cards feed list, so a single Chase feed renders as duplicate options. The original workspace shows only one entry because it holds a single card list for that feed, which is why the duplication only appears when aggregating across workspaces.

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

1. In Card.ts, normalize the record key inside buildFeedKeysWithAssignedCards so that entries are grouped by the actual feed/bank identifier instead of the per-workspace card-list key. This collapses the same Chase feed that exists on several workspaces into a single entry.

App/src/selectors/Card.ts

Line 20 in f1182da

const buildFeedKeysWithAssignedCards = (allWorkspaceCards: OnyxCollection<WorkspaceCardsList>): Record<string, true> => {

const buildFeedKeysWithAssignedCards = (allWorkspaceCards: OnyxCollection<WorkspaceCardsList>): Record<string, true> => {
    const feedKeys: Record<string, true> = {};
    Object.values(allWorkspaceCards ?? {}).forEach((cardsList) => {
        Object.values(cardsList ?? {}).forEach((card) => {
            if (!card?.bank) {
                return;
            }
            feedKeys[card.bank] = true;
        });
    });
    return feedKeys;
};

Keying on the feed/bank identifier (the field that identifies the Chase connection) guarantees each distinct feed appears exactly once in the Add Cards list, which is the expected behavior described in the issue.

2. Confirm the consumer of buildFeedKeysWithAssignedCards iterates the returned record keys directly when rendering the feed options, so no further per-workspace expansion reintroduces duplicates downstream.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[aswin-s]

Note: This proposal is not a duplicate. It identifies a deeper root cause rather than the surface symptom.

Proposal

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

On web (Windows/macOS Chrome/Safari), when an admin opens a workspace and navigates to Company Cards → Add Cards, the "From other workspaces" section shows multiple duplicate Chase feed rows even though only one Chase feed truly exists across the admin's other workspaces. Expected behavior: a single row should appear per distinct Chase feed available from another workspace.

What is the root cause of that problem?

In src/hooks/useOtherFeedsForFeedSelector.tsx the "other workspaces" list is built from getVisibleCompanyCardFeedsForSelector (src/libs/CardFeedUtils.ts:655), which deduplicates only by the composite id `${fundID}_${feed}` (line 701–705). When the same physical Chase login has been re-authenticated from different workspaces, each re-auth produced a distinct workspace-scoped fundID for the same feed (oauth.chase.*), so every one of those {fundID}_oauth.chase.* rows survives the seenFeedIDs check and is pushed into visibleFeeds. useOtherFeedsForFeedSelector.tsx:61-73 only filters out feeds already linked to the current policy (linkedPolicyIDs match) or already present in the current policy's companyCardFeeds map — it does not collapse multiple foreign-policy rows that represent the same Chase institution, so all of them render under "From other workspaces".

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

1. src/hooks/useOtherFeedsForFeedSelector.tsx (around lines 57–113, inside getOtherFeeds): after the existing skip checks, dedupe the otherPolicyFeeds accumulator by a stable identity key — for OAuth/Plaid feeds this should be (feed type, domainName, institution/plaidUrl) rather than fundID, so multiple ${fundID}_oauth.chase.* entries pointing at the same Chase account collapse into one visible row.
2. Keep the first-seen row (preferring one with a resolved linkedPolicy name for the alternateText) and drop subsequent duplicates; use a local Set keyed on the identity above, similar to the seenFeedIDs pattern already used in CardFeedUtils.ts:664.
3. src/libs/CardFeedUtils.ts:655-718 (getVisibleCompanyCardFeedsForSelector): extend the dedup so callers that don't apply extra filtering (e.g. the selector's own list) also see one row per distinct institution — expose an optional identity function or make the collapse the default for OAuth Chase (oauth.chase.*) feeds.
4. src/pages/workspace/companyCards/WorkspaceCompanyCardFeedSelectorPage.tsx:184-208: no logic change needed once useOtherFeedsForFeedSelector returns deduped items; verify the RBR/alternateText still surfaces meaningfully after collapsing.
5. Add a unit test in the corresponding CardFeedUtils/useOtherFeedsForFeedSelector test file covering: same feed name across multiple fundIDs under the same admin domain must produce exactly one "other workspaces" row.

What alternative solutions did you explore? (Optional)

Fix the upstream re-authentication flow (RefreshCardFeedConnectionPage / BankConnection) to update the existing Chase feed instead of creating a workspace-scoped duplicate on OAuth re-connect; more correct long-term but requires backend coordination and doesn't help admins already carrying duplicate feed records.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 13:41:47 UTC.

Proposal

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

On the workspace Company Cards → Add Cards feed selector, the "From other workspaces" section renders the same bank (e.g. Chase) as several visually identical rows, even though only one such feed is actually available. The admin can't tell the rows apart or know which one to pick.

What is the root cause of that problem?

The "From other workspaces" list is built by useOtherFeedsForFeedSelector, which maps every entry returned by getVisibleCompanyCardFeedsForSelector into a row:

App/src/hooks/useOtherFeedsForFeedSelector.tsx

Lines 57 to 110 in b502674

	const getOtherFeeds = () => {
	const otherPolicyFeeds: CardFeedListItem[] = [];
	// `policyID` is stable for this hook invocation, so uppercase it once instead of per feed/linked-policy evaluation.
	const upperPolicyID = policyID.toUpperCase();
	for (const feed of visibleFeeds) {
	// Feeds linked to the active policy are shown as available feeds, not under "From other workspaces".
	// Linked policy IDs can differ in casing, so compare case-insensitively (matches the Expensify-card path).
	if (feed?.linkedPolicyIDs?.filter(Boolean).some((linkedPolicyID) => linkedPolicyID.toUpperCase() === upperPolicyID)) {
	continue;
	}
	// Skip feeds already present in the active policy's available list to avoid duplicate rows across the two lists.
	// `companyCardFeeds` is keyed at runtime by the domain-ID-suffixed feed value (`${feed}${separator}${fundID}`),
	// so a membership check on that value avoids an unsafe assertion to the narrower `CompanyCardFeedWithNumber` key type.
	const feedValueForActivePolicy = getCardFeedWithDomainID(feed.feed, Number(feed.fundID));
	if (companyCardFeeds && feedValueForActivePolicy in companyCardFeeds) {
	continue;
	}
	const feedName = feed.feed;
	const plaidUrl = getPlaidInstitutionIconUrl(feedName);
	// Use the same fundID-aware domain lookup as the visibility logic (`getVisibleCompanyCardFeedsForSelector`)
	// so the domain email resolves even when the domains collection isn't keyed by fundID.
	const domain = getDomainByFundID(allDomains, Number(feed.fundID));
	const firstLinkedPolicyID = feed?.linkedPolicyIDs?.at(0);
	// POLICY collection entries are keyed by uppercase policy IDs, so we uppercase before indexing (matches the Expensify-card path).
	const linkedPolicy = firstLinkedPolicyID ? allPolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${firstLinkedPolicyID.toUpperCase()}`] : undefined;
	const domainName = domain?.email ? Str.extractEmailDomain(domain.email) : undefined;
	const shouldShowRBR = shouldShowRbrForFeedNameWithDomainID[feed.id];
	otherPolicyFeeds.push({
	value: feed.id as CompanyCardFeedWithDomainID,
	feed: feedName as CompanyCardFeedWithNumber,
	fundID: Number(feed.fundID),
	country: feed?.country,
	alternateText: domainName ?? linkedPolicy?.name ?? firstLinkedPolicyID,
	text: getCustomOrFormattedFeedName(translate, feedName, feed.name),
	keyForList: feed.id,
	isSelected: feed.id === selectedFeedName,
	brickRoadIndicator: shouldShowRBR ? CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR : undefined,
	canShowSeveralIndicators: shouldShowRBR,
	leftElement: plaidUrl ? (
	<PlaidCardFeedIcon
	plaidUrl={plaidUrl}
	style={styles.mr3}
	/>
	) : (
	<Icon
	src={getCardFeedIcon(feed.feed, illustrations, companyCardFeedIcons)}
	height={variables.cardIconHeight}
	width={variables.cardIconWidth}
	additionalStyles={[styles.mr3, styles.cardIcon]}
	/>
	),
	});
	}

getVisibleCompanyCardFeedsForSelector deduplicates feeds only by the exact ${fundID}_${feed} key:

App/src/libs/CardFeedUtils.ts

Lines 692 to 714 in b502674

	for (const [key, feedData] of Object.entries(getOriginalCompanyFeeds(cardFeeds, feedKeysWithCards, numericFundID))) {
	// `getOriginalCompanyFeeds` is keyed by `CardFeedWithNumber`, but `Object.entries` widens the key to
	// `string`. Narrow it back with a type guard instead of an unsafe `as` assertion.
	if (!isCardFeedWithNumber(key)) {
	continue;
	}
	const country = feedData && 'country' in feedData ? (feedData.country ?? '') : '';
	const linkedPolicyIDs = feedData && 'linkedPolicyIDs' in feedData ? feedData.linkedPolicyIDs : undefined;
	const feed = key;
	const id = `${fundID}_${feed}`;
	if (seenFeedIDs.has(id)) {
	continue;
	}
	seenFeedIDs.add(id);
	visibleFeeds.push({
	id,
	feed,
	country,
	fundID,
	linkedPolicyIDs,
	name: getCustomOrFormattedFeedName(translate, feed, cardFeeds?.settings?.companyCardNicknames?.[feed], false) ?? feed,
	});
	}

The problem is that a feed key is not the same thing as what the user sees. Two things collapse to one visible label:

1. A single bank can be stored under several numbered feed keys of the type `${CompanyCardFeed}${number}` (e.g. oauth.chase.com, oauth.chase.com2). getBankName resolves the label with a prefix startsWith match, so every one of them formats to the same display name "Chase":

App/src/libs/CardUtils.ts

Lines 725 to 745 in b502674

	function getBankName(feedType: CardFeedWithNumber | CardFeedWithDomainID): string {
	const cacheKey = feedType ?? '';
	const cached = getBankNameCache.get(cacheKey);
	if (cached !== undefined) {
	return cached;
	}
	let result: string;
	if (feedType?.includes(CONST.COMPANY_CARD.FEED_BANK_NAME.CSV)) {
	result = CONST.COMPANY_CARDS.CARD_TYPE.CSV;
	} else {
	const feedKey = feedNamesMappingKeysByLength.find((feed) => feedType?.startsWith(feed));
	result = feedKey ? feedNamesMapping[feedKey] : '';
	}
	if (getBankNameCache.size >= GET_BANK_NAME_CACHE_MAX_SIZE) {
	getBankNameCache.clear();
	}
	getBankNameCache.set(cacheKey, result);
	return result;
	}

2. Each such key produces a distinct ${fundID}_${feed} id, so the seenFeedIDs guard never collapses them — they all survive as separate rows.

The only thing that could distinguish these rows is the subtitle, but it is frequently empty:

alternateText: domainName ?? linkedPolicy?.name ?? firstLinkedPolicyID,

For a domain-level feed that hasn't been linked to any policy yet, linkedPolicyIDs is empty, and if the domain's email doesn't resolve via getDomainByFundID, domainName is undefined too. The result is multiple rows with the identical title "Chase" and an empty subtitle — indistinguishable duplicates.

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

Collapse rows the user genuinely cannot tell apart. In getOtherFeeds() inside useOtherFeedsForFeedSelector, track the display identity (text + alternateText) already pushed and skip redundant rows, so identical-looking Chase entries render once while genuinely distinct feeds (different subtitle) still show:

const getOtherFeeds = () => {
    const otherPolicyFeeds: CardFeedListItem[] = [];
    const seenDisplayIdentities = new Set<string>();
    const upperPolicyID = policyID.toUpperCase();
    for (const feed of visibleFeeds) {
        // ...existing linked-policy and companyCardFeeds skip checks...

        const text = getCustomOrFormattedFeedName(translate, feedName, feed.name);
        const alternateText = domainName ?? linkedPolicy?.name ?? firstLinkedPolicyID;

        // Two rows with the same title and the same subtitle are indistinguishable to the
        // admin and represent redundant options — keep only the first.
        const displayIdentity = `${text ?? ''}#${alternateText ?? ''}`;
        if (seenDisplayIdentities.has(displayIdentity)) {
            continue;
        }
        seenDisplayIdentities.add(displayIdentity);

        otherPolicyFeeds.push({ /* ...existing row... */ });
    }
    return otherPolicyFeeds;
};

This is a minimal, safe guard: it only merges rows that are literally identical on screen, so no genuinely distinct feed is hidden.

What alternative solutions did you explore? (Optional)

• Guarantee a distinguishing subtitle instead of hiding rows. Rather than collapsing duplicates, always give each "other workspace" row a non-empty subtitle by falling back to the feed's own domain/workspace identifier when domainName, linkedPolicy?.name, and firstLinkedPolicyID are all missing. This keeps every feed visible but makes them distinguishable. Preferable if product wants each real connection listed; can be combined with the primary dedup so only truly-identical rows collapse.
• Deduplicate at the source in getVisibleCompanyCardFeedsForSelector. Fold numbered feed-key variants of the same bank within one fundID into a single entry there. Rejected as the primary because that function feeds several consumers and changing its granularity risks regressions elsewhere; scoping the fix to the selector hook is lower risk.

Automated tests: add a unit test around useOtherFeedsForFeedSelector (or getVisibleCompanyCardFeedsForSelector) that seeds SHARED_NVP_PRIVATE_DOMAIN_MEMBER with multiple Chase feed keys that resolve to the same label and no resolvable subtitle, and asserts a single row is produced; and a companion case with distinct subtitles asserting both rows remain.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 14:25:22 UTC.

Proposal

What is the root cause of that problem?

This was reported on version 9.4.27-2, and that release line still builds the Company Cards "From other workspaces" list from the per-policy cardFeedsByPolicy map. useOtherFeedsForFeedSelector loops every policy bucket and pushes each feed into the selector, then gives the row a composite ${feedPolicyID}_${feed.id} key so the same feed remains a separate row under each policy bucket.

App/src/hooks/useOtherFeedsForFeedSelector.tsx

Lines 51 to 93 in ccff6bf

	const getOtherFeeds = () => {
	const otherPolicyFeeds: CardFeedListItem[] = [];
	for (const [feedPolicyID, cardFeeds] of Object.entries(cardFeedsByPolicy ?? {})) {
	for (const feed of cardFeeds) {
	if (feed?.linkedPolicyIDs?.includes(policyID)) {
	continue;
	}
	const feedName = feed.feed;
	const plaidUrl = getPlaidInstitutionIconUrl(feedName);
	const domain = allDomains?.[`${ONYXKEYS.COLLECTION.DOMAIN}${feed.fundID}`];
	const feedPolicy = allPolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${feed?.linkedPolicyIDs?.[0] ?? feedPolicyID}`];
	const domainName = domain?.email ? Str.extractEmailDomain(domain.email) : undefined;
	const shouldShowRBR = shouldShowRbrForFeedNameWithDomainID[feed.id];
	otherPolicyFeeds.push({
	value: feed.id as CompanyCardFeedWithDomainID,
	feed: feedName as CompanyCardFeedWithNumber,
	fundID: Number(feed.fundID),
	country: feed?.country,
	alternateText: domainName ?? feedPolicy?.name,
	text: getCustomOrFormattedFeedName(translate, feedName, feed.name),
	// Composite key so rows stay distinct if the same feed id appears under multiple policies
	keyForList: `${feedPolicyID}_${feed.id}`,
	isSelected: feed.id === selectedFeedName,
	brickRoadIndicator: shouldShowRBR ? CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR : undefined,
	canShowSeveralIndicators: shouldShowRBR,
	leftElement: plaidUrl ? (
	<PlaidCardFeedIcon
	plaidUrl={plaidUrl}
	style={styles.mr3}
	/>
	) : (
	<Icon
	src={getCardFeedIcon(feed.feed, illustrations, companyCardFeedIcons)}
	height={variables.cardIconHeight}
	width={variables.cardIconWidth}
	additionalStyles={[styles.mr3, styles.cardIcon]}
	/>
	),
	});
	}
	}
	return otherPolicyFeeds;

The duplicate feed entries come from getCardFeedsForDisplayPerPolicy: when a feed has multiple linkedPolicyIDs, the same feedEntry is intentionally indexed under each linked policy, and orphan feeds can also be indexed under every policy whose policyAccountID matches the feed fund. That is useful for policy-grouped lookups, but the selector flattened that grouped data without collapsing the repeated feed identity.

App/src/libs/CardFeedUtils.ts

Lines 597 to 625 in ccff6bf

	const validLinkedPolicyIDs = linkedPolicyIDs?.filter(Boolean);
	if (validLinkedPolicyIDs?.length) {
	// Index the feed under each linked policy so it appears for all of them
	for (const linkedPolicyID of validLinkedPolicyIDs) {
	(cardFeedsForDisplayPerPolicy[linkedPolicyID] ||= []).push(feedEntry);
	}
	} else if (preferredPolicy) {
	(cardFeedsForDisplayPerPolicy[preferredPolicy] ||= []).push(feedEntry);
	} else {
	// Orphan feed: no linkedPolicyIDs and no preferredPolicy.
	// Find policies whose policyAccountID matches the fundID so the feed
	// still appears under the correct workspace.
	const numericFundID = Number(fundID);
	const matchingPolicies = Object.values(policies ?? {}).filter((policy) => policy?.policyAccountID === numericFundID);
	if (matchingPolicies.length) {
	for (const policy of matchingPolicies) {
	if (policy?.id) {
	(cardFeedsForDisplayPerPolicy[policy.id] ||= []).push(feedEntry);
	}
	}
	} else {
	// Still store under empty key so the feed is not silently lost
	(cardFeedsForDisplayPerPolicy[''] ||= []).push(feedEntry);
	}
	}
	}
	}
	return cardFeedsForDisplayPerPolicy;

So one real Chase feed associated with multiple other workspaces can render as several identical "Chase CC's" rows in a new workspace, while the original workspace still shows a single feed in its own available-feed view. That also matches the issue note that staging could not reproduce this: the relevant selector path was already changed after the 9.4.27 line.

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

No additional App-side fix is needed on current main. PR #93928 already replaced the old per-policy flattening path with getVisibleCompanyCardFeedsForSelector, which enumerates visible company-card feeds directly and dedupes the visible feed list before useOtherFeedsForFeedSelector partitions the feed into the active-workspace list or the "From other workspaces" list.

App/src/libs/CardFeedUtils.ts

Lines 655 to 718 in 708e2da

	function getVisibleCompanyCardFeedsForSelector(
	allCardFeeds: OnyxCollection<CardFeeds>,
	translate: LocalizedTranslate,
	feedKeysWithCards: FeedKeysWithAssignedCards | undefined,
	policies: OnyxCollection<Policy>,
	domains: OnyxCollection<Domain>,
	currentUserAccountID: number,
	): CardFeedForDisplay[] {
	const visibleFeeds: CardFeedForDisplay[] = [];
	const seenFeedIDs = new Set<string>();
	// Precompute the fundIDs (policyAccountIDs) backed by non-deleted policies the user can administer.
	// This avoids re-scanning every policy for each domain entry (was O(domains × policies)).
	const adminPolicyFundIDs = new Set<number>();
	for (const policy of Object.values(policies ?? {})) {
	if (policy?.policyAccountID === undefined || !isPolicyAdmin(policy) || policy.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	continue;
	}
	adminPolicyFundIDs.add(policy.policyAccountID);
	}
	for (const [domainKey, cardFeeds] of Object.entries(allCardFeeds ?? {})) {
	// sharedNVP_private_domain_member_123456 -> 123456
	const fundID = domainKey.split('_').at(-1);
	if (!fundID) {
	continue;
	}
	const numericFundID = Number(fundID);
	// Visibility: the user must be an admin of the feed's domain or of a policy backed by this fund.
	const domain = getDomainByFundID(domains, numericFundID);
	const isDomainAdmin = isAdminSelector(currentUserAccountID)(domain);
	const isWorkspaceAdmin = adminPolicyFundIDs.has(numericFundID);
	if (!isDomainAdmin && !isWorkspaceAdmin) {
	continue;
	}
	for (const [key, feedData] of Object.entries(getOriginalCompanyFeeds(cardFeeds, feedKeysWithCards, numericFundID))) {
	// `getOriginalCompanyFeeds` is keyed by `CardFeedWithNumber`, but `Object.entries` widens the key to
	// `string`. Narrow it back with a type guard instead of an unsafe `as` assertion.
	if (!isCardFeedWithNumber(key)) {
	continue;
	}
	const country = feedData && 'country' in feedData ? (feedData.country ?? '') : '';
	const linkedPolicyIDs = feedData && 'linkedPolicyIDs' in feedData ? feedData.linkedPolicyIDs : undefined;
	const feed = key;
	const id = `${fundID}_${feed}`;
	if (seenFeedIDs.has(id)) {
	continue;
	}
	seenFeedIDs.add(id);
	visibleFeeds.push({
	id,
	feed,
	country,
	fundID,
	linkedPolicyIDs,
	name: getCustomOrFormattedFeedName(translate, feed, cardFeeds?.settings?.companyCardNicknames?.[feed], false) ?? feed,
	});
	}
	}
	return visibleFeeds;
	}

App/src/hooks/useOtherFeedsForFeedSelector.tsx

Lines 55 to 113 in 708e2da

	const visibleFeeds = getVisibleCompanyCardFeedsForSelector(allFeeds, translate, feedKeysWithCards, allPolicies, allDomains, currentUserAccountID);
	const getOtherFeeds = () => {
	const otherPolicyFeeds: CardFeedListItem[] = [];
	// `policyID` is stable for this hook invocation, so uppercase it once instead of per feed/linked-policy evaluation.
	const upperPolicyID = policyID.toUpperCase();
	for (const feed of visibleFeeds) {
	// Feeds linked to the active policy are shown as available feeds, not under "From other workspaces".
	// Linked policy IDs can differ in casing, so compare case-insensitively (matches the Expensify-card path).
	if (feed?.linkedPolicyIDs?.filter(Boolean).some((linkedPolicyID) => linkedPolicyID.toUpperCase() === upperPolicyID)) {
	continue;
	}
	// Skip feeds already present in the active policy's available list to avoid duplicate rows across the two lists.
	// `companyCardFeeds` is keyed at runtime by the domain-ID-suffixed feed value (`${feed}${separator}${fundID}`),
	// so a membership check on that value avoids an unsafe assertion to the narrower `CompanyCardFeedWithNumber` key type.
	const feedValueForActivePolicy = getCardFeedWithDomainID(feed.feed, Number(feed.fundID));
	if (companyCardFeeds && feedValueForActivePolicy in companyCardFeeds) {
	continue;
	}
	const feedName = feed.feed;
	const plaidUrl = getPlaidInstitutionIconUrl(feedName);
	// Use the same fundID-aware domain lookup as the visibility logic (`getVisibleCompanyCardFeedsForSelector`)
	// so the domain email resolves even when the domains collection isn't keyed by fundID.
	const domain = getDomainByFundID(allDomains, Number(feed.fundID));
	const firstLinkedPolicyID = feed?.linkedPolicyIDs?.at(0);
	// POLICY collection entries are keyed by uppercase policy IDs, so we uppercase before indexing (matches the Expensify-card path).
	const linkedPolicy = firstLinkedPolicyID ? allPolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${firstLinkedPolicyID.toUpperCase()}`] : undefined;
	const domainName = domain?.email ? Str.extractEmailDomain(domain.email) : undefined;
	const shouldShowRBR = shouldShowRbrForFeedNameWithDomainID[feed.id];
	otherPolicyFeeds.push({
	value: feed.id as CompanyCardFeedWithDomainID,
	feed: feedName as CompanyCardFeedWithNumber,
	fundID: Number(feed.fundID),
	country: feed?.country,
	alternateText: domainName ?? linkedPolicy?.name ?? firstLinkedPolicyID,
	text: getCustomOrFormattedFeedName(translate, feedName, feed.name),
	keyForList: feed.id,
	isSelected: feed.id === selectedFeedName,
	brickRoadIndicator: shouldShowRBR ? CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR : undefined,
	canShowSeveralIndicators: shouldShowRBR,
	leftElement: plaidUrl ? (
	<PlaidCardFeedIcon
	plaidUrl={plaidUrl}
	style={styles.mr3}
	/>
	) : (
	<Icon
	src={getCardFeedIcon(feed.feed, illustrations, companyCardFeedIcons)}
	height={variables.cardIconHeight}
	width={variables.cardIconWidth}
	additionalStyles={[styles.mr3, styles.cardIcon]}
	/>
	),
	});
	}
	return otherPolicyFeeds;
	};
	return getOtherFeeds();

That change is present in 9.4.28-0-staging and not in the 9.4.27 staging tags, which explains why the customer could see the issue on 9.4.27-2 while QA could not reproduce it in staging. The right action is to let #93928 ride to production, or cherry-pick that PR to the active production branch if this needs to be fixed before the normal deploy.

Test coverage:

• #93928 added coverage that getVisibleCompanyCardFeedsForSelector enumerates a feed once when the user can see it through a backed policy/domain and when the feed has multiple linked policy IDs.
• The hook tests now verify that the selector consumes the already-deduped visible-feed output, excludes feeds linked to or already present in the active policy, and keeps feed.id as the stable row key.
• Manually verify on 9.4.28+: use a Chase feed visible from multiple workspaces, open Company Cards > Add cards in a workspace that is not linked to that feed, and confirm the "From other workspaces" section shows one Chase row.

App/tests/unit/CardFeedUtilsTest.ts

Lines 570 to 607 in 708e2da

	it('enumerates a feed once when the user is an admin of a policy backed by the fund (no linkedPolicyIDs)', () => {
	const cardFeeds = createCompanyCardFeeds({[cardFeedAmericaExpressMock]: {}});
	const policies: OnyxCollection<Policy> = {policy_WS: createTestPolicy({id: 'WS', policyAccountID: fundID})};
	const result = getVisibleCompanyCardFeedsForSelector(cardFeeds, translateLocal, undefined, policies, {}, currentUserAccountID);
	expect(result).toHaveLength(1);
	expect(result.at(0)?.id).toBe('1234_oauth.americanexpressfdx.com 1001');
	});
	it('enumerates a feed once when the user is a domain admin for the fund', () => {
	const cardFeeds = createCompanyCardFeeds({[cardFeedAmericaExpressMock]: {}});
	const domains: OnyxCollection<Domain> = {[`domain_${fundID}`]: createAdminDomain(fundID, currentUserAccountID)};
	const result = getVisibleCompanyCardFeedsForSelector(cardFeeds, translateLocal, undefined, {}, domains, currentUserAccountID);
	expect(result).toHaveLength(1);
	expect(result.at(0)?.id).toBe('1234_oauth.americanexpressfdx.com 1001');
	});
	it('excludes feeds when the user is neither a domain admin nor a workspace admin for the fund', () => {
	const cardFeeds = createCompanyCardFeeds({[cardFeedAmericaExpressMock]: {}});
	const policies: OnyxCollection<Policy> = {policy_OTHER: createTestPolicy({id: 'OTHER', policyAccountID: 9999})};
	const result = getVisibleCompanyCardFeedsForSelector(cardFeeds, translateLocal, undefined, policies, {}, currentUserAccountID);
	expect(result).toHaveLength(0);
	});
	it('enumerates a feed with multiple linkedPolicyIDs exactly once (no per-policy duplication)', () => {
	const cardFeeds = createCompanyCardFeeds({[cardFeedAmericaExpressMock]: {linkedPolicyIDs: ['WS', 'WS2', 'WS3']}});
	const policies: OnyxCollection<Policy> = {policy_WS: createTestPolicy({id: 'WS', policyAccountID: fundID})};
	const result = getVisibleCompanyCardFeedsForSelector(cardFeeds, translateLocal, undefined, policies, {}, currentUserAccountID);
	expect(result).toHaveLength(1);
	expect(result.at(0)?.linkedPolicyIDs).toEqual(['WS', 'WS2', 'WS3']);
	});

App/tests/unit/hooks/useOtherFeedsForFeedSelector.test.tsx

Lines 120 to 184 in 708e2da

	it('should exclude feeds already linked to the current policy', () => {
	mockVisibleFeeds([
	{
	id: '999_oauth.chase.com',
	feed: 'oauth.chase.com',
	fundID: '999',
	name: 'Chase feed',
	linkedPolicyIDs: [currentPolicyID],
	country: 'US',
	},
	]);
	const {result} = renderHook(() => useOtherFeedsForFeedSelector(currentPolicyID));
	expect(result.current).toHaveLength(0);
	});
	it('should exclude feeds already present in the active policy available list', () => {
	// Build the key the same way production does (`${feed}${separator}${fundID}`) via a computed property name,
	// which keeps the dotted feed key out of a string literal and avoids a naming-convention violation.
	const activePolicyFeedKey = `oauth.chase.com${CONST.COMPANY_CARD.FEED_KEY_SEPARATOR}999`;
	(useCompanyCards as jest.Mock).mockReturnValue({feedName: undefined, companyCardFeeds: {[activePolicyFeedKey]: {feed: 'oauth.chase.com'}}});
	mockVisibleFeeds([
	{
	id: '999_oauth.chase.com',
	feed: 'oauth.chase.com',
	fundID: '999',
	name: 'Chase feed',
	linkedPolicyIDs: ['policy_unrelated'],
	country: 'US',
	},
	]);
	const {result} = renderHook(() => useOtherFeedsForFeedSelector(currentPolicyID));
	expect(result.current).toHaveLength(0);
	});
	it('should include feeds that are not linked to the current policy', () => {
	mockVisibleFeeds([
	{
	id: '999_oauth.chase.com',
	feed: 'oauth.chase.com',
	fundID: '999',
	name: 'Chase feed',
	linkedPolicyIDs: ['policy_unrelated'],
	country: 'US',
	},
	]);
	const {result} = renderHook(() => useOtherFeedsForFeedSelector(currentPolicyID));
	expect(result.current).toHaveLength(1);
	// Use toMatchObject so Jest does not deep-compare leftElement (React nodes use private fields and break toEqual).
	expect(result.current.at(0)).toMatchObject({
	value: '999_oauth.chase.com',
	feed: 'oauth.chase.com',
	fundID: 999,
	country: 'US',
	// Stable, deduped key: feed.id is unique per feed (no per-policy composite).
	keyForList: '999_oauth.chase.com',
	isSelected: false,
	});
	expect(React.isValidElement(result.current.at(0)?.leftElement)).toBe(true);
	});

What alternative solutions did you explore? (Optional)

Adding a second dedupe layer to the current-main selector by OAuth/Plaid credentials would be riskier than needed for this issue. It would address a different, unproven data shape and could hide legitimately distinct same-bank connections. The version evidence points to the old per-policy flattening bug, and that exact path has already been replaced by #93928.