# Self-Service Switching Exposed Every Place Identity Was Guessed > Moving between ZopNight, zopcloud, and ZopDay used to mean logging out of one and back into another. A new switcher in the sidebar removes that entirely, letting a person move between all three… Source: https://zop.dev/resources/blogs/sidebar-product-switcher-nearly-stranded-zopcloud-users Published: 2026-09-22 · Author: riya-mittal · Tags: platform-engineering, self-service, zopcloud --- Moving between ZopNight, zopcloud, and ZopDay used to mean [logging out of one](https://zop.dev/resources/blogs/centralized-sign-in-remembers-your-product-per-email) and back into another. A new switcher in the sidebar removes that entirely, letting a person move between all three without ever seeing a login screen again. [zopcloud switches in place](https://zop.dev/resources/blogs/idle-services-vm-sleep-and-wake) rather than opening as a separate app, since it's really a view of ZopDay, and it now carries its own green identity mark everywhere it appears. Adding that one control did not stay contained to the sidebar. It touched every screen that had been quietly assuming a user's product context only ever changed through a full page reload, and two of those assumptions broke in ways serious enough to need same-release fixes. ## Hiding a Nav Section Doesn't Move You Off the Page It Led To The first bug was reported straight from a live environment. The navigation correctly drops the Infrastructure section for a zopcloud user. What it didn't do was move a user who was already sitting on an Infrastructure page, Provision button and all, off of it. That page kept rendering in full, with no navigation entry left anywhere on screen to get back to anything else. The zopcloud identity, the switcher, and the nav-hiding logic had shipped together without anyone also handling the case of a user already standing on a surface that had just been pulled out from under them. The fix deliberately lives in the route guard itself, not in the switcher's own selection logic, because switching through the sidebar is only one of four separate ways a person can land on that page. Architecture diagram A bookmark, a shared link, and a plain page reload can each land a zopcloud user on that same restricted page with no switch action involved at all, so fixing the switcher alone would have left three of those four paths completely unprotected. The guard itself uses a prefix match against the whole route family rather than an enumerated list of specific pages, which means a seventh route added under that path later stays covered automatically instead of needing to be remembered and added by hand. ## A Route Guard's Signal Isn't the Question It's Answering The second bug hit ZopDay's [setup wizard](https://zop.dev/resources/blogs/self-service-terraform-8-modules-60-percent-platform-tickets), which had started forcing itself on every visit instead of only appearing for a genuinely new organization coming out of onboarding. The fix restores the original behavior: the wizard is reachable from onboarding again, and the /setup route stays directly reachable on its own. | What the guard actually checks | What it was being used to mean | Where that broke | |---|---|---| | Does this org have an active cloud account | Is this a first-run user | An org whose accounts went inactive, failed, or were archived reads as brand new | | Has this browser dismissed the wizard before | Has this specific person seen this specific org's wizard | Dismissing it in one org silences it in a different org on the same browser that still needs it | The underlying problem is that a query filtering on active-status accounts answers a narrower question than the one it was standing in for. An organization can have zero rows matching status equals active for entirely legitimate reasons that have nothing to do with being new. Onboarding, by contrast, knows something a route guard structurally cannot reconstruct after the fact: that this exact organization was created by this exact person, right now. ## A Dismiss Flag Scoped to the Wrong Thing The second half of that same bug came from where the wizard's own dismissal state lived. It was stored per browser rather than per organization, so a person who dismissed the wizard once while working inside one organization found it silently gone in a second, unrelated organization on the same machine that genuinely still needed to show it. A flag meant to represent "this specific org's setup has been seen" was actually representing "this browser has seen a setup wizard at some point," which is a different and much less useful fact. One case was named explicitly in the fix rather than quietly absorbed into it: someone who creates their organization through ZopNight's own onboarding, then picks ZopDay at the product picker, never passes through ZopDay's own onboarding flow at all. Properly closing that gap needs a signal scoped to a specific person and a specific organization together, not a route guard operating on either alone, and the release notes are explicit that this one remains open rather than claiming it's handled. ## What Stayed Deliberately Unchanged A short, explicit list of things this fix left alone is itself part of the release: the DEFAULT_AFTER_CREATE constant still points to /setup, the branch that redirects an org with no cloud accounts into onboarding is untouched, /setup remains a directly reachable route on its own, the zopcloud infrastructure guard from the first bug fix stays exactly as it was, and the existing useHasCloudAccounts hook keeps its current behavior. Naming what wasn't touched is as useful to a reader as naming what was. It tells the next engineer working in this area exactly which assumptions are still load-bearing and which ones were the actual site of the bug, rather than leaving them to rediscover that boundary by breaking it again.