[$250] Onboarding - Name and "Join existing policies" modals not shown when redirected from OD

[vincdargento]

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.49-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176677/test-cases/43685222
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: MacBook Air 15.7.4 Chrome
App Component: Other

Action Performed:

1. Navigate to staging.expensify.com.
2. Select the option "Manage my team (1-9)"
3. Enter a private domain email that is associated with existing accounts (e.g., xyz+anything@futebr.com)
4. Click "Get started for free", then "Join"
5. When redirected to the NewDot, verify that the first step of the onboarding flow displayed is the 'What is your name" modal
6. Verify that the next step asks the user if they want to "Join existing policies"

Expected Result:

'What is your name" and "Join existing policies" modals are shown, when user with a private domain account is redirected from OD to ND during onboarding

Actual Result:

'What is your name" and "Join existing policies" modals are not shown, when user with a private domain account is redirected from OD to ND during onboarding

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @stitesExpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022037296580589870031
• Upwork Job ID: 2037296580589870031
• Last Price Increase: 2026-04-16

[MelvinBot]

Proposal

What is the root cause of that problem?

When a private domain user is redirected from OldDot to NewDot during onboarding, the OnboardingGuard in OnboardingGuard.ts:104-113 calls getOnboardingInitialPath() to determine which onboarding screen to start on. This function checks account.hasAccessibleDomainPolicies to decide if the user should see the private domain flow (Personal Details → Private Domain → Workspaces).

The problem is that when the guard evaluates after the OD-to-ND transition completes, the account Onyx data may not yet include hasAccessibleDomainPolicies = true. In the guard, account is read from a module-level Onyx subscription (OnboardingGuard.ts:45-50), and it's passed to getOnboardingInitialPath as !!account?.hasAccessibleDomainPolicies (line 108). When account is undefined or doesn't yet have this field, hasAccessiblePolicies evaluates to false.

In OnboardingFlow.ts:133-138, the private domain branch is:

if (!isUserFromPublicDomain && hasAccessiblePolicies) {
    return ONBOARDING_PERSONAL_DETAILS;
}

With hasAccessiblePolicies = false, this branch is skipped. The function falls through to either the VSB/SMB paths (returning ONBOARDING_ACCOUNTING or ONBOARDING_EMPLOYEES) or the default ONBOARDING_ROOT (PURPOSE screen) at line 148. The user never sees Personal Details ("What is your name") or Workspaces ("Join existing policies").

The same issue exists in OnboardingModalNavigator.tsx:50-56, where initialRouteName defaults to PURPOSE unless account?.hasAccessibleDomainPolicies is truthy. Notably, the navigator already waits for account metadata to load (line 106), but the guard does not have this same check.

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

The OnboardingGuard should not calculate the onboarding route until account data is available. Currently, the guard checks context.isLoading but doesn't verify that the account Onyx data has actually been populated.

The fix should add a check in the guard's evaluate function (OnboardingGuard.ts:162-221): if account is undefined or null (meaning it hasn't been loaded from the server yet), treat it as a loading state and include it in the shouldSkipOnboarding conditions (returning ALLOW to defer the onboarding redirect until account data is available).

This mirrors what OnboardingModalNavigator already does — it returns null while isLoadingOnyxValue(accountMetadata) is true (line 106-108).

What alternative solutions did you explore? (Optional)

1. Server-side fix: Ensure hasAccessibleDomainPolicies is always populated in the OpenApp response for users transitioning from OD. However, this would only fix one manifestation — any other scenario where account data loads slowly would still be broken.

2. Saving onboarding state during OD signup: When the user selects "Manage my team" on OldDot and enters a private domain email, the server could set ONBOARDING_LAST_VISITED_PATH to the personal details route. This would be used by getOnboardingInitialPath at line 134 as a fallback. However, this requires backend changes and is more complex.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[twilight2294]

Proposal

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

When a private-domain user is redirected from OldDot to NewDot during onboarding, the "What is your name" (Personal Details) and "Join existing policies" (Workspaces) modals are never shown — the user lands directly in the app without completing the guided setup flow.

What is the root cause of that problem?

The issue is a logic error in the evaluate function of OnboardingGuard. The isInvitedOrGroupMember variable is computed as:

const isInvitedOrGroupMember = (!CONFIG.IS_HYBRID_APP && (hasNonPersonalPolicy || wasInvitedToNewDot)) ?? false;

For a private-domain user arriving from OldDot on web: !CONFIG.IS_HYBRID_APP is true, and hasNonPersonalPolicy is true (the domain has existing policies). So isInvitedOrGroupMember evaluates to true, which feeds into shouldSkipOnboarding becoming true. The guard then returns ALLOW and never redirects to the onboarding flow.

The routing logic in getOnboardingInitialPath() in OnboardingFlow is actually correct — it would route to PERSONAL_DETAILS for private-domain users with accessible policies. But that code is never reached because the guard short-circuits first.

The core flaw is that isInvitedOrGroupMember doesn't account for whether the user has actually completed the guided setup flow. A user who has non-personal policies but hasn't finished onboarding is incorrectly treated the same as one who has.

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

In OnboardingGuard, add a check for hasCompletedGuidedSetupFlow so that users who still need onboarding aren't skipped:

- const isInvitedOrGroupMember = (!CONFIG.IS_HYBRID_APP && (hasNonPersonalPolicy || wasInvitedToNewDot)) ?? false;
+ const isInvitedOrGroupMember = (!CONFIG.IS_HYBRID_APP && (hasNonPersonalPolicy || wasInvitedToNewDot) && onboarding?.hasCompletedGuidedSetupFlow !== false) ?? false;

This ensures:

• Users who haven't completed onboarding (hasCompletedGuidedSetupFlow === false): isInvitedOrGroupMember becomes false, the guard proceeds to the redirect logic, and they correctly see Personal Details → Private Domain → Workspaces.
• Users who have completed onboarding: existing skip behavior is preserved.
• Old/migrated accounts with empty onboarding data: hasCompletedGuidedSetupFlow won't be false, so the current behavior is unchanged.

What alternative solutions did you explore? (Optional)

The existing proposal suggests this is a timing/loading issue — that account.hasAccessibleDomainPolicies isn't populated yet when the guard runs, so adding a loading check would fix it. While that race condition may exist as a secondary issue, the primary root cause is the logic flaw in isInvitedOrGroupMember: even after all data is fully loaded, this condition will still skip onboarding for private-domain users who have non-personal policies but haven't completed the guided setup flow. Adding a loading guard alone would not fix this — once the data loads, the same incorrect skip would occur.

My fix is a single-line change that addresses the actual logic error, is consistent with how isOnboardingCompleted is already used elsewhere in the guard, and carries minimal regression risk.

[trasnake87]

Proposal

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

When a private domain user is redirected from OldDot to NewDot during onboarding, the "What is your name" and "Join existing policies" modals are not shown — the user lands directly on the home screen.

What is the root cause of that problem?

The isInvitedOrGroupMember condition in OnboardingGuard.ts:173 unconditionally skips onboarding for any non-HybridApp user who has a non-personal policy:

const isInvitedOrGroupMember = (!CONFIG.IS_HYBRID_APP && (hasNonPersonalPolicy || wasInvitedToNewDot)) ?? false;

When a private domain user signs up through OldDot ("Manage my team" → "Join"), the backend creates a policy membership before redirecting to NewDot. So when OpenApp returns, HAS_NON_PERSONAL_POLICY is true. The guard treats this user identically to an existing user who was invited to a workspace — it sets shouldSkipOnboarding = true at line 197 and returns ALLOW, bypassing the private domain onboarding flow (Personal Details → Workspaces) entirely.

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

In OnboardingGuard.ts, exclude users who need the private domain onboarding flow from the isInvitedOrGroupMember skip. These users have hasAccessibleDomainPolicies = true and isFromPublicDomain = false — they must still enter onboarding even though they already have a non-personal policy.

const needsPrivateDomainOnboarding = !account?.isFromPublicDomain && !!account?.hasAccessibleDomainPolicies;
// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
const isInvitedOrGroupMember = (!CONFIG.IS_HYBRID_APP && !needsPrivateDomainOnboarding && (hasNonPersonalPolicy || wasInvitedToNewDot)) ?? false;

This is safe because users who have already completed onboarding are caught earlier by the isOnboardingCompleted condition on line 190, so the change only affects users whose hasCompletedGuidedSetupFlow is false — exactly the OD-redirect scenario described in the issue.

What alternative solutions did you explore? (Optional)

Gating isInvitedOrGroupMember on isOnboardingCompleted was considered, but that would make the entire condition redundant (since isOnboardingCompleted is already a separate term in shouldSkipOnboarding). The narrower needsPrivateDomainOnboarding check preserves the existing skip for genuinely invited users while unblocking only the private domain flow.

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!