[$250] Assigning Expensify Card in One Workspace Automatically Adds User to Another Workspace

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number:
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: @CCKroetsch
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Have: Workspace A and Workspace B
2. As admin, assign an Expensify card to User A in Workspace A
3. Observe workspace memberships for User A

Expected Result:

User A should:
Only be added to and assigned a card in Workspace A

Actual Result:

User A is:
Automatically added to Workspace B as well

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/~022056460364304087373
• Upwork Job ID: 2056460364304087373
• Last Price Increase: 2026-06-08

[MelvinBot]

Issue Analysis

Confidence: Medium — frontend is confirmed clean; root cause is almost certainly backend, which is outside this repo's scope.

Root Cause: The frontend card assignment flow is correctly scoped to a single workspace (policyID). When an admin assigns an Expensify Card in Workspace A, the App sends only that workspace's policyID to the backend. No frontend code path exists that would add a user to Workspace B. The automatic cross-workspace membership addition must be a backend side effect — likely domain-level membership syncing triggered by the AssignCard / CreateExpensifyCard / CreateAdminIssuedVirtualCard backend command handlers.

Recommended Fix: This appears to be a backend/internal issue. A separate internal investigation is needed, specifically into the backend handlers for card assignment commands (AssignCard, CreateExpensifyCard, CreateAdminIssuedVirtualCard) to determine if they trigger domain-level workspace membership operations that auto-add users to all workspaces sharing the same domain.

Investigation details

Frontend card assignment flows examined:

1. Expensify Card issuance — Card.ts:1407-1492: Calls CREATE_EXPENSIFY_CARD (physical) or CREATE_ADMIN_ISSUED_VIRTUAL_CARD (virtual) with a single policyID and domainAccountID.

2. Company Card assignment — CompanyCards.ts:402-477: Calls ASSIGN_COMPANY_CARD with a single policyID. Optimistic data only touches REPORT_ACTIONS and ASSIGN_CARD loading state — does not modify any policy's employeeList.

3. Invite non-member flow — When the assignee is not already a workspace member, InviteNewMemberStep calls addMembersToWorkspace (Policy/Member.ts:950-991), which sends ADD_MEMBERS_TO_WORKSPACE with a single policyID. The optimistic data builder (Policy/Member.ts:815-944) constructs a single policyKey and only updates that policy's employeeList.

Why this points to the backend:

• Every frontend API call sends exactly one policyID — no iteration over workspaces occurs
• No optimistic Onyx update touches any policy other than the current one
• The domainAccountID parameter sent with card assignment suggests the backend operates at a domain level, which could affect multiple workspaces sharing the same domain
• If Workspace A and B are under the same domain, backend domain-level auto-join logic during card provisioning is the most likely culprit

Alternative explanations considered:

• Pusher/real-time updates pushing stale membership data → unlikely to add a member, would only reflect existing state
• Frontend bug in optimistic updates → ruled out, only one policy key is ever touched

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[KJ21-ENG]

Proposal

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

When an admin issues an Expensify Card from Workspace A, the selected employee can also be added to Workspace B. The card/member side effect should be scoped to the workspace where the admin started the issue-card flow.

What is the root cause of that problem?

The issue-card confirmation screen still knows the selected workspace policyID, and passes it into issueExpensifyCard() along with defaultFundID:

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

