[$250] Onboarding- Task "Set up categories and tags" isn't auto-checked after completed

[nlemma]

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.55-0
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-17114/folder/13176677/41237662/1317002015
Email or phone of affected tester (no customers): lekima20+642404@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Win 11/Chrome
App Component: Other

Action Performed:

1. Open https://staging.new.expensify.com
2. Create a new user with select option "Manage my team's expenses" and complete flow
3. Navigate to Concierge chat
4. Click on 'categories" at the task 'Set up categories and tags'
5. Add a category
6. Click on More features and enable Tags
7. Click on Tags tab and add some tags
8. Navigate to Concierge chat
9. Refresh page
10. Click on the task 'Set up categories and tags'

Expected Result:

The task 'Set up categories and tags' should get auto-checked

Actual Result:

The task 'Set up categories and tags’ isn't auto-checked

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7125664_1775722351452.Recording__1959.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @DylanDylann

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022042198222552145991
• Upwork Job ID: 2042198222552145991
• Last Price Increase: 2026-04-09

[MelvinBot]

Proposal

What is the root cause of that problem?

The combined "Set up categories and tags" onboarding task has a cross-dependency for auto-completion that is asymmetric:

• Category creation path (Category.ts:900): completes the combined task if policyHasTags is true — this checks for ANY tags via hasTags() at PolicyUtils.ts:672
• Tag creation path (Tag.ts:231): completes the combined task if policyHasCustomCategories is true — this uses hasCustomCategories() at PolicyUtils.ts:680 which only counts categories whose names are not in the 19 default categories list (CONST.POLICY.DEFAULT_CATEGORIES)

In the normal user flow (categories first → tags second), auto-completion depends on the tag creation path. Since new workspaces come pre-populated with only default categories, if the user enables/toggles a default category or adds a category that happens to match a default name, hasCustomCategories returns false and the combined task never auto-completes.

The category-side check (policyHasTags) is permissive — any tag counts. The tag-side check (policyHasCustomCategories) is overly restrictive — only non-default-named categories count. This asymmetry is the bug.

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

Replace the policyHasCustomCategories condition at Tag.ts:231 with a broader check that mirrors the permissiveness of the category-side check.

Specifically, change hasCustomCategories to hasEnabledCategories (or similar) that returns true when the user has any enabled categories — including default ones. Since the user was directed from the task to set up categories and has navigated there, having enabled categories confirms they've "set up categories."

Alternatively, since setWorkspaceCategoryEnabled at Category.ts:460 already completes the combined task when policyHasTags is true (without checking for custom names), the simplest consistent fix is to use the same permissive check on the tag side — just verify that categories exist on the policy, not that they are custom-named.

What alternative solutions did you explore? (Optional)

• Remove the cross-check entirely: auto-complete the combined task on either a category or tag action, without requiring the other to exist. Rejected because the task is "Set up categories AND tags" — both should be configured.
• Track user visits: mark the task as "categories set up" when the user visits the categories page, then auto-complete when tags are also created. Rejected as over-engineered — the existing mechanism just needs the condition relaxed.

Investigation details

Key code paths:

• Combined task definition: OnboardingFlow.ts:266-272 (autoCompleted: false)
• Task filtering: ReportUtils.ts:11835-11841 — combined task only created when userReportedIntegration is truthy
• Category-side auto-check: Category.ts:899-910 — uses policyHasTags (permissive)
• Tag-side auto-check: Tag.ts:230-240 — uses policyHasCustomCategories (restrictive)
• hasCustomCategories: PolicyUtils.ts:680-688 — filters against CONST.POLICY.DEFAULT_CATEGORIES (19 names: Advertising, Benefits, Car, Equipment, Fees, Home Office, Insurance, Interest, Labor, Maintenance, Materials, Meals and Entertainment, Office Supplies, Other, Professional Services, Rent, Taxes, Travel, Utilities)
• hasTags: PolicyUtils.ts:672-674 — checks for ANY tags in any tag list
• Task completion mechanism: Task.ts:1429-1446 → completeTask at Task.ts:502-526

Data flow for user's repro steps:

1. User creates workspace → default categories pre-populated
2. User adds a category → createPolicyCategory fires → policyHasTags is false → combined task NOT completed
3. User enables Tags → feature toggle only, no tags created
4. User creates a tag → createPolicyTag fires → policyHasCustomCategories checked → returns false if category name matches a default → combined task NOT completed

---

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

[melvin-bot]

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

[yuvrajangadsingh]

Proposal

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

The onboarding task "Set up categories and tags" never auto-completes after the user adds categories and tags following the task's instructions.

What is the root cause of that problem?

The combined task has two completion paths, and they use asymmetric checks:

Category side (Category.ts:826 and :459): completes the task if policyHasTags is true, using hasTags() at PolicyUtils.ts:662. This accepts ANY tags.

Tag side (Tag.ts:201): completes the task if policyHasCustomCategories is true, using hasCustomCategories() at PolicyUtils.ts:670. This only counts categories whose names are NOT in the 19 defaults (CONST.POLICY.DEFAULT_CATEGORIES at CONST/index.ts:3368-3388).

New workspaces come pre-populated with those 19 default categories. In the normal onboarding flow (categories first, tags second), the second step is tag creation. At Tag.ts:201:

if (isTaskIncomplete(setupCategoriesAndTagsTaskReport) && policyHasCustomCategories) {
    completeTask(setupCategoriesAndTagsTaskReport, false, false, undefined);
}

policyHasCustomCategories comes from WorkspaceCreateTagPage.tsx:47, which calls hasCustomCategories(policyCategories). If the user only toggled existing default categories, or created a category matching a default name (like "Travel"), hasCustomCategories returns false. The task is permanently stuck.

The value is computed in WorkspaceCreateTagPage.tsx:47 and passed to createPolicyTag at line 73.

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

Change hasCustomCategories in PolicyUtils.ts:670-678 to not filter out default category names. The intent of this check is "has the user set up categories". Any non-deleted category should count, including defaults.

Before (PolicyUtils.ts:670-678):

function hasCustomCategories(policyCategories: OnyxEntry<PolicyCategories>): boolean {
    if (!policyCategories) {
        return false;
    }
    const defaultCategoryNames = new Set<string>(Object.values(CONST.POLICY.DEFAULT_CATEGORIES));
    return Object.values(policyCategories).some(
        (category) => category && category.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE && !defaultCategoryNames.has(category.name)
    );
}

After:

function hasCustomCategories(policyCategories: OnyxEntry<PolicyCategories>): boolean {
    if (!policyCategories) {
        return false;
    }
    return Object.values(policyCategories).some(
        (category) => category && category.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE
    );
}

Remove the defaultCategoryNames set and the !defaultCategoryNames.has(category.name) filter. This aligns the tag-side check with the permissive category-side check (hasTags).

The function is only called in one place (WorkspaceCreateTagPage.tsx:47), so this change has no side effects.

Update the test at tests/actions/PolicyTagTest.ts:2314 ("should NOT complete SETUP_CATEGORIES_AND_TAGS task when creating tag but no custom categories exist") to reflect the corrected behavior.

All completion surfaces (verified no others are affected):

• CreateCategoryPage.tsx -> createPolicyCategory (Category.ts:826) -> policyHasTags check (works correctly)
• WorkspaceCategoriesPage.tsx -> setWorkspaceCategoryEnabled (Category.ts:459) -> policyHasTags check (works correctly)
• CategorySettingsPage.tsx -> setWorkspaceCategoryEnabled (Category.ts:459) -> policyHasTags check (works correctly)
• WorkspaceCreateTagPage.tsx -> createPolicyTag (Tag.ts:201) -> policyHasCustomCategories check (the broken path, fixed by this change)

What alternative solutions did you explore? (Optional)

Considered replacing hasCustomCategories with hasEnabledOptions from OptionsListUtils (which checks for enabled + non-deleted options), but that adds a new dependency for no real benefit. The simpler fix of removing the default name filter achieves the same thing with less churn.

[nkdengineer]

Proposal

What is the root cause of that problem?

The Set up categories and tags task is completed only if the task report is related to the current workspace.

App/src/libs/actions/Policy/Tag.ts

