Only show "New role types for admins" dialog to returning Collect/Control admins

[melvin-bot]

Problem
The "New role types for admins" training dialog is currently being shown to brand-new users. It should only be shown to returning Collect/Control admins — not to brand-new users, and definitely not to Submit admins.

Expected behavior

• Show the "New role types for admins" dialog only to returning Collect/Control admins.
• Do not show it to brand-new users.
• Do not show it to Submit admins.

Notes

• Related (but distinct): [Due for payment 2026-08-25] Can't dismiss New role types for admins modal #98140 covers a bug where the same modal can't be dismissed. This issue is specifically about the eligibility/targeting logic for who sees the dialog.

Reported in Slack.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022089976607632433365
• Upwork Job ID: 2089976607632433365
• Last Price Increase: 2026-08-19

[melvin-bot]

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

[melvin-bot]

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

[carlosmiceli]

@MelvinBot submit a proposal to get started

[MelvinBot]

Proposal

What is the root cause of that problem?

The "New role types for admins" window is the admin variant of the active product-marketing announcement (productUpdateJuly2026). Its audience gating in ProductMarketingWindowManager is too broad — it shows the admin window to any user who is an admin on any active workspace, and never checks whether the user is brand-new:

• targetAdminPolicyID is derived from activeAdminPolicies, which comes from getActiveAdminWorkspaces. That helper returns admin workspaces of every policy type, including Submit (submit2026). So Submit admins get the window.
• There is no "returning vs brand-new" check anywhere in the gating conditions, so a brand-new user who just created a workspace sees a window announcing a feature as "new" that they never had an "old" version of.

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

Two additional gates on the admin variant:

1. Restrict to Collect/Control workspaces. When computing the target admin policy, only consider workspaces whose type is Control (corporate) or Collect (team), excluding Submit (submit2026) — see the policy type constants. If the user has no Collect/Control admin workspace, don't show the admin window.

2. Exclude brand-new users. Add a gate that treats the user as "returning" only if their first workspace predates the feature. The nvp_private_firstPolicyCreatedDate NVP is already used for exactly this new-vs-returning distinction in useHasTeam2025Pricing — mirror that pattern against a new "role types launch date" constant, and skip the window when the first policy was created on/after that date.

Both checks live alongside the existing early-return conditions in the manager, keeping the pure resolver in ProductMarketingWindowUtils unit-testable.

What alternative solutions did you explore? (Optional)

Instead of a firstPolicyCreatedDate cutoff, "returning" could be sourced from a dedicated backend eligibility NVP delivered via OpenApp (the manager already waits on OpenApp for targeting data). That's more robust but requires backend work; the client-side date check reuses existing data and ships within App. The exact launch date and the preferred "returning" signal should be confirmed with the team before implementation.

---

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

[carlosmiceli]

@MelvinBot implement your proposal

[MelvinBot]

🤖 Draft PR created: #98953

It adds two gates in ProductMarketingWindowManager so the "New role types for admins" window only reaches returning Collect/Control admins:

• Collect/Control only: the target admin workspace is now picked from team/corporate policies only, so Submit (submit2026) admins fall through to the (absent) member variant and see nothing.
• Exclude brand-new users: a new returningUserCutoffDate on the announcement + an isBrandNewUser helper compare against nvp_private_firstPolicyCreatedDate (mirroring useHasTeam2025Pricing), so users whose first workspace was created on/after the cutoff don't see it.

Local AI checks pass: typecheck-tsgo, lint-changed, react-compiler-compliance-check, oxfmt, and the ProductMarketingWindowUtils unit suite (15 tests, including new isBrandNewUser coverage). A web smoke test couldn't complete because the dev server wasn't serving in the CI environment (blank page, no network activity) — the manual test/QA steps in the PR should be validated before it's marked ready.

Two things for reviewers to confirm, called out in the PR: the exact launch date for the cutoff (currently 2026-07-01 to match the productUpdateJuly2026 key), and whether a backend-provided eligibility signal is preferred over the client-side date check.

Please mark the PR as "Ready for review" when it's ready.

[mukhrr]

@carlosmiceli do you really think Melvin's solution is complete? I mean if a user's firstPolicyCreatedDate hasn't synced yet (which is normal for a brand-new admin), isBrandNewUser reads that as "returning" and shows the window anyway. so the exact case this issue wants hidden still gets shown. cc @ahmedGaber93

[carlosmiceli]

@mukhrr no, that's possible, I wanted to start building and testing it. Feel free to submit a proposal and if it's better we can go with it.

[mukhrr]

Proposal

What is the root cause of that problem?

ProductMarketingWindowManager decides eligibility for the "New role types for admins" window from activeAdminPolicies alone, with no plan-type filter and no new-vs-returning check:

App/src/components/ProductMarketingWindow/ProductMarketingWindowManager.tsx

Lines 50 to 73 in 712cdef

	function ProductMarketingWindowManager({topmostRouteName}: ProductMarketingWindowManagerProps) {
	const {login: currentUserLogin = ''} = useCurrentUserPersonalDetails();
	const [activeAdminPolicies, activeAdminPoliciesMetadata] = useOnyx(ONYXKEYS.COLLECTION.POLICY, {
	selector: (policies: OnyxCollection<Policy>) => activeAdminPoliciesSelector(policies, currentUserLogin),
	});
	const [activePolicyID, activePolicyIDMetadata] = useOnyx(ONYXKEYS.NVP_ACTIVE_POLICY_ID);
	// Semantically covering overlays take precedence over the marketing window from pre-show through final hide.
	// Responsive popover sheets and route-backed right-docked navigation remain exempt.
	const [isProductMarketingWindowCovered = false] = useOnyx(ONYXKEYS.RAM_ONLY_IS_PRODUCT_MARKETING_WINDOW_COVERED);
	const [isAnonymousSession = false] = useOnyx(ONYXKEYS.SESSION, {selector: isAnonymousSessionSelector});
	const [isActingAsDelegate = false, accountMetadata] = useOnyx(ONYXKEYS.ACCOUNT, {selector: isActingAsDelegateSelector});
	const [lastDismissedMarketingWindow, lastDismissedMarketingWindowMetadata] = useOnyx(ONYXKEYS.NVP_LAST_DISMISSED_MARKETING_WINDOW);
	// OpenApp provides the dismissal and targeting data; wait for it to avoid a startup flash or a wrong CTA destination.
	const [isLoadingApp = true, isLoadingAppMetadata] = useOnyx(ONYXKEYS.IS_LOADING_APP);
	const announcement = ACTIVE_PRODUCT_MARKETING_ANNOUNCEMENT;
	// Every illustration-backed variant is resolved up front because useMemoizedLazyIllustrations doesn't reload
	// assets when the requested names change after mount (e.g. when the audience flips after policies arrive).
	const illustrationNames = announcement ? [announcement.admin.visual, announcement.member?.visual].flatMap((visual) => (visual?.type === 'illustration' ? [visual.name] : [])) : [];
	const illustrations = useMemoizedLazyIllustrations(illustrationNames);
	const targetAdminPolicyID = activeAdminPolicies?.find((policy) => policy.id === activePolicyID)?.id ?? activeAdminPolicies?.at(0)?.id;
	const variant = getProductMarketingAnnouncementVariant(announcement, !!targetAdminPolicyID, lastDismissedMarketingWindow);
	const isCoveredByCenteredModalScreen = !!topmostRouteName && CENTERED_MODAL_SCREEN_NAVIGATORS.has(topmostRouteName);
	const isLoading = isLoadingOnyxValue(lastDismissedMarketingWindowMetadata, activeAdminPoliciesMetadata, activePolicyIDMetadata, isLoadingAppMetadata, accountMetadata) || isLoadingApp;

activeAdminPolicies comes from activeAdminPoliciesSelector → getActiveAdminWorkspaces, which filters only by active status and admin role, not by plan:

App/src/libs/PolicyUtils.ts

Lines 1959 to 1963 in 712cdef

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

So a Submit (submit2026) admin passes the same !!targetAdminPolicyID check as a Collect/Control admin. The paid-plan predicate the app already uses elsewhere for exactly this Collect/Control-vs-Submit distinction sits unused a few hundred lines away:

App/src/libs/PolicyUtils.ts

Lines 1340 to 1363 in 712cdef

	/**
	* Returns true only for paid plans (Collect/Control). Use this only for billing/paid-only concerns:
	* subscriptions, payments and reimbursement, company cards, Expensify Card, Travel, Invoices, and
	* "do I own a paid workspace" checks.
	*
	* For workspace feature gating (violations, report fields, workspace chat, report creation,
	* expense-workspace usability) use `isGroupPolicy` instead, otherwise free group plans like Submit
	* (submit2026) are wrongly excluded. The report-based counterparts are `ReportUtils.isPaidGroupPolicy`
	* (paid-only) and `ReportUtils.isReportInGroupPolicy` (group).
	*/
	function isPaidGroupPolicy(policy: OnyxInputOrEntry<Policy>): boolean {
	return policy?.type === CONST.POLICY.TYPE.TEAM || policy?.type === CONST.POLICY.TYPE.CORPORATE;
	}
	function isPaidGroupPolicyByType(policyType: string | undefined): boolean {
	return policyType === CONST.POLICY.TYPE.TEAM || policyType === CONST.POLICY.TYPE.CORPORATE;
	}
	function isSubmitPolicy(policy: OnyxInputOrEntry<Policy>): boolean {
	return policy?.type === CONST.POLICY.TYPE.SUBMIT;
	}
	function isSubmitPolicyByType(policyType: string | undefined): boolean {
	return policyType === CONST.POLICY.TYPE.SUBMIT;

I pulled the real Onyx state off a signed-in dev session to check this against live data: nvp_private_firstPolicyCreatedDate was sitting there ("2026-07-06 11:26:06"), and the account was an active admin on both a team and a corporate policy, exactly the unfiltered shape getActiveAdminWorkspaces hands to the manager. That NVP is never read by the manager at all, it's only consumed by useHasTeam2025Pricing and ExportOnyxState, confirming there's genuinely no new-vs-returning signal in the eligibility path today:

App/src/hooks/useHasTeam2025Pricing.tsx

Lines 1 to 21 in 712cdef

	import CONST from '@src/CONST';
	import ONYXKEYS from '@src/ONYXKEYS';
	import {differenceInDays} from 'date-fns';
	import useOnyx from './useOnyx';
	function useHasTeam2025Pricing(): boolean {
	const [firstPolicyDate] = useOnyx(ONYXKEYS.NVP_PRIVATE_FIRST_POLICY_CREATED_DATE);
	const [hasManualTeam2025Pricing] = useOnyx(ONYXKEYS.NVP_PRIVATE_MANUAL_TEAM_2025_PRICING);
	if (hasManualTeam2025Pricing) {
	return true;
	}
	if (!firstPolicyDate) {
	return true;
	}
	return differenceInDays(firstPolicyDate, CONST.SUBSCRIPTION.TEAM_2025_PRICING_START_DATE) >= 0;
	}

I encoded the three broken audiences as Jest cases against unfixed main and all three failed as predicted: a Submit-type admin got the window, an admin whose firstPolicyCreatedDate postdates the campaign got the window (the brand-new case), and an admin with no recorded first-policy date also got the window. A fourth case exposed a second-order bug in the same code: with an active Submit workspace and a separate eligible Collect workspace, the CTA navigated to workspaces/product-marketing-policy/members (the Submit workspace) instead of the Collect one, because targetAdminPolicyID is picked from the same unfiltered list.

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

In ProductMarketingWindowManager, filter activeAdminPolicies down to Collect/Control with isPaidGroupPolicy before picking targetAdminPolicyID, so a Submit workspace can never become the CTA destination either. Read NVP_PRIVATE_FIRST_POLICY_CREATED_DATE (with its loading metadata folded into isLoading) and gate on it via a new isReturningRoleTypesAdmin predicate in ProductMarketingWindowUtils, pinned to the window's first commit date (2026-07-15, confirm with the team). Unlike useHasTeam2025Pricing, a missing date resolves to not eligible, not eligible, since the intent here is to exclude anyone we can't positively confirm as returning, including a brand-new admin whose NVP hasn't landed yet.

- const targetAdminPolicyID = activeAdminPolicies?.find((policy) => policy.id === activePolicyID)?.id ?? activeAdminPolicies?.at(0)?.id;
- const variant = getProductMarketingAnnouncementVariant(announcement, !!targetAdminPolicyID, lastDismissedMarketingWindow);
+ const eligibleAdminPolicies = activeAdminPolicies?.filter(isPaidGroupPolicy);
+ const targetAdminPolicyID = eligibleAdminPolicies?.find((policy) => policy.id === activePolicyID)?.id ?? eligibleAdminPolicies?.at(0)?.id;
+ const isEligibleForAdminAnnouncement = !!targetAdminPolicyID && isReturningRoleTypesAdmin(firstPolicyCreatedDate);
+ const variant = getProductMarketingAnnouncementVariant(announcement, isEligibleForAdminAnnouncement, lastDismissedMarketingWindow);

+ const ROLE_TYPES_ADMIN_ANNOUNCEMENT_LAUNCH_DATE = new Date(2026, 6, 15);
+ function isReturningRoleTypesAdmin(firstPolicyCreatedDate: OnyxEntry<string>): boolean {
+     return !!firstPolicyCreatedDate && differenceInDays(firstPolicyCreatedDate, ROLE_TYPES_ADMIN_ANNOUNCEMENT_LAUNCH_DATE) < 0;
+ }

With this change, the four scenarios I added (Submit admin, post-cutoff first-policy date, missing first-policy date, and the Submit-active/Collect-eligible CTA target) all pass, and the 15 pre-existing manager tests are untouched. The one trade-off worth naming: an invited Collect/Control admin who never created their own workspace may not have this NVP populated, so they'd be conservatively excluded until it's confirmed otherwise.

What alternative solutions did you explore? (Optional)

I looked at reusing useHasTeam2025Pricing directly, but it treats a missing first-policy date as eligible (return true when !firstPolicyDate), which is the wrong default here, we specifically want to exclude when returning status can't be established, not include. A backend-driven eligibility NVP delivered via OpenApp would be more authoritative long-term, but it needs coordinated backend work; the client-side date check reuses data the app already has and ships entirely in App.

[carlosmiceli]

Great, let's see what @ahmedGaber93 says 🫡