How Your Active Workspace Is Chosen

Once you belong to more than one workspace, such as your own plus a client's or an agency's, every invoice, client, and report you see depends on which workspace is active. Choosing it isn't a single setting stored somewhere. The server works it out again on every request, and the rules for doing so explain a few things that might otherwise look odd.

The Workspace Switcher Sets a Value in Your Browser

When you pick a workspace in the switcher, the app saves its ID in your browser. From then on, every request the app sends to the server includes that ID in a header. The server never assumes you're allowed to use the workspace you named. It checks the membership table for a row linking your user to that workspace. If there is one, the request runs in that workspace with the role from that row: admin, member, or accountant. If there isn't, the request is refused with "You are not a member of this workspace."

This check happens on every request, not just when you switch. Your role is never saved in your session either. It's read from the membership table each time, so if an admin changes your role, the change applies to your next request without you signing out.

The Default When You Haven't Chosen One

If no workspace is selected, for example on your first visit, in a new browser, or after signing out (which clears the selection), the server chooses one. It looks at all your memberships and ranks them by role: admin first, then member, then accountant. If you're admin in more than one workspace, it picks the one you joined earliest.

The ranking is by role on purpose. Sorting role names alphabetically would put "accountant" before "admin", which would drop an admin into a workspace where they have read-only access and make it look as though their permissions had disappeared. Ranking by role means the default is the workspace where you can do the most, which for most people is their own.

A Missing Workspace Is Created Automatically

Every account gets a personal workspace at sign-up. If an account ends up with no memberships at all, for example after its only workspace is removed, the server doesn't fail. On the next request it creates a new "Personal Workspace", makes you its admin, and continues. You'll never be signed in with nowhere to put your invoices.

When You're Removed from the Selected Workspace

If an admin removes you from the workspace your browser has selected, your next request using that saved ID fails the membership check and is refused. The server doesn't silently move you to another workspace, because quietly showing you different data could be confusing. Switch to another workspace in the switcher, or sign out and back in to clear the selection. The default rules above then choose a workspace you still belong to.

A Deleted Account Can't Keep Using an Old Session

Session tokens are signed and checked without a database lookup, so in principle a token stays valid for its full hour even if the account behind it is deleted. To close that gap, workspace-scoped requests also check that the user still exists. If it doesn't, the request is refused with a prompt to sign in again, even though the token itself is still valid.

API Keys Belong to One Workspace

Developer API keys don't use the switcher. Each key is created inside a workspace and permanently tied to it, and requests made with that key run with admin rights in that workspace. To automate more than one workspace, create a key in each. Unlike your own sign-in, one key can't reach every workspace you belong to.

In Short

The workspace you select is sent with every request and checked against your memberships each time. With nothing selected, you land in a workspace where you're admin, preferring the earliest one you joined. Role changes take effect immediately, removal blocks the next request instead of silently moving you, and an account always has at least one workspace.