Lines 231 to 236 in a42bb23

	if (setupCategoriesAndTagsTaskReport && policyHasCustomCategories && currentUserAccountID && isTaskForCurrentWorkspace(setupCategoriesAndTagsTaskReport)) {
	getFinishOnboardingTaskOnyxData(
	setupCategoriesAndTagsTaskReport,
	setupCategoriesAndTagsTaskParentReport,
	isSetupCategoriesAndTagsTaskParentReportArchived ?? false,
	currentUserAccountID,

When the user has + in the email, the onboarding task is created in the concierge chat, report?.policyID is _FAKE_ which causes isTaskForCurrentWorkspace to fail. Then the task is not completed.

App/src/libs/actions/Policy/Tag.ts

Line 216 in a42bb23

const isTaskForCurrentWorkspace = (taskReport: OnyxEntry<Report>) => !taskReport?.policyID || taskReport.policyID === policyID;

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

Since the title and description of the onboarding task will have the link to the onboarding workspace and this data is not editable, we can update isTaskForCurrentWorkspace check to also return true if the title/description includes the policyID

const isTaskForCurrentWorkspace = (taskReport: OnyxEntry<Report>) => !taskReport?.policyID || taskReport.policyID === policyID || taskReport?.reportName?.includes(policyID) || taskReport?.description?.includes(policyID);

App/src/libs/actions/Policy/Tag.ts

Line 216 in a42bb23

const isTaskForCurrentWorkspace = (taskReport: OnyxEntry<Report>) => !taskReport?.policyID || taskReport.policyID === policyID;

We can also update isTaskForCurrentWorkspace check when creating a category here.

App/src/libs/actions/Policy/Category.ts

Line 900 in aab8650

if (setupCategoriesAndTagsTaskReport && policyHasTags) {

What alternative solutions did you explore? (Optional)

We can remove isTaskForCurrentWorkspace as we don't use this when completing the task here

App/src/libs/actions/Policy/Tag.ts

Line 216 in a42bb23

const isTaskForCurrentWorkspace = (taskReport: OnyxEntry<Report>) => !taskReport?.policyID || taskReport.policyID === policyID;

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[github-actions]

⚠️ @nkdengineer Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[Yatin-Bhatti]

What is the root cause of that problem?

The failure to auto-complete the task is caused by Requirement Asymmetry and UI-Logic Coupling.
Asymmetric Logic: The "Set up categories and tags" task has two triggers. The category-creation trigger is permissive (any tag counts), but the tag-creation trigger is restrictive. Specifically, Tag.ts uses hasCustomCategories, which explicitly ignores the 19 default categories. If a user fulfills the onboarding requirement by enabling a default category and then adding a tag, the system fails to transition the task to "complete" because it is strictly looking for non-default category names.
State Desynchronization: The logic currently depends on boolean flags (like policyHasCustomCategories) being passed as props from the UI layer to the Action layer. If the user has an email with a + sign or is in a specific onboarding state where policyID is masked as FAKE, the UI-level checks can fail to resolve the correct workspace context, preventing the completion signal from being dispatched to the server even if the data is valid.

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

I propose a Policy-State Evaluation approach that moves the completion authority away from UI props and into a centralized utility:

Centralize Setup Verification: In PolicyUtils.ts, I will create a unified helper isCategoriesAndTagsSetup(policyID). This function will determine setup completion by checking for the existence of any enabled category (including defaults) and any active tag. This ensures a "Single Source of Truth" for this specific onboarding milestone.

Action-Layer Autonomy: I will refactor createPolicyTag in Tag.ts and the category update functions in Category.ts to call this new helper directly using the policyID. This removes the need to pass policyHasCustomCategories or policyHasTags as arguments from the React components, reducing the risk of stale data or prop-drilling errors.

Relax Category Constraints: I will update the completion check in Tag.ts to replace hasCustomCategories with a check that validates if the user has any categories configured. Toggling a default category is a valid "setup" action and should satisfy the onboarding requirement.

Contextual Policy ID Resolution: I will update the isTaskForCurrentWorkspace check to handle the FAKE policyID scenario. If the direct policyID check fails, the logic will attempt to resolve the context via the parentReportID to ensure users on the guided onboarding path aren't locked out of task completion.

What alternative solutions did you explore? (Optional)

I considered simply removing the default category filter from hasCustomCategories. However, that function might be used elsewhere in the app where "Custom" actually means "Non-Default." By creating a dedicated isCategoriesAndTagsSetup helper, we fix the onboarding bug without creating side effects for other features that might need to distinguish between default and custom categories. I also considered auto-completing the task upon the first navigation to the categories page, but rejected it because it doesn't guarantee the user actually performed the required setup.

[melvin-bot]

📣 @Yatin-Bhatti! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>