[Due for payment 2026-10-23] Join my company workspace - Magic code step reappears after skipping, wrong back navigation

@abzokhattab

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

Version Number: 9.5.9-4
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: #103652
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Other

Action Performed:

Go to staging.new.expensify.com
Log in with new Gmail account.
On work email step, enter any email with private domain (eg, @gd.lowdn.com).
Click Add work email.
Click Skip on magic code step.
Click Join my company workspace.
→ Magic code step appears again after skipping it in Step 5.
Click app back button.
→ Work email step appears when it did not appear after clicking Join my company workspace in Step 6.

Expected Result:

In Step 6, magic code step should not reappear after skipping it in Step 5.
In Step 7, work email step should not appear when it did not appear after clicking Join my company workspace in Step 6.

Actual Result:

In Step 6, magic code step reappears after skipping it in Step 5.
In Step 7, work email step appears when it did not appear after clicking Join my company workspace in Step 6.

Workaround:

Unknown

Platforms:

Screenshots/Videos

Bug7286914_1792043501995.11.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7286914

Issue Owner

Current Issue Owner: @abzokhattab

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/feb11027bb9a67fac191387016e5aef02dd74d53a563c9fb51ef9385ea4293f7

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

@iwiznia

@iwiznia @abzokhattab you have been assigned to this deploy blocker because you reviewed the offending PR: #103652

@carlosmiceli

@carlosmiceli you have been assigned to this deploy blocker because you authored the offending PR: #103652

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

👋 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:

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

Deploy Blocker Investigation

Causing PR: [Payment due @abzokhattab] Add the join-workspace onboarding intent and Concierge follow up tasks. Confidence is high.

Recommendation: Fix it with a small change in one file instead of reverting. Keep DeployBlockerCash.

Step 6 is intended behavior. The magic code step returning matches how the PR was designed. Product should confirm this is acceptable.
Step 7 is a bug. The PR added a new way into the private-domain screen but didn't update that screen's Back button.

Root cause

Submitting a private-domain work email with no existing account sets shouldValidate = false. Skipping the code doesn't clear it.
Choosing "Join my company workspace" with an unvalidated private-domain email opens the private-domain (magic code) screen with backTo = onboarding/purpose (BaseOnboardingPurpose.tsx:134-146). The comment at lines 130-133 and Test 3 in the PR say this is intended. That explains step 6.
The screen's Back handler checks shouldValidate === false before it checks backTo (BaseOnboardingPrivateDomain.tsx:110-118). Because of that, it calls updateOnboardingValuesAndNavigation, which always goes back to the work email step (Welcome/index.ts:101-110). That explains step 7.

Suggested fix

In handleBackButtonPress, let backTo === ROUTES.ONBOARDING_PURPOSE.getRoute() take priority over the shouldValidate === false branch. Then Back returns to the intent list. Add a UI test for this case.

Investigation details

Same feature, landed twice. The causing PR restores Add the join-workspace onboarding intent and Concierge follow up tasks plus two follow-up PRs, which an earlier PR had reverted. Another revert would remove the whole feature again. It isn't on production, so a revert is safe if you prefer it.
Unchanged handler. The Back handler is the same on production. It worked there because the work email step was the only way into the screen.
Nothing resets the flag. clearOnboardingMergeAccountBlocked on the Join path clears only the merge-blocked flag, not shouldValidate.
Other PRs ruled out. The other onboarding and navigation PRs in the Deploy Checklist: New Expensify 2026-10-14 don't touch this Back logic or the Join routing.
Main has the same code. main still has the bug.

Draft fix:

const handleBackButtonPress = useCallback(() => {
    const backTo = route.params?.backTo as Route | undefined;
    if (onboardingValues?.shouldValidate === false && backTo !== ROUTES.ONBOARDING_PURPOSE.getRoute()) {
        updateOnboardingValuesAndNavigation(onboardingValues);
        return;
    }
    Navigation.goBack(backTo ?? ROUTES.ONBOARDING_PERSONAL_DETAILS.getRoute());
}, [route.params?.backTo, onboardingValues]);

Confirm that backTo from the route equals onboarding/purpose exactly, or pass an explicit route param instead.

Not tested. I found this by reading the code and didn't reproduce it in the app. After the fix, check two flows. First, steps 1–6 and then Back should open the intent list. Second, work email → Add → private-domain screen → Back should still open the work email step.

view run

On it

I believe steps 6 is expected

@jponikarchuk

17. I believe steps 6 is expected

That is correct. cc @jponikarchuk

@abzokhattab

@abzokhattab

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.12-1 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

Fix blockers related to join workspace #104070

If no regressions arise, payment will be issued on 2026-10-23. 🎊

The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]

Navigation Menu

Repository navigation

[Due for payment 2026-10-23] Join my company workspace - Magic code step reappears after skipping, wrong back navigation #104061

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Deploy Blocker Investigation

Root cause

Suggested fix

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Due for payment 2026-10-23] Join my company workspace - Magic code step reappears after skipping, wrong back navigation #104061

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

applause-bot commented on Oct 15, 2026

melvin-bot commented on Oct 15, 2026

melvin-bot commented on Oct 15, 2026

melvin-bot commented on Oct 15, 2026

melvin-bot commented on Oct 15, 2026

github-actions commented on Oct 15, 2026

MelvinBot commented on Oct 15, 2026

Deploy Blocker Investigation

Root cause

Suggested fix

hungvu193 commented on Oct 15, 2026

hungvu193 commented on Oct 15, 2026

carlosmiceli commented on Oct 15, 2026

melvin-bot commented on Oct 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions