[$250] [Exploratory] Workspace Setting - Nothing happened when attempt to add work email in company card

[jponikarchuk]

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: v9.3.74-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90528
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 / Chrome, iPhone 13 / iOS 26.5, Samsung Galaxy A52 / Android 14
App Component: Workspace Settings

Action Performed:

Preconditions

• Logged in to existing gmail account that already add mock bank company cards in workspace but hasn't assigned to that account yet

Steps:

1. Navigate to company card in workspace
2. Click add card
3. Choose any mock bank card
4. fill the work email field
5. Click save

Expected Result:

Clicking "save" should respond something like if the work email is valid, user can navigate to the next step. Or if the work email is invalid, there should be an error occurred

Actual Result:

Nothing happened when attempt to add work email in company card

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022064688933652170015
• Upwork Job ID: 2064688933652170015
• Last Price Increase: 2026-06-17

Issue Owner

Current Issue Owner: @KJ21-ENG

[MelvinBot]

Issue Analysis

Root Cause (medium confidence): In the "Assign card" flow, the cardholder step (AssigneeStep.tsx) has no Save/Next button — you advance by tapping a row in the search results. When you type a work email and the results list renders zero rows, there is nothing to tap and no error is shown, so it looks like "nothing happens" when you press save.

The list goes empty deterministically here:

// AssigneeStep.tsx:182-201
if (debouncedSearchTerm && areOptionsInitialized) {
    /* build options incl. "user to invite" row */
} else if (debouncedSearchTerm) {
    assignees = [];   // <-- nothing to tap
}

areOptionsInitialized only becomes true after the options are initialized, which is gated on didScreenTransitionEnd (shouldInitialize), set by the screen's onEntryTransitionEnd callback (AssigneeStep.tsx:65-72, 231). If that callback doesn't fire on this navigation path, options never initialize, the list stays empty, and the only feedback is a silent loading placeholder.

Recommended Fix: In AssigneeStep, when debouncedSearchTerm is set but areOptionsInitialized is still false, surface the loading/placeholder state and the "user to invite" row reliably — and verify onEntryTransitionEnd actually fires in the card‑first flow so didScreenTransitionEnd flips to true. The user must always get either a tappable row or a visible error for a typed email; never a dead-end.

Investigation details & alternative causes considered

Flow: The card is chosen before the assignee — tapping a card on the company cards page sets cardToAssign.encryptedCardNumber and navigates to AssigneeStep (useAssignCard.ts). The "work email field" in the report is the SelectionList search input on AssigneeStep (label: "Name, email or phone number"). submit runs via onSelectRow, so it never fires if no row renders.

Alternative cause — userToInvite suppressed: canCreateOptimisticPersonalDetailOption returns false (dropping the invite row) when any recent report / personal-detail option already matches. For a genuinely new email these are normally empty, so this only bites in narrower data conditions — less likely to be the universal cause, but worth checking against the repro account's data.

No error path: headerMessage (AssigneeStep.tsx:208-216) only renders when the list is empty and the email format is invalid; a valid-but-unresolved email yields no actionable feedback.