Lines 91 to 100 in eaaffe3

	const handleIssueCard = useCallback(() => {
	if (!policyID) {
	return;
	}
	if (AccountUtils.hasValidateCodeExtendedAccess(account)) {
	// Attempt to issue directly without magic code when user has extended access
	// If this fails, the effect above will redirect to the magic code page
	issueExpensifyCard(defaultFundID, policyID, isBetaEnabled(CONST.BETAS.EXPENSIFY_CARD_EU_UK) ? '' : CONST.COUNTRY.US, '', assigneeTimeZone, data);
	} else {

defaultFundID can intentionally resolve to a domain fund shared by multiple workspaces, not just the current workspace account ID:

App/src/hooks/useDefaultFundID.ts

Lines 17 to 69 in eaaffe3

	* Hook to get the default fundID for a given policyID. This is used to get the settings and cards for each of the feeds.
	* It will always return lastSelectedExpensifyCardFeed if it exists or fallback to the domainFundID or workspaceAccountID.
	*/
	function useDefaultFundID(policyID: string | undefined) {
	const workspaceAccountID = useWorkspaceAccountID(policyID);
	const [lastSelectedExpensifyCardFeed] = useOnyx(`${ONYXKEYS.COLLECTION.LAST_SELECTED_EXPENSIFY_CARD_FEED}${policyID}`);
	const [lastSelectedCardSettings] = useOnyx(`${ONYXKEYS.COLLECTION.PRIVATE_EXPENSIFY_CARD_SETTINGS}${lastSelectedExpensifyCardFeed}`);
	const lastSelectedSettings = getCardSettings(lastSelectedCardSettings);
	const getDomainFundID = useCallback(
	(cardSettings: OnyxCollection<ExpensifyCardSettings>) => {
	const eligibleEntries = Object.entries(cardSettings ?? {}).filter(
	([key, settings]) => !!settings && !key.includes(workspaceAccountID.toString()) && settings.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
	);
	if (policyID) {
	const preferredMatch = eligibleEntries.find(([, settings]) => getPreferredPolicyFromExpensifyCardSettings(settings)?.toUpperCase() === policyID.toUpperCase());
	if (preferredMatch) {
	return getFundIdFromSettingsKey(preferredMatch[0]);
	}
	const linkedMatch = eligibleEntries.find(([, settings]) => isPolicyIDInLinkedExpensifyCardPolicyList(getLinkedPolicyIDsFromExpensifyCardSettings(settings), policyID));
	if (linkedMatch) {
	return getFundIdFromSettingsKey(linkedMatch[0]);
	}
	}
	return getFundIdFromSettingsKey('');
	},
	[policyID, workspaceAccountID],
	);
	const [domainFundID] = useOnyx(
	ONYXKEYS.COLLECTION.PRIVATE_EXPENSIFY_CARD_SETTINGS,
	{
	selector: getDomainFundID,
	},
	[getDomainFundID],
	);
	const isFeedPendingDelete = lastSelectedCardSettings?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE;
	if (lastSelectedExpensifyCardFeed && lastSelectedSettings?.paymentBankAccountID && !isFeedPendingDelete) {
	return lastSelectedExpensifyCardFeed;
	}
	if (domainFundID) {
	return domainFundID;
	}
	if (workspaceAccountID) {
	return workspaceAccountID;
	}

Inside issueExpensifyCard(), the common request parameters include domainAccountID, but not policyID. The virtual-card request then adds policyID, while the physical-card CreateExpensifyCard request does not:

App/src/libs/actions/Card.ts

Lines 1455 to 1484 in eaaffe3

	const parameters = {
	assigneeEmail,
	limit,
	limitType,
	cardTitle,
	validateCode,
	domainAccountID,
	};
	if (cardType === CONST.EXPENSIFY_CARD.CARD_TYPE.PHYSICAL) {
	API.write(
	WRITE_COMMANDS.CREATE_EXPENSIFY_CARD,
	{...parameters, feedCountry},
	{
	optimisticData,
	successData,
	failureData,
	},
	);
	return;
	}
	// eslint-disable-next-line rulesdir/no-multiple-api-calls
	API.write(
	WRITE_COMMANDS.CREATE_ADMIN_ISSUED_VIRTUAL_CARD,
	{
	...parameters,
	policyID,
	validFrom: validFrom ? DateUtils.normalizeDateToStartOfDay(validFrom, timeZone) : undefined,
	validThru: validThru ? DateUtils.normalizeDateToEndOfDay(validThru, timeZone) : undefined,

So for physical Expensify Cards on a domain-backed feed, the backend receives only the shared domainAccountID/fund context and not the workspace policy that initiated the assignment. That can make the invite/card side effect apply against another linked workspace instead of being constrained to Workspace A. The API type already allows policyID on CreateExpensifyCardParams, but the physical-card request currently omits it:

App/src/libs/API/parameters/CreateExpensifyCardParams.ts

Lines 1 to 10 in eaaffe3

	type CreateExpensifyCardParams = {
	assigneeEmail: string;
	limit: number;
	limitType: string;
	cardTitle: string;
	feedCountry: string;
	domainAccountID: number;
	policyID?: string;
	validFrom?: string;
	validThru?: string;

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

Pass policyID in the physical CREATE_EXPENSIFY_CARD request as well, matching the virtual-card path.

Concretely, update issueExpensifyCard() so the physical branch calls:

API.write(
    WRITE_COMMANDS.CREATE_EXPENSIFY_CARD,
    {...parameters, policyID, feedCountry},
    ...
);

Keep the shared domainAccountID parameter so domain cards still issue against the correct fund, but also send the workspace-scoping policyID so backend membership/card assignment logic can add the employee only to the initiating workspace.

I would also add a focused unit/API-parameter test around issueExpensifyCard() covering both card types:

• physical card request includes domainAccountID, policyID, and feedCountry
• virtual card request includes domainAccountID, policyID, validFrom, and validThru
• neither path loses the selected workspace ID when defaultFundID is a domain fund shared by multiple policies

What alternative solutions did you explore? (Optional)

We could try to force useDefaultFundID() to return the workspace account ID during card issuance, but that would break the domain-card support added for shared Expensify Card feeds. The safer fix is to keep using the domain fund for the card program while passing policyID as the workspace scope for membership side effects.

[annaweber830]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-18 20:20:35 UTC.

Proposal

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

When an admin issues a physical Expensify Card to a user in Workspace A, the backend also adds that user to Workspace B — any sibling workspace sharing the same domain fund. This shouldn't happen: the assignment should be scoped to the workspace where the admin initiated the flow.

What is the root cause of that problem?

The regression was introduced in PR #61360 (commit 37a9aeb8385, "pass policyID for virtual card creation only"). That commit moved policyID out of the shared parameters object inside issueExpensifyCard() and added it back only in the virtual card branch. The physical branch never got it back.

In Card.ts L1455–1491:

// Lines 1455-1491
const parameters = {
    assigneeEmail,
    limit,
    limitType,
    cardTitle,
    validateCode,
    domainAccountID,
    // policyID is NOT here
};

if (cardType === CONST.EXPENSIFY_CARD.CARD_TYPE.PHYSICAL) {
    API.write(
        WRITE_COMMANDS.CREATE_EXPENSIFY_CARD,
        {...parameters, feedCountry},   // ← no policyID sent to backend
        ...
    );
    return;
}

API.write(
    WRITE_COMMANDS.CREATE_ADMIN_ISSUED_VIRTUAL_CARD,
    {
        ...parameters,
        policyID,   // ← virtual card correctly scopes to this workspace
        ...
    },
    ...
);

Without policyID, the CREATE_EXPENSIFY_CARD backend command only receives the shared domainAccountID. The backend resolves all workspaces attached to that domain fund and adds the assignee to them — including Workspace B. The virtual card path has always worked correctly because policyID tells the backend which single workspace to scope the membership side-effect to.

CreateExpensifyCardParams already declares policyID?: string (CreateExpensifyCardParams.ts) — the API contract accepts it. The frontend just isn't sending it.

What changes do you propose to make?

File: src/libs/actions/Card.ts

Add policyID to the physical card request (L1464–1472):

Current code:

if (cardType === CONST.EXPENSIFY_CARD.CARD_TYPE.PHYSICAL) {
    API.write(
        WRITE_COMMANDS.CREATE_EXPENSIFY_CARD,
        {...parameters, feedCountry},
        {
            optimisticData,
            successData,
            failureData,
        },
    );
    return;
}

Updated code:

if (cardType === CONST.EXPENSIFY_CARD.CARD_TYPE.PHYSICAL) {
    API.write(
        WRITE_COMMANDS.CREATE_EXPENSIFY_CARD,
        {...parameters, feedCountry, policyID},
        {
            optimisticData,
            successData,
            failureData,
        },
    );
    return;
}

One-word change. policyID is already in scope (it's a parameter of issueExpensifyCard()), and CreateExpensifyCardParams.policyID is already typed as string | undefined — no other files need changing.

[harryautomazione]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

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

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

When an admin issues an Expensify Card from Workspace A on a domain-backed Expensify Card account (Workspaces A and B both linked to the same domain fund), issueExpensifyCard() sends only the shared domainAccountID (the domain fund) to the backend for physical cards. The CREATE_EXPENSIFY_CARD request omits policyID entirely, while the virtual CREATE_ADMIN_ISSUED_VIRTUAL_CARD request includes it. Without policyID on the physical request, the backend has no workspace scope to constrain the assignment's membership side effect to, so the assignee ends up added to a sibling workspace that shares the domain fund (Workspace B) instead of being constrained to Workspace A.

The asymmetry is a regression from PR #61360 (commit 37a9aeb83859, 2025‑05‑07, titled "pass policyID for virtual card creation only"). That PR added policyID?: string to CreateExpensifyCardParams and — in the same change — removed policyID from the shared parameters object inside issueExpensifyCard(), re-introducing it only in the virtual branch's spread. The relevant code today:

App/src/libs/actions/Card.ts

Lines 1455 to 1492 in 12cd8e5

	const parameters = {
	assigneeEmail,
	limit,
	limitType,
	cardTitle,
	validateCode,
	domainAccountID,
	};
	if (cardType === CONST.EXPENSIFY_CARD.CARD_TYPE.PHYSICAL) {
	API.write(
	WRITE_COMMANDS.CREATE_EXPENSIFY_CARD,
	{...parameters, feedCountry},
	{
	optimisticData,
	successData,
	failureData,
	},
	);
	return;
	}
	// eslint-disable-next-line rulesdir/no-multiple-api-calls
	API.write(
	WRITE_COMMANDS.CREATE_ADMIN_ISSUED_VIRTUAL_CARD,
	{
	...parameters,
	policyID,
	validFrom: validFrom ? DateUtils.normalizeDateToStartOfDay(validFrom, timeZone) : undefined,
	validThru: validThru ? DateUtils.normalizeDateToEndOfDay(validThru, timeZone) : undefined,
	},
	{
	optimisticData,
	successData,
	failureData,
	},
	);
	}

CreateExpensifyCardParams still declares policyID?: string (the API contract on both sides accepts it — only the FE call site drops it for physical):

App/src/libs/API/parameters/CreateExpensifyCardParams.ts

Lines 1 to 11 in 12cd8e5

	type CreateExpensifyCardParams = {
	assigneeEmail: string;
	limit: number;
	limitType: string;
	cardTitle: string;
	feedCountry: string;
	domainAccountID: number;
	policyID?: string;
	validFrom?: string;
	validThru?: string;
	};

defaultFundID (passed in as domainAccountID) intentionally resolves to a domain fund — not the workspace account — whenever the Expensify Card account is shared across workspaces in the same domain, which is exactly the precondition for this bug. useDefaultFundID prefers the last‑selected feed, then the domain fund, and only falls back to the workspace account ID:

App/src/hooks/useDefaultFundID.ts

Lines 20 to 72 in 12cd8e5

	function useDefaultFundID(policyID: string | undefined) {
	const workspaceAccountID = useWorkspaceAccountID(policyID);
	const [lastSelectedExpensifyCardFeed] = useOnyx(`${ONYXKEYS.COLLECTION.LAST_SELECTED_EXPENSIFY_CARD_FEED}${policyID}`);
	const [lastSelectedCardSettings] = useOnyx(`${ONYXKEYS.COLLECTION.PRIVATE_EXPENSIFY_CARD_SETTINGS}${lastSelectedExpensifyCardFeed}`);
	const lastSelectedSettings = getCardSettings(lastSelectedCardSettings);
	const getDomainFundID = useCallback(
	(cardSettings: OnyxCollection<ExpensifyCardSettings>) => {
	const eligibleEntries = Object.entries(cardSettings ?? {}).filter(
	([key, settings]) => !!settings && !key.includes(workspaceAccountID.toString()) && settings.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
	);
	if (policyID) {
	const preferredMatch = eligibleEntries.find(([, settings]) => getPreferredPolicyFromExpensifyCardSettings(settings)?.toUpperCase() === policyID.toUpperCase());
	if (preferredMatch) {
	return getFundIdFromSettingsKey(preferredMatch[0]);
	}
	const linkedMatch = eligibleEntries.find(([, settings]) => isPolicyIDInLinkedExpensifyCardPolicyList(getLinkedPolicyIDsFromExpensifyCardSettings(settings), policyID));
	if (linkedMatch) {
	return getFundIdFromSettingsKey(linkedMatch[0]);
	}
	}
	return getFundIdFromSettingsKey('');
	},
	[policyID, workspaceAccountID],
	);
	const [domainFundID] = useOnyx(
	ONYXKEYS.COLLECTION.PRIVATE_EXPENSIFY_CARD_SETTINGS,
	{
	selector: getDomainFundID,
	},
	[getDomainFundID],
	);
	const isFeedPendingDelete = lastSelectedCardSettings?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE;
	if (lastSelectedExpensifyCardFeed && lastSelectedSettings?.paymentBankAccountID && !isFeedPendingDelete) {
	return lastSelectedExpensifyCardFeed;
	}
	if (domainFundID) {
	return domainFundID;
	}
	if (workspaceAccountID) {
	return workspaceAccountID;
	}
	return CONST.DEFAULT_NUMBER_ID;
	}

So for any admin issuing on a domain-backed card account, the physical request currently carries the assignee + the shared domain fund + zero workspace context, and the backend's membership-add resolves against the domain rather than the initiating workspace.

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

Restore the structural symmetry the regression PR broke — put policyID back in the shared parameters so it goes to both physical and virtual API.write calls. The type already permits it on both ends, and the original PR's fix (#61051: "You must be a domain admin to create the virtual card") was about adding policyID to the virtual call — it never required removing it from the shared object.

src/libs/actions/Card.ts

 const parameters = {
     assigneeEmail,
     limit,
     limitType,
     cardTitle,
     validateCode,
     domainAccountID,
+    policyID,
 };

And drop the now-redundant policyID from the virtual spread (parameters already carries it):

 API.write(
     WRITE_COMMANDS.CREATE_ADMIN_ISSUED_VIRTUAL_CARD,
     {
         ...parameters,
-        policyID,
         validFrom: validFrom ? DateUtils.normalizeDateToStartOfDay(validFrom, timeZone) : undefined,
         validThru: validThru ? DateUtils.normalizeDateToEndOfDay(validThru, timeZone) : undefined,
     },
     {
         optimisticData,
         successData,
         failureData,
     },
 );

The physical branch (line 1465-1473) needs no change — it already does {...parameters, feedCountry} and will now inherit policyID from parameters. PR #61360's original behavior (virtual call carries policyID) is preserved verbatim; we only stop dropping the same field for the physical call.

What alternative solutions did you explore? (Optional)

• Force useDefaultFundID() to always return the workspace account ID during issuance. Rejected — useDefaultFundID deliberately returns the domain fund for shared Expensify Card accounts so the card is issued against the correct funding source; overriding it would break domain-card support added in commit 629cbdc6ee68 ("fix company cards page not showing feeds for domain-based card account").
• Tighten useCardFeeds.tsx's shouldIncludeFeedPredicate to ignore linkedPolicyIDs (a sibling proposal on this thread). That predicate governs the Company Cards assign-card flow (WorkspaceCompanyCardsPage → useAssignCard → AssignCompanyCard), not the Expensify Card Issue New flow described in the repro. The reproduction path here is Workspace settings → Expensify Card → Issue card, which calls issueExpensifyCard() directly and never touches useCardFeeds/useAssignCard. Wrong surface for this issue.
• Suffix-style fix that adds policyID only in the physical spread (e.g. {...parameters, policyID, feedCountry}). Functionally equivalent, but less symmetric — leaves two call sites independently responsible for threading the workspace ID, which is exactly the shape that produced this regression in the first place. Putting policyID back in the shared parameters removes that footgun.