Workspace- "Configure via Gusto" link navigated to not here page

[mitarachim]

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.70-1
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #89996
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome, Samsung Galaxy A52 / Android 14, iPhone 13 / iOS 26.5
App Component: Workspace Settings

Action Performed:

Preconditions

• Logged in to Expensifail account
• Create a control workspace
• Connect Gusto integration to the workspace in Olddot Prod environment (expensify.com) (credentials can be found in 1Password)
• Navigate to ND staging (staging.new.expensify.com)
• Open the workspace setting that just connected to Gusto

Steps:

1. Go to Workspace settings > Workflows.
2. Click “Configure via Gusto.” link on the Approvals section
3. Back to workflow page
4. Press the locked Approvals toggle.
5. Press “Go to Gusto settings”

Expected Result:

Step 2 and step 4 should navigate to HR setting page

Actual Result:

Step 2 and step 4 navigate to not here page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7151409_1778550957277.gusto.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ShridharGoel

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #89996

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

PR #89996 added a navigateToGustoSettings function in WorkspaceWorkflowsPage.tsx:196-198 that navigates to ROUTES.WORKSPACE_HR when the user clicks "Configure via Gusto" (line 286) or "Go to Gusto settings" (line 210).

The destination page, WorkspaceHRPage.tsx:164-168, is wrapped in an AccessOrNotFoundWrapper with shouldBeBlocked={!isBetaEnabled(CONST.BETAS.GUSTO)}. If the user is not in the GUSTO beta, this evaluates to true and the wrapper renders a "Not Found" page instead of the HR settings content.

The Workflows page shows the Gusto links whenever a Gusto connection exists on the policy, but the HR page additionally requires the GUSTO beta to be enabled. This mismatch causes users with a Gusto connection but without the beta flag to land on a "not here" page.

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

The visibility of the Gusto links on the Workflows page should be gated on the same conditions as the HR page. Specifically, in WorkspaceWorkflowsPage.tsx, the isGustoConnected check (used at line 276 and line 280) should also require isBetaEnabled(CONST.BETAS.GUSTO) so the "Configure via Gusto" link and the locked toggle behavior only appear when the user can actually access the HR page.

Alternatively, if the intent is that all users with a Gusto connection should be able to access the HR page, then the shouldBeBlocked beta gate in WorkspaceHRPage.tsx:168 should be removed (or adjusted to allow access when a Gusto connection exists).

Investigation details

Navigation flow:

1. User clicks "Configure via Gusto" or toggles the locked Approvals switch → navigateToGustoSettings() is called
2. This navigates to ROUTES.WORKSPACE_HR → resolves to WorkspaceHRPage
3. WorkspaceHRPage renders AccessOrNotFoundWrapper with two gates:
   • featureName={CONST.POLICY.MORE_FEATURES.IS_HR_ENABLED} — policy must have HR enabled
   • shouldBeBlocked={!isBetaEnabled(CONST.BETAS.GUSTO)} — user must be in GUSTO beta
4. When shouldBeBlocked is true, AccessOrNotFoundWrapper.tsx:183 sets shouldShowNotFoundPage = true → renders "not here" page

Key mismatch: The Workflows page checks isGustoConnectionEnabled(policy) (Gusto connection exists) to show the links, but the HR page additionally requires the GUSTO beta flag. QA testers who have a Gusto connection in their workspace but are not enrolled in the GUSTO beta will always see the "not here" page.

---

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.