Option to add "New domain" is not displayed

[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: 9.3.0-5
Reproducible in staging?: Y
Reproducible in production?: Y
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: Applause Internal Team
Slack conversation (hyperlinked to channel name): #QA Channel

Action Performed:

1. Login with an account who has not claimed the domain associated with their private email
2. Navigate to the “Workspaces” tab
3. Click on the “New” button in the top right corner

Expected Result:

Option to add a new workspace or a new domain

Actual Result:

New Workspace button is displayed, but clicking it does not show the New Domain option.## 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

Recording.2197.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mhawryluk

[melvin-bot]

Triggered auto assignment to @twisterdotcom (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MobileMage]

Proposal

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

When a user with a private email domain (e.g., user@company.com) navigates to the Workspaces tab and clicks the "New" button, they only see the "New Workspace" option. The "New domain" option is not displayed, even though they should be able to claim and verify their email domain.

What is the root cause of that problem?

In src/pages/workspace/WorkspacesListPage.tsx:695, the shouldShowNewDomainButton prop is set to !!domains.length:

<WorkspacesListPageHeaderButton
    shouldShowNewWorkspaceButton={!isRestrictedPolicyCreation && (!!domains.length || !!workspaces.length)}
    shouldShowNewDomainButton={!!domains.length}  // <-- Bug: only true if user already has domains
/>

This condition only evaluates to true if the user already has claimed domains. Users with private email domains who haven't claimed any domain yet will have domains.length === 0, so the "New domain" option never appears for them.

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

The condition should also check if the user has a private email domain (i.e., not from a public domain like gmail.com). The account object is already available in the component (line 147) and contains isFromPublicDomain.

Diff:

 const headerButton = (
     <WorkspacesListPageHeaderButton
         shouldShowNewWorkspaceButton={!isRestrictedPolicyCreation && (!!domains.length || !!workspaces.length)}
-        shouldShowNewDomainButton={!!domains.length}
+        shouldShowNewDomainButton={!!domains.length || !account?.isFromPublicDomain}
     />
 );

This ensures:

• Users with existing domains see the option (existing behavior)
• Users with private email domains (who can claim their domain) also see the option

What alternative solutions did you explore? (Optional)

1. Always show the "New domain" option - Rejected because users on public domains (gmail.com, etc.) cannot claim domains, so showing them the option would lead to a confusing UX.

2. Check in AddDomainPage - The page could redirect public domain users, but it's better UX to not show the option at all if the user can't use it.

[annaweber830]

Proposal

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

On the Workspaces tab, clicking the top-right “New” button only shows “New workspace”, and does not show “New domain” for users who have not previously claimed any domains (e.g., users with a private email domain that isn’t claimed yet). This blocks users from starting the “claim a domain” flow from the expected entry point.

What is the root cause of that problem?

The visibility logic for the header menu in WorkspacesListPage only enables the “New domain” option when domains.length > 0. That means first-time domain claimers (who have domains.length === 0) can never see “New domain” in the header, even though the “add domain” route exists and is otherwise reachable.

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

Update the Workspaces header button logic so “New domain” is available even when there are zero existing domains, i.e., don’t gate the menu item purely on domains.length. Concretely:
Treat “New domain” as a generally available action on the Workspaces list (subject to any existing auth/validation checks handled by the destination flow).
Ensure the header can render a dropdown with both actions in the common case where users have workspaces but no domains yet.

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 693 to 696 in 3bf7f14

	<WorkspacesListPageHeaderButton
	shouldShowNewWorkspaceButton={!isRestrictedPolicyCreation && (!!domains.length || !!workspaces.length)}
	shouldShowNewDomainButton={!!domains.length}
	/>

<WorkspacesListPageHeaderButton
            shouldShowNewWorkspaceButton={!isRestrictedPolicyCreation && (!!domains.length || !!workspaces.length)}
            shouldShowNewDomainButton={!!domains.length || !!workspaces.length}
        />

What alternative solutions did you explore? (Optional)

[duckemiah]

Proposal

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

Users with work/company email addresses cannot see the "New domain" option when clicking the "New" button in the Workspaces tab. Only the "New Workspace" option appears, preventing them from claiming their company domain.

What is the root cause of that problem?

The visibility of the "New domain" button is controlled in src/pages/workspace/WorkspacesListPage.tsx at line 695:

shouldShowNewDomainButton={!!domains.length}

This checks if the user has existing domains. First-time users wanting to claim their domain have zero domains, so the button never shows for them.

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

Introduce a dedicated hook to determine domain eligibility based on the user's email type. This centralizes the logic and can be reused wherever domain access needs to be checked.

1. Add src/hooks/useCanAddDomain.ts:

import useOnyx from '@hooks/useOnyx';
import ONYXKEYS from '@src/ONYXKEYS';

function useCanAddDomain(): boolean {
    const [account] = useOnyx(ONYXKEYS.ACCOUNT, {canBeMissing: true});
    return account?.isFromPublicDomain === false;
}

export default useCanAddDomain;

2. Modify src/pages/workspace/WorkspacesListPage.tsx:

+ import useCanAddDomain from '@hooks/useCanAddDomain';

  function WorkspacesListPage() {
+     const canAddDomain = useCanAddDomain();

      const headerButton = (
          <WorkspacesListPageHeaderButton
              shouldShowNewWorkspaceButton={!isRestrictedPolicyCreation && (!!domains.length || !!workspaces.length)}
-             shouldShowNewDomainButton={!!domains.length}
+             shouldShowNewDomainButton={!!domains.length || canAddDomain}
          />
      );

3. Optionally update src/components/DomainsEmptyStateComponent.tsx to hide for public domain users:

+ import useCanAddDomain from '@hooks/useCanAddDomain';

  function DomainsEmptyStateComponent() {
+     const canAddDomain = useCanAddDomain();
+     if (!canAddDomain) {
+         return null;
+     }

What alternative solutions did you explore? (Optional)

1. Pass eligibility from parent component - Could thread isFromPublicDomain down from a parent, but this adds prop drilling and the hook pattern is cleaner.

2. Check in WorkspacesListPageHeaderButton directly - Moving the Onyx subscription into the button component would work, but violates separation of concerns since the parent should control visibility.

3. Modify DomainsEmptyStateComponent to always render the button - The empty state already has an "Enable" button, but relying solely on that is inconsistent with the header button UX pattern used elsewhere.

[abbasifaizan70]

Proposal

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

New Workspace button is displayed in the Workspaces tab, but clicking it does not show the New Domain option for users who have not claimed the domain associated with their private email.

What is the root cause of that problem?

The issue is in the WorkspacesListPage.tsx where the shouldShowNewDomainButton prop is passed to WorkspacesListPageHeaderButton. The current logic only shows the "New Domain" option if the user already has at least one claimed domain:

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 687 to 692 in 95e0df2

	const headerButton = (
	<WorkspacesListPageHeaderButton
	shouldShowNewWorkspaceButton={!isRestrictedPolicyCreation && (!!domains.length || !!workspaces.length)}
	shouldShowNewDomainButton={!!domains.length}
	/>
	);

The problem is shouldShowNewDomainButton={!!domains.length} - this evaluates to false when the user has zero domains, which prevents users with private email domains from seeing the option to claim their domain.

Looking at the WorkspacesListPageHeaderButton component, we can see the conditional logic:

App/src/pages/workspace/WorkspacesListPageHeaderButton.tsx

Lines 26 to 51 in 95e0df2

	if (shouldShowNewWorkspaceButton && shouldShowNewDomainButton) {
	return (
	<ButtonWithDropdownMenu
	success={false}
	onPress={() => {}}
	customText={translate('common.new')}
	options={[
	{
	value: 'workspace',
	text: translate('workspace.new.newWorkspace'),
	icon: icons.Building,
	onSelected: () => interceptAnonymousUser(() => Navigation.navigate(ROUTES.WORKSPACE_CONFIRMATION.getRoute(ROUTES.WORKSPACES_LIST.route))),
	},
	{
	value: 'domain',
	text: translate('domain.addDomain.newDomain'),
	icon: icons.Globe,
	onSelected: () => interceptAnonymousUser(() => Navigation.navigate(ROUTES.WORKSPACES_ADD_DOMAIN)),
	},
	]}
	isSplitButton={false}
	style={shouldUseNarrowLayout && [styles.flexGrow1, styles.mb3]}
	wrapperStyle={styles.flexGrow1}
	testID="dropdown-button-new"
	/>
	);

When shouldShowNewDomainButton is false, only the "New Workspace" button is shown instead of the dropdown menu with both options.

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

The fix should check if the user has a private email domain (not a public domain like gmail.com, outlook.com, etc.) and show the "New Domain" option accordingly. Users with private email domains should be able to claim their domain even if they haven't claimed any domains yet.

File: App/src/pages/workspace/WorkspacesListPage.tsx

1. Add import for isEmailPublicDomain:

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 63 to 64 in 95e0df2

	import {getDefaultWorkspaceAvatar} from '@libs/ReportUtils';
	import shouldRenderTransferOwnerButton from '@libs/shouldRenderTransferOwnerButton';

// After
import {isEmailPublicDomain} from '@libs/LoginUtils';
import {getDefaultWorkspaceAvatar} from '@libs/ReportUtils';
import shouldRenderTransferOwnerButton from '@libs/shouldRenderTransferOwnerButton';

2. Update the shouldShowNewDomainButton logic:

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 687 to 692 in 95e0df2

	const headerButton = (
	<WorkspacesListPageHeaderButton
	shouldShowNewWorkspaceButton={!isRestrictedPolicyCreation && (!!domains.length || !!workspaces.length)}
	shouldShowNewDomainButton={!!domains.length}
	/>
	);

// After
// Users with a private email domain should be able to see the "New Domain" option
// even if they haven't claimed any domains yet
const currentUserEmail = currentUserPersonalDetails?.login ?? '';
const hasPrivateEmailDomain = !!currentUserEmail && !isEmailPublicDomain(currentUserEmail);

const headerButton = (
    <WorkspacesListPageHeaderButton
        shouldShowNewWorkspaceButton={!isRestrictedPolicyCreation && (!!domains.length || !!workspaces.length)}
        shouldShowNewDomainButton={!!domains.length || hasPrivateEmailDomain}
    />
);

How the fix works:

1. We import the isEmailPublicDomain utility from @libs/LoginUtils which checks if an email belongs to a public domain (like gmail.com, yahoo.com, etc.)

2. We get the current user's email from currentUserPersonalDetails?.login

3. We calculate hasPrivateEmailDomain which is true if:

   • The user has an email, AND
   • The email is NOT from a public domain

4. We update shouldShowNewDomainButton to be true when:

   • The user already has domains (!!domains.length), OR
   • The user has a private email domain (hasPrivateEmailDomain)

[mhawryluk]

this is exactly what it was decided to be like when we implemented the feature (#76231 (comment)). the flow is accessible through the "Enable" button in the domain section security banner