[$250] Onboarding modal is show when the invited member does not complete onboarding login

[lanitochka17]

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-4
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/test-runs/TR-29867/folder/13176677/41237677/1417452913?sort=%2Bidentifier
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11/ Chrome
App Component: Other

Action Performed:

1. Go to OldDot staging.expensify.com > Choose the "Manage expenses for 1-9 employees" option and sign up with a new account
2. Once on NewDot - don't complete the onboarding modal, exit the browser
3. Another account invite the created account to a Collect workspace via OldDot as a member
4. As the invited member again, open staging.new.expensify.com and login

Expected Result:

The onboarding modal is not shown

Actual Result:

Onboarding modal still shows

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7155158_1778857066552.bandicam_2026-05-15_17-44-48-205.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022055326948013049067
• Upwork Job ID: 2055326948013049067
• Last Price Increase: 2026-05-15

Issue Owner

Current Issue Owner: @mollfpr

[lanitochka17]

https://test-management.browserstack.com/projects/2219752/test-runs/TR-29867/folder/13176677/41237677/1417452913?sort=%2Bidentifier

[MelvinBot]

Proposal

What is the root cause of that problem?

There are two code paths that control whether the onboarding modal is shown, and both fail to skip onboarding for invited workspace members who haven't completed it:

1. OnboardingGuard.ts:186-187: isInvitedOrGroupMember is computed at line 173 but is never included in the shouldSkipOnboarding condition. It's only used in debug logging at line 213. So the navigation guard always redirects these users to onboarding.

2. useOnboardingFlow.ts:86: The skip condition is isInvitedOrGroupMember && isOnboardingCompleted. This requires the user to have already completed onboarding. For a user who started but didn't finish (hasCompletedGuidedSetupFlow === false), the AND condition fails even though they now belong to a workspace.

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

1. In OnboardingGuard.ts, add isInvitedOrGroupMember to the shouldSkipOnboarding condition at line 186-187.
2. In useOnboardingFlow.ts, change the condition at line 86 from isInvitedOrGroupMember && isOnboardingCompleted to just isInvitedOrGroupMember so that workspace membership alone is sufficient to skip onboarding.

What alternative solutions did you explore? (Optional)

An alternative would be to mark onboarding as complete server-side when a user is invited to a workspace (setting hasCompletedGuidedSetupFlow = true in NVP_ONBOARDING). However, fixing the client-side guard logic is simpler and more correct — the intent of isInvitedOrGroupMember was clearly to skip onboarding for these users, it just wasn't wired up properly.

Investigation details

Data flow for the reported scenario:

1. User signs up via OldDot → NVP_ONBOARDING is populated with hasCompletedGuidedSetupFlow: false
2. User exits before completing onboarding
3. Another account invites user to a Collect workspace → hasNonPersonalPolicy becomes true
4. User logs back into NewDot
5. OnboardingGuard.evaluate runs: isOnboardingCompleted = false, isInvitedOrGroupMember = true (but not checked)
6. shouldSkipOnboarding evaluates to false → guard redirects to onboarding
7. useOnboardingFlow runs: isInvitedOrGroupMember && isOnboardingCompleted = true && false = false → onboarding starts

Key selector: hasCompletedGuidedSetupFlowSelector returns true for empty objects (old/migrated accounts) but returns the actual false value for users who started but didn't finish onboarding.

Likely related issue: #84436 appears to describe the same underlying bug.

---

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 - @marufsharifi (External)

[melvin-bot]

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

[aswin-s]

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

When an invited member completes OldDot signup (which creates a workspace and sets introSelected but does not run NewDot onboarding), exits the browser, and is later invited to a Collect workspace by another account, the onboarding modal appears on re-login even though the user is now an invited/group member who should skip onboarding. This occurs because the guard that checks whether to show onboarding incorrectly requires both invited/group membership AND onboarding completion, when invited/group members should skip onboarding regardless of completion status.

What is the root cause of that problem?

The bug is in src/hooks/useOnboardingFlow.ts in the useOnboardingFlowRouter function. The guard that decides whether to skip the onboarding modal requires isInvitedOrGroupMember && isOnboardingCompleted to be true before returning early and suppressing the modal:

App/src/hooks/useOnboardingFlow.ts

Lines 82 to 88 in 845811f

	const isMigratedUser = hasBeenAddedToNudgeMigration ?? false;
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const isInvitedOrGroupMember = (!CONFIG.IS_HYBRID_APP && (hasNonPersonalPolicy || wasInvitedToNewDot)) ?? false;
	// OD signup sets inviteType + creates a workspace, so invited/group members can still need NewDot onboarding.
	if (isMigratedUser || (isInvitedOrGroupMember && isOnboardingCompleted)) {
	return;
	}

The intent is to skip onboarding for invited/group members, but the condition is overly restrictive. In the repro, after another account invites the user to a workspace, isInvitedOrGroupMember is true (because hasNonPersonalPolicy is true), but isOnboardingCompleted is false (because the user never finished NewDot onboarding after OldDot signup). Since both conditions must be true, the guard fails, and execution falls through to show the onboarding modal.

The hook already has robust hydration guards: it returns early when isLoadingApp !== false, when isOnboardingLoading is true, or when isLoadingOnyxValue(isOnboardingCompletedMetadata, tryNewDotMetadata, dismissedProductTrainingMetadata) is true. Both isMigratedUser and isInvitedOrGroupMember are computed with ?? false defaults, so they are always boolean by the time the guard runs. The sole issue is the logical conjunction: isOnboardingCompleted should not gate the invited-member skip.

The isOnboardingCompleted value comes from hasCompletedGuidedSetupFlowSelector(onboardingValues), which returns true for legacy/migrated accounts that have no onboarding Onyx data. For a brand-new OldDot-signup user who exits before finishing NewDot onboarding, onboardingValues will reflect an incomplete flow, so isOnboardingCompleted is false. This is the exact condition that triggers the bug on every subsequent login — including after logout and re-login — until the user manually completes onboarding, because the Onyx state is re-hydrated from the server each session and the incomplete flag persists until onboarding is finished.

The bug reproduces on web only because the isInvitedOrGroupMember calculation explicitly short-circuits on HybridApp (!CONFIG.IS_HYBRID_APP && ...). Native iOS/Android builds that go through HybridApp do not reach this code path, which is consistent with the issue's platform checklist showing only Windows/Chrome affected.

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

1. File: src/hooks/useOnboardingFlow.ts
   Function: useOnboardingFlowRouter
   Description: Remove the isOnboardingCompleted requirement from the invited/group member guard. Change the condition from (isMigratedUser || (isInvitedOrGroupMember && isOnboardingCompleted)) to (isMigratedUser || isInvitedOrGroupMember) so that invited/group members skip onboarding unconditionally, regardless of whether they previously started and abandoned the NewDot onboarding flow.

-                if (isMigratedUser || (isInvitedOrGroupMember && isOnboardingCompleted)) {
+                if (isMigratedUser || isInvitedOrGroupMember) {
                     return;
                 }

No changes to the existing null/hydration guards are needed — the hook already ensures isLoadingApp === false and all Onyx metadata is loaded before this code runs, and both isMigratedUser and isInvitedOrGroupMember are explicitly defaulted to false via ?? false before the guard is evaluated.

Blast radius: This change only affects the early-return guard for invited/group members in useOnboardingFlowRouter. The fix is limited to non-HybridApp (web) sessions because isInvitedOrGroupMember is already gated with !CONFIG.IS_HYBRID_APP. No other callers or code paths depend on the conjunction with isOnboardingCompleted. The change is isolated to the conditional logic that gates modal display, and it aligns the invited-member path with the migrated-user path, which has always skipped onboarding unconditionally.

What alternative solutions did you explore?

1. Force hasCompletedGuidedSetupFlow=true server-side when a user accepts a workspace invite — Rejected because it is a backend change out of scope for this bug, would conflate the genuine onboarding-completion signal with a workspace-invitation side effect, and would affect telemetry/analytics that rely on the true completion status. The frontend guard is the correct layer to fix because it is where the modal is actually gated.

[dilshodmackbook-sketch]

Proposal

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

A user starts the OldDot "Manage expenses for 1–9 employees" signup, lands in NewDot with NVP_ONBOARDING.hasCompletedGuidedSetupFlow: false, and exits before finishing onboarding. Another account then invites them to an existing Collect workspace via OldDot. When that user signs back into NewDot they are now a regular member of an already set-up workspace, but the standalone onboarding modal is still forced open instead of dropping them into the workspace.

What is the root cause of that problem?

The skip-onboarding guard in useOnboardingFlowRouter only suppresses the modal for invited/group members when onboarding is already completed:

https://github.com/Expensify/App/blob/main/src/hooks/useOnboardingFlow.ts#L80-L86

const isInvitedOrGroupMember = (!CONFIG.IS_HYBRID_APP && (hasNonPersonalPolicy || wasInvitedToNewDot)) ?? false;
// OD signup sets inviteType + creates a workspace, so invited/group members can still need NewDot onboarding.
if (isMigratedUser || (isInvitedOrGroupMember && isOnboardingCompleted)) {
    return;
}

So in this repro, after step 3, the flags are hasNonPersonalPolicy=true, wasInvitedToNewDot=true, hasCompletedGuidedSetupFlow=false — the AND evaluates to false, control falls through to startOnboardingFlow and the modal reopens:

https://github.com/Expensify/App/blob/main/src/hooks/useOnboardingFlow.ts#L93-L104

The reason this && isOnboardingCompleted tiebreaker exists is the OD self-signup path (PR #89071 / commit 25cf873) — "Manage 1–9" signup on OldDot also sets introSelected.inviteType and creates a workspace, so wasInvitedToNewDotSelector and hasNonPersonalPolicy both flip to true for users who genuinely still need NewDot onboarding. The author needed a tiebreaker to keep that case in the flow, and used isOnboardingCompleted — which works for that case but, as a side effect, breaks the case in this issue.

The navigation guard has the same defect from the other direction: isInvitedOrGroupMember is computed but is not part of shouldSkipOnboarding, so any deep-link or programmatic navigation re-redirects the invited member back into onboarding:

https://github.com/Expensify/App/blob/main/src/libs/Navigation/guards/OnboardingGuard.ts#L173

https://github.com/Expensify/App/blob/main/src/libs/Navigation/guards/OnboardingGuard.ts#L186-L187

The signal that's actually missing in both files is "I'm a non-admin member of a non-personal policy I don't own". Policy already exposes the current user's role, and PolicyUtils already has an isPolicyUser helper that returns true when policy.role === CONST.POLICY.ROLE.USER:

https://github.com/Expensify/App/blob/main/src/types/onyx/Policy.ts#L1816-L1817

https://github.com/Expensify/App/blob/main/src/libs/PolicyUtils.ts#L542-L545

After step 3 of the repro, the invited Collect workspace lands in POLICY with role: 'user', while the workspace from OD self-signup has role: 'admin'. The role discriminates the two cases cleanly — isOnboardingCompleted does not.

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

The fix is to split the predicate so that membership-with-user-role unconditionally skips onboarding, while the noisier wasInvitedToNewDot signal keeps its && isOnboardingCompleted tiebreaker (preserving the PR #89071 behaviour for OD self-signups). Share the predicate between the hook and the guard so they stay consistent.

1. Add a selector in src/selectors/Onboarding.ts (next to wasInvitedToNewDotSelector) — e.g. isInvitedWorkspaceMemberSelector(policies, currentUserLogin) — that returns true if any non-personal policy in the collection has role === CONST.POLICY.ROLE.USER for the current user (or compose isPolicyUser from PolicyUtils). This is the new canonical "real invitee" signal and is exported once so both call sites agree.

2. Wire it into src/hooks/useOnboardingFlow.ts — subscribe to ONYXKEYS.COLLECTION.POLICY and the session email, replace the current AND, and short-circuit on the role-aware signal:

- const isInvitedOrGroupMember = (!CONFIG.IS_HYBRID_APP && (hasNonPersonalPolicy || wasInvitedToNewDot)) ?? false;
- // OD signup sets inviteType + creates a workspace, so invited/group members can still need NewDot onboarding.
- if (isMigratedUser || (isInvitedOrGroupMember && isOnboardingCompleted)) {
+ // A real invitee is a non-admin member of someone else's workspace (role === 'user').
+ // OD self-signup makes the user an admin of their own workspace, so it fails this check and
+ // still goes through onboarding — keeping the PR #89071 fix intact.
+ const isInvitedWorkspaceMember = !CONFIG.IS_HYBRID_APP && isInvitedWorkspaceMemberSelector(allPolicies, sessionEmail);
+ const isSelfSignupInvitee = !CONFIG.IS_HYBRID_APP && wasInvitedToNewDot;
+ if (isMigratedUser || isInvitedWorkspaceMember || (isSelfSignupInvitee && isOnboardingCompleted)) {
      return;
  }

3. Mirror the change in src/libs/Navigation/guards/OnboardingGuard.ts — subscribe to the policy collection + session email at the module level (same pattern the file already uses for NVP_ONBOARDING, ACCOUNT, etc.), and add the new role-aware predicate to the shouldSkipOnboarding OR-chain so deep links / REPLACE navigation actions do not re-redirect invited members back to onboarding:

  const shouldSkipOnboarding =
-     skipOnboardingConfig || isLoading || isTransitioning || isOnboardingCompleted || isMigratedUser || isSingleEntry || needsExplanationModal || isNavigatingWithReplace;
+     skipOnboardingConfig || isLoading || isTransitioning || isOnboardingCompleted || isMigratedUser || isSingleEntry || needsExplanationModal || isInvitedWorkspaceMember || isNavigatingWithReplace;

The dead isInvitedOrGroupMember derivation at L173 can be deleted along with this change.

4. Tests — tests/unit/Navigation/guards/OnboardingGuard.test.ts (and a parallel hook test):
   • Add: hasCompletedGuidedSetupFlow=false + a non-personal policy where role='user' → expect ALLOW (this is the issue's repro).
   • Add: hasCompletedGuidedSetupFlow=false + the only non-personal policy is role='admin' (OD manage-team signup) → expect redirect to onboarding (guards the PR fix onboarding modal from OD and bac button flow #89071 regression).
   • Keep: nvp_introSelected.inviteType with hasCompletedGuidedSetupFlow=true → expect ALLOW (existing covered behaviour).

This fix is scoped to web/standalone NewDot — both predicates are guarded by !CONFIG.IS_HYBRID_APP, which matches the platforms reported in the issue.

What alternative solutions did you explore? (Optional)

1. Drop the && isOnboardingCompleted and revert to the original blanket isInvitedOrGroupMember. Smallest diff, but it re-introduces the regression PR #89071 fixed: every OD "Manage 1–9" self-signup would also satisfy hasNonPersonalPolicy || wasInvitedToNewDot and skip NewDot onboarding entirely. Rejected — it trades one bug for the previously-fixed one.

2. Backend-only fix. Have the server set nvp_introSelected.inviteType = workspace (or flip hasCompletedGuidedSetupFlow = true) when an existing account is invited as a workspace member. That would also unblock this repro on the current client, but it conflates "user completed onboarding" with "user got invited" in telemetry and analytics, and it requires a server change for a bug the client already has enough data to fix correctly after OpenApp. Rejected as out of scope and semantically lossy.

3. Replace hasNonPersonalPolicy with a coarser "user has any non-admin policy role" boolean derived in a single Onyx selector, without keeping wasInvitedToNewDot at all. This is conceptually clean but would silently drop the existing inviteType-based skip path for invite-created accounts that have no policy collection populated yet (e.g. invited-then-account-created flow before OpenApp finishes). Rejected — the role-aware predicate is additive and preserves the inviteType branch as a fallback.

[aswin-s]

Updated the proposal above to tighten 4 edge cases (additional guards and broader coverage).

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-15 17:03:32 UTC.

Proposal

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

A user can start the OldDot "Manage expenses for 1-9 employees" signup, land in NewDot with hasCompletedGuidedSetupFlow: false, leave before finishing onboarding, then later get invited as a member to an existing Collect workspace. When that invited member signs back into NewDot, the onboarding modal is still forced open. Since they are now an employee/member of an existing workspace, they should not be asked to finish the standalone company onboarding flow.

What is the root cause of that problem?

The current client only skips the onboarding flow for invited/group-member users when hasCompletedGuidedSetupFlowSelector() already returns true.

App/src/hooks/useOnboardingFlow.ts

Lines 82 to 87 in 8f3ca19

	const isMigratedUser = hasBeenAddedToNudgeMigration ?? false;
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const isInvitedOrGroupMember = (!CONFIG.IS_HYBRID_APP && (hasNonPersonalPolicy || wasInvitedToNewDot)) ?? false;
	// OD signup sets inviteType + creates a workspace, so invited/group members can still need NewDot onboarding.
	if (isMigratedUser || (isInvitedOrGroupMember && isOnboardingCompleted)) {
	return;

That means this repro falls through to startOnboardingFlow() because the user still has hasCompletedGuidedSetupFlow: false from the abandoned signup.

App/src/hooks/useOnboardingFlow.ts

Lines 90 to 105 in 8f3ca19

	// Explicitly start the onboarding flow when onboarding is not completed.
	// We use startOnboardingFlow (which calls resetRoot) instead of Navigation.navigate because
	// navigate goes through the router where OnboardingGuard would block the navigation.
	// waitForProtectedRoutes ensures navigation is ready, which is critical during fresh login.
	// Skip when HybridApp explanation modal is active (OldDot-transitioning users).
	if (isOnboardingCompleted === false && !(CONFIG.IS_HYBRID_APP && isHybridAppOnboardingCompleted === false)) {
	Navigation.waitForProtectedRoutes().then(() => {
	startOnboardingFlow({
	onboardingValuesParam: onboardingValues ?? undefined,
	isUserFromPublicDomain: !!account?.isFromPublicDomain,
	hasAccessiblePolicies: !!account?.hasAccessibleDomainPolicies,
	currentOnboardingCompanySize: onboardingCompanySize,
	currentOnboardingPurposeSelected: onboardingPurposeSelected,
	onboardingInitialPath,
	onboardingValues,
	});

The navigation guard has the same mismatch: it computes isInvitedOrGroupMember, but that value is not part of shouldSkipOnboarding, so a navigation action for the same user can still be redirected into onboarding.

App/src/libs/Navigation/guards/OnboardingGuard.ts

Lines 167 to 187 in 8f3ca19

	const isTransitioning = context.currentUrl?.includes(ROUTES.TRANSITION_BETWEEN_APPS);
	const isOnboardingCompleted = hasCompletedGuidedSetupFlowSelector(onboarding) ?? false;
	const isMigratedUser = tryNewDot?.hasBeenAddedToNudgeMigration ?? false;
	const isSingleEntry = hybridApp?.isSingleNewDotEntry ?? false;
	const needsExplanationModal = (CONFIG.IS_HYBRID_APP && tryNewDot?.isHybridAppOnboardingCompleted !== true) ?? false;
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const isInvitedOrGroupMember = (!CONFIG.IS_HYBRID_APP && (hasNonPersonalPolicy || wasInvitedToNewDot)) ?? false;
	// Redirect completed users who try to navigate to onboarding routes (e.g. via deep link)
	// The OnboardingModalNavigator is not mounted when onboarding is complete, so the route would silently fail
	if ((isOnboardingCompleted || CONFIG.SKIP_ONBOARDING) && isNavigatingToOnboardingFlow(action)) {
	Log.info('[OnboardingGuard] Redirecting user away from onboarding route to home');
	return {type: 'REDIRECT', route: ROUTES.HOME};
	}
	const skipOnboardingConfig = CONFIG.SKIP_ONBOARDING;
	const isLoading = context.isLoading;
	const isNavigatingWithReplace = isNavigatingToOnboardingFlowWithReplaceAction(action);
	const shouldSkipOnboarding =
	skipOnboardingConfig || isLoading || isTransitioning || isOnboardingCompleted || isMigratedUser || isSingleEntry || needsExplanationModal || isNavigatingWithReplace;

The tricky part is that we should not simply skip onboarding for every HAS_NON_PERSONAL_POLICY or every nvp_introSelected.inviteType user. OldDot "manage expenses" signup can set the invite flag and create/reuse an admin workspace during onboarding, and that admin/owner user may still need the company onboarding steps. The issue's repro is narrower: after another account invites this user "as a member" to an existing Collect workspace, the policy data identifies them as a non-admin workspace participant.

Policy already exposes the current user's role, and PolicyUtils already has helpers for user/employee workspaces.

App/src/types/onyx/Policy.ts

Lines 1999 to 2003 in 8f3ca19

	/** The current user's role in the policy */
	role: ValueOf<typeof CONST.POLICY.ROLE>;
	/** The policy type */
	type: ValueOf<typeof CONST.POLICY.TYPE>;

App/src/libs/PolicyUtils.ts

Line 542 in 8f3ca19

const isPolicyUser = (policy: OnyxInputOrEntry<Policy>, currentUserLogin?: string): boolean => getPolicyRole(policy, currentUserLogin) === CONST.POLICY.ROLE.USER;

App/src/libs/PolicyUtils.ts

Lines 1396 to 1400 in 8f3ca19

	/** Return active policies where current user is an employee (of the role "user") */
	function getActiveEmployeeWorkspaces(policies: OnyxCollection<Policy> | null, currentUserLogin: string | undefined): Policy[] {
	const activePolicies = getActivePolicies(policies, currentUserLogin);
	return activePolicies.filter((policy) => shouldShowPolicy(policy, getIsOffline(), currentUserLogin) && isPolicyUser(policy, currentUserLogin));
	}

So the bug is that the skip logic still uses the coarse invite/non-personal-policy signal, then gates it by onboarding completion, instead of distinguishing employee membership from an admin workspace created by the abandoned OldDot signup flow.

There is also a route-state edge case after the same root condition fails: the user can already be sitting on an /onboarding/... route from a previous attempt. In that case, simply preventing a new startOnboardingFlow() call is not enough because the stale onboarding modal route is already mounted. Once the role-aware employee-membership signal is true, the app also needs to dismiss or redirect away from that existing onboarding route.

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

Make the onboarding skip condition role-aware and share it between useOnboardingFlowRouter and OnboardingGuard.

1. Add a small helper, either in @selectors/Onboarding or a nearby onboarding utility, that answers: "should this non-hybrid user skip the standalone onboarding modal because they are already an invited workspace participant?"

   • Return true when the current user has at least one active non-personal policy where their policy role is CONST.POLICY.ROLE.USER, using getActiveEmployeeWorkspaces() / isPolicyUser() if that matches the intended employee-member roles.
   • Do not return true just because hasNonPersonalPolicy is true, because that includes admin workspaces created by the OldDot manage-team signup path.
   • Do not return true just because wasInvitedToNewDotSelector(introSelected) is true while onboarding is incomplete, because OldDot signup can also set inviteType. Existing completed/invite-specific behavior can remain covered by isOnboardingCompleted; the new unconditional skip should come from actual employee membership.
   • Return false when the only active non-personal workspace role is admin/owner, so OldDot manage-team signup can still continue the company onboarding flow.

2. In src/hooks/useOnboardingFlow.ts, subscribe to the policy collection and session email (or a selector over them), replace the current coarse hasNonPersonalPolicy || wasInvitedToNewDot boolean with the role-aware helper, and return before startOnboardingFlow() when that helper is true. This is the direct fix for the modal opening on login after the member invite.

   • Also handle the stale-route case: if the role-aware helper becomes true while the current URL is already /onboarding/..., dismiss the onboarding modal instead of just returning, so an invited member is not left on /onboarding/work-email from a previous attempt.

3. In src/libs/Navigation/guards/OnboardingGuard.ts, subscribe to the same policy data and apply the same helper in shouldSkipOnboarding. This keeps route-level redirects consistent with the hook and avoids forcing the same user back into onboarding on subsequent navigation actions.

   • Additionally, when the same invited-member helper is true, redirect onboarding-targeting navigation actions (including an existing/reset onboarding modal route) back to Home so a stale or deep-linked onboarding route cannot remain mounted.

4. Update tests/unit/Navigation/guards/OnboardingGuard.test.ts:

   • Add/adjust a case where NVP_ONBOARDING.hasCompletedGuidedSetupFlow = false and the user is a USER/employee member of a Collect workspace. Expected: ALLOW.
   • Keep/add a case where hasCompletedGuidedSetupFlow = false and the only non-personal workspace role is admin/owner from the OD manage-team signup path. Expected: redirect to onboarding.
   • Keep the existing invite/completed cases so invite-created accounts that already safely skip onboarding continue to do so.
   • Add a case where the user has incomplete onboarding and employee-role workspace membership while navigation is already targeting onboarding. Expected: redirect/dismiss to Home.

This keeps the behavior that was intentionally preserved for OD-created admin workspaces, while fixing the exact employee-invite case from this issue.

What alternative solutions did you explore? (Optional)

A backend-only fix could set hasCompletedGuidedSetupFlow complete when an already-created account is later invited as a workspace member. That would also make this client skip the modal, but it would conflate "completed onboarding" with "joined someone else's workspace".

I would not simply restore the old blanket isInvitedOrGroupMember skip for every HAS_NON_PERSONAL_POLICY / invite user, because that would also skip onboarding for users whose non-personal policy is an admin workspace created/reused by the OldDot manage-team onboarding path. The role-aware employee-workspace skip is the narrower fix.