FixControl/Documentation

User Guide

Switching workspaces

One account, several workspaces — how switching works, what it changes for your other tabs, and why a switch can be refused.

You can ask for this instead of navigating to it. Ask Command Center "which workspaces do I have?" and it gives the same answer this switcher does — every workspace you may enter, your role in each, which is active and which can be switched to — and it can switch you, behind a confirmation card, because the switch moves every open tab. It spends from the same rate limit the switcher does, so asking is not a faster way to guess at names.

First: two meanings of "workspace"

FixControl uses the word twice. On this page, a workspace is a separate FixControl environment with its own issues, agents, inbox, knowledge base, and audit log — the kind of thing the switcher at the top of the sidebar lists. The other meaning is the agent chat session in which you explore a codebase and receive patch proposals; that one is described in Workspace.

Home workspace and active workspace

What it is
Home workspaceWhere your account lives. You land there every time you sign in, and your two-factor enrollment is stored against it (you can still set it up from any workspace).
Active workspaceThe one your session is scoped to right now. Everything you see — issues, inbox, agents, knowledge — belongs to it.

They are the same workspace until you switch, and they become the same again the next time you sign in.

One account, several workspaces

You sign in once, with one email and one password (and one two-factor enrollment). Access to a workspace is a membership, and each membership carries its own role: you can be an admin in one workspace and an operator in another. The switcher shows the role you hold in each entry, so you can see before you click what you will be able to do once you are there.

What never travels between workspaces is data. Switching does not merge, copy, or expose anything across workspaces — it only changes which one you are working in.

Notifications belong to a workspace

The bell and the Notifications page show the notifications of the workspace you are in: an approval, a run or a preview in another workspace is listed there, not here, so clicking a notification always opens something you can see. When you have unread notifications in another workspace you can switch to, the bell and the Notifications page say so — "N unread in <workspace> · Switch" — so nothing waits unnoticed.

How to switch

The workspace switcher sits at the top of the sidebar and shows the workspace you are in now. Open it and you get Switch workspace: every workspace you may enter, with its role, and a Home marker on your home workspace.

Pick one and three things happen:

  1. Your session is re-scoped on the server — the switch is a real change, not a label.
  2. The page does a full reload, so nothing from the previous workspace stays on screen or in memory.
  3. You land on the dashboard, not on the page you were on. The page you came from likely referred to an issue, project, or agent that only exists in the workspace you just left.

While a switch is in flight the list goes inert and the switcher shows Switching… — one switch at a time, so the answer always applies to the workspace you clicked.

A switch applies to every open tab

Your session lives in one cookie that every tab of that browser shares. Switching in one tab therefore changes the workspace in all of them: the other tabs reload themselves, and a tab you left in the background reloads when you come back to it. The switcher says so, permanently, underneath the list.

There is deliberately no way to keep one tab in workspace A and another in workspace B. A single session can have only one active workspace, and pretending otherwise is how work ends up in the wrong place.

Workspaces you cannot open

A workspace that is blocked or being deleted is still listed, greyed out, with the reason next to its name. It stays visible on purpose: a disappearing entry would read as "I lost my access", when the truth is that the workspace itself is unavailable.

Why a switch can be refused

A workspace you cannot enter is greyed out in the list with the reason beside its name — Being deleted for one whose deletion is scheduled, Blocked for one that is frozen. A switch that fails for a reason the list could not show in advance puts the refusal in the panel instead of failing quietly.

What you seeWhat it means
You are not a member of that workspace.There is no membership for you there (any more). Ask a FixControl platform administrator.
That workspace is blocked.It has been frozen. It can be unblocked by a FixControl platform administrator.
That workspace is being deleted.It is scheduled for deletion and can no longer be opened.
Your session is no longer valid for that workspace.Your sessions were revoked, or the session is too old. Sign in again.
That workspace requires two-factor verification.The target workspace requires two-factor authentication and this sign-in has not proven it. Sign in again and enter your code.
That workspace requires two-factor authentication. Set it up first.You have no two-factor enrollment yet. Set it up under Settings → Security — you can do that from whichever workspace you are in — then switch.
Your account is inactive.Your account has been deactivated. Contact an administrator.
Too many switches in a short time.Wait a moment and try again.
The request was blocked for security reasons.A stale or cross-site request. Reload the page and try again.

Switching does not extend your session

A session lasts 24 hours, counted from when you signed in — a fixed length, not a setting. A switch re-scopes that same session: the clock keeps running, and the switch never gives you a fresh 24 hours. For the same reason a switch cannot get you past a revocation — when an administrator revokes your sessions, you are signed out of every workspace at once, and switching is refused rather than used as a way back in.

Two-factor and workspaces

Two-factor enrollment belongs to your account, not to a workspace. You set it up once, under Settings → Security, from whichever workspace you happen to be in; the enrollment is stored against your account (in your home workspace) and counts everywhere you switch to. If you lose your authenticator, a FixControl platform administrator resets the enrollment for you.

The requirement is per workspace: a workspace can require two-factor authentication of everyone who enters it. If the workspace you are switching to requires it and your current sign-in has not proven it, the switch is refused and you sign in again with your code. If you have not enrolled at all, enroll first and then switch — you do not have to go back to your home workspace to do that.

Creating a workspace

If you are an admin of the workspace you are in, you can create another one for yourself. Open the switcher, follow Manage workspaces, and use Add tenant on that page (the overview still calls a workspace a tenant — the same thing under its older name).

  • Name only. A workspace you create this way starts on the free plan; plan, environment, and domain are platform settings and are not offered here.
  • You become its admin, with a membership in the new workspace. It appears in your switcher immediately.
  • Your home workspace does not move. Creating is not switching — you stay where you are until you switch to it.
  • Names are unique. If a workspace with that name already exists, creation is refused and you pick another one.
  • Two-factor applies. Creation requires a two-factor-verified session where your workspace requires it.
  • There is a limit on how many workspaces one account may create. When you reach it, creation is refused with a message saying so; a FixControl platform administrator can create further workspaces.

If you do not see the option, you are not an admin of the workspace you are in. Ask an admin of this workspace, or your platform administrator.

Settings your workspace makes for itself

Most of FixControl is configured once for the whole deployment by whoever runs it. A short list is deliberately yours: five settings your workspace can change for itself.

Four of them are in Settings → Overview & progress, in the panel Settings for this workspace. The panel is shown to admins and managers; other roles don't see it.

SettingWhat it decidesDefault
Investigate failures inside the test environmentWhen a check fails, let FixControl look around in the environment it failed in before writing the next attempt. Adds about a minute to a run that already failed.Off
Let people open a running previewA private, expiring link to a running copy of the application with a proposed change in it, so a reviewer can click through before approving. Nothing starts by itself: someone has to start the preview.On
Work out how an application runsLet FixControl read a repository and find out how to build and start it, instead of waiting for someone to write that down.On
Language for messages sent outside the appWhat FixControl writes in when it composes a message outside the app — approval cards in Slack or Teams, approval emails, mission status posts. A ticket that arrives in another language keeps that language, and in the app everyone follows their own language picker.English

The fifth is not in the panel and can only be changed through Command Center:

SettingWhat it decidesDefault
Investigating inside a running previewLet FixControl run a small, limited number of commands inside a preview that is already running — read the configuration the application actually loaded, re-run one test with more output, query the preview's own database — instead of reasoning from a log. Every command and its output is recorded. It never starts a preview by itself.Off

The defaults shown here are FixControl's own; whoever runs your deployment can change a default, and the panel always shows the one that applies to you ("The default is …").

Each row in the panel says where its value comes from, and the distinction is not cosmetic: Following the default means your workspace tracks the deployment-wide value and will move with it; Set by this workspace means you have a value of your own, which stays put even when the default changes. Use the default again hands the setting back.

Admins and managers can change these, behind the two-factor wall, and every change is audited with the value before and after. Anything not on this list is the deployment's, and FixControl says so rather than showing you a control that would be refused.

You can ask for these too. "Turn on reproduction sessions", "let people open a preview", "what does this workspace have set?" — Command Center reads and writes exactly these five, on a card that states the consequence before you confirm.

Getting access to somebody else's workspace

A FixControl platform administrator adds your membership to that workspace and sets the role you hold there. Invitations are not self-serve yet: there is no in-product flow to invite yourself or a colleague into another workspace, so ask your platform administrator through your usual support channel.

That is a different thing from adding a colleague to the workspace you administer — that is user management inside your own workspace, under Settings → Users.

  • Workspace — the agent chat session (the other meaning of the word).
  • Users & identity — roles, memberships, and user management for admins.
  • Security & audit — sessions, revocation, and two-factor policy.
Anything unclear or wrong?Let us know →

FixControl is a trade name of FixControl B.V.