Why medium confidence: This is client-side React state — backend logs won't confirm it. The exact trigger (transition callback not firing vs. options never initializing on this specific navigation path) needs a device/React-DevTools repro using the reporter's preconditions (mock bank cards already added, not yet assigned). The single visible commit on this checkout is a groups-selector SelectionList/selector-hook refactor (#92376), which touches exactly this area and is a plausible regression source — but the shallow clone prevented confirming via git blame.

PR #90528 (referenced as the regression-testing source) only relabels a button in the unrelated add‑feed DetailsStep and is not the cause.

Suggested verification: Reproduce with React DevTools and watch didScreenTransitionEnd / areOptionsInitialized on AssigneeStep while typing a new work email; confirm whether the invite row ever renders.

---

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

[melvin-bot]

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

[wildan-m]

Proposal

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

In the Workspace → Company Cards → Add card flow, a public-domain user (e.g. signed in with a gmail address) is sent to the "Add work email" step. After filling the work email and clicking Save, nothing happens — there is no error message, no navigation forward, and no visible feedback at all.

What is the root cause of that problem?

The handler that processes the Save click lives here:

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

Lines 61 to 94 in 2273f92

	const handleSubmit = (values: FormOnyxValues<typeof ONYXKEYS.FORMS.ADD_WORK_EMAIL_FORM>) => {
	const submittedEmail = values[INPUT_IDS.EMAIL].trim();
	const existingLoginKey = Object.keys(loginList ?? {}).find((login) => login.toLowerCase() === submittedEmail.toLowerCase());
	const isExistingLoginValidated = existingLoginKey ? !!loginList?.[existingLoginKey]?.validatedDate : false;
	if (existingLoginKey) {
	if (!isExistingLoginValidated) {
	setEmail(submittedEmail);
	Navigation.navigate(ROUTES.WORKSPACE_COMPANY_CARD_VERIFY_WORK_EMAIL.getRoute(policyID, feed));
	return;
	}
	setContactMethodAsDefault(currentUserPersonalDetails, existingLoginKey, formatPhoneNumber, undefined, true, '');
	if (!feedInfo) {
	setEmail(submittedEmail);
	return;
	}
	setLoading(true);
	const feedValue = getCardFeedWithDomainID(feedInfo.feed, feedInfo.fundID) as CompanyCardFeedWithDomainID;
	linkCardFeedToPolicy(Number(feedInfo.fundID), policyID, CONST.COMPANY_CARD.LINK_FEED_TYPE.COMPANY_CARD, feedInfo?.country, feedInfo.feed as CompanyCardFeedWithNumber)
	.then(() => {
	updateSelectedFeed(feedValue, policyID);
	Navigation.closeRHPFlow();
	})
	.catch((error: TranslationPaths) => {
	addErrorMessage({}, INPUT_IDS.EMAIL, translate(error));
	})
	.finally(() => {
	setLoading(false);
	});
	} else {
	AddWorkEmail(submittedEmail);
	}
	setEmail(submittedEmail);
	};

Inside handleSubmit, when the submitted email is already in loginList and already validated (existingLoginKey set, isExistingLoginValidated === true), the code calls setContactMethodAsDefault(...) and then performs this guard:

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

Lines 73 to 76 in 2273f92

	if (!feedInfo) {
	setEmail(submittedEmail);
	return;
	}

If feedInfo is undefined the handler does setEmail(submittedEmail); return; and exits silently — no navigation, no error, no loading state. Because the email is validated, the fallback useEffect at the bottom of the component also early-returns on isWorkEmailValidated, so it never navigates either:

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

Lines 96 to 101 in 2273f92

	useEffect(() => {
	if (!email || !primaryContactMethod || primaryContactMethod.toLowerCase() !== email.toLowerCase() || isWorkEmailValidated) {
	return;
	}
	Navigation.navigate(ROUTES.WORKSPACE_COMPANY_CARD_VERIFY_WORK_EMAIL.getRoute(policyID, feed));
	}, [primaryContactMethod, email, policyID, feed, isWorkEmailValidated]);

In the reported repro, feedInfo is reliably undefined. The lookup comes from useCardFeedsForActivePolicies, which builds its data from ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER:

App/src/hooks/useCardFeedsForActivePolicies.ts

Lines 24 to 38 in 2273f92

	const useCardFeedsForActivePolicies = () => {
	const {translate} = useLocalize();
	const [allFeeds] = useOnyx(ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER);
	const feedKeysWithCards = useFeedKeysWithAssignedCards();
	const eligiblePoliciesSelector = useEligiblePoliciesSelector();
	const [eligiblePoliciesIDsArray] = useOnyx(ONYXKEYS.COLLECTION.POLICY, {
	selector: eligiblePoliciesSelector,
	});
	const allCardFeedsByPolicy = getCardFeedsForDisplayPerPolicy(allFeeds, translate, feedKeysWithCards);
	const eligiblePolicyIdsSet = new Set(eligiblePoliciesIDsArray ?? []);
	const cardFeedsByPolicy = Object.fromEntries(Object.entries(allCardFeedsByPolicy).filter(([policyID]) => eligiblePolicyIdsSet.has(policyID)));
	return {cardFeedsByPolicy};
	};

For a user whose current primary login is a public-domain email (gmail/yahoo/etc.), SHARED_NVP_PRIVATE_DOMAIN_MEMBER does not yet contain the card-feed shape this hook expects for the workspace's mock-bank feed, so getFeedInfo(feed, cardFeedsByPolicy) returns undefined:

App/src/libs/CardFeedUtils.ts

Lines 606 to 616 in 2273f92

	function getFeedInfo(feedId: string, cardFeedsByPolicy?: Record<string, CardFeedForDisplay[]>): CardFeedForDisplay | undefined {
	if (!feedId || !cardFeedsByPolicy) {
	return undefined;
	}
	for (const cardFeeds of Object.values(cardFeedsByPolicy)) {
	const found = cardFeeds.find((item) => item.id === feedId);
	if (found) {
	return found;
	}
	}
	return undefined;

So whenever the user types in a previously-validated work email on this screen — which is the case any time they re-enter the flow after having validated that email even once before — they hit the silent-return branch and the Save button looks broken.

The other two outcomes in handleSubmit handle the user correctly: the unvalidated branch navigates to WORKSPACE_COMPANY_CARD_VERIFY_WORK_EMAIL and the brand-new-email branch calls AddWorkEmail and lets the useEffect navigate to the same verify screen once the primary contact method updates. Only the validated-without-feedInfo branch has no exit.

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

The "validated existing login, but feedInfo not yet available" branch in WorkspaceCompanyCardAddWorkEmailPage.handleSubmit should not silently return. It should navigate the user to WORKSPACE_COMPANY_CARD_VERIFY_WORK_EMAIL, the same place the unvalidated branch already routes to.

That screen (WorkspaceVerifyWorkAccountPage) is designed to recover exactly this state:

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

Lines 46 to 75 in 2273f92

	const validateAccountAndMerge = (validateCode: string) => {
	getAccessiblePolicies(validateCode);
	};
	const onDismissError = () => {
	setFeedWithError(undefined);
	};
	useEffect(() => {
	if (!feedInfo) {
	return;
	}
	if (isWorkEmailValidated) {
	setLoading(true);
	const feedValue = getCardFeedWithDomainID(feedInfo.feed, feedInfo.fundID) as CompanyCardFeedWithDomainID;
	linkCardFeedToPolicy(Number(feedInfo.fundID), policyID, CONST.COMPANY_CARD.LINK_FEED_TYPE.COMPANY_CARD, feedInfo?.country, feedInfo.feed as CompanyCardFeedWithNumber)
	.then(() => {
	updateSelectedFeed(feedValue, policyID);
	Navigation.closeRHPFlow();
	})
	.catch((error: TranslationPaths) => {
	setFeedWithError({
	error: getMicroSecondOnyxErrorWithTranslationKey(error),
	});
	})
	.finally(() => {
	setLoading(false);
	});
	}
	}, [feed, feedInfo, isWorkEmailValidated, policyID]);

When the user submits a magic code there it calls getAccessiblePolicies(validateCode), which is the VALIDATE_USER_AND_GET_ACCESSIBLE_POLICIES API command that populates the private-domain feed data so feedInfo becomes available. Its own useEffect then automatically calls linkCardFeedToPolicy and closes the RHP, which is exactly the outcome the original validated branch was trying to reach.

Concretely, the fix is in handleSubmit: in the if (existingLoginKey) { ... if (!isExistingLoginValidated) ... } block, after setContactMethodAsDefault(...) is called, when the if (!feedInfo) guard is true we should set email, navigate to ROUTES.WORKSPACE_COMPANY_CARD_VERIFY_WORK_EMAIL.getRoute(policyID, feed), and return. This mirrors the unvalidated branch a few lines above and reuses the verify page's existing recovery logic, so the user always has a path forward and the Save button is no longer a no-op.

No other paths change. The linkCardFeedToPolicy happy path (when feedInfo is already present) is untouched, the unvalidated-email path is untouched, and the brand-new-email path (AddWorkEmail + useEffect) is untouched.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/90691-company-card-work-email-silent-save?expand=1

What alternative solutions did you explore? (Optional)

Two alternatives I considered and rejected:

1. Show an inline error message instead of navigating. This would unblock the visual silence but leaves the user stranded — they have nowhere to go to recover, since the only thing that populates feedInfo for this user is the magic-code/getAccessiblePolicies flow that lives on the verify page.

2. Call getAccessiblePolicies() (the non-validate variant) directly from this page and wait for cardFeedsByPolicy to repopulate, then call linkCardFeedToPolicy. This is possible but introduces an asynchronous wait and a new loading state on this page, duplicating the recovery logic that the verify page already implements. Reusing the verify page is the simpler, less invasive option and keeps the recovery logic in one place.