Your workspace
What every application in it shares — the domain, the design systems, the people, the user directory and, if you want it, one set of records — and how to be in more than one.
A workspace is your organisation: its people, its applications, its domain and its brand.
Four things are shared by every application in it, and they are the four that would otherwise be re-specified one application at a time. A fifth — the records themselves — is shared only if you ask for it:
| The domain | Set it once and every application becomes a subdomain of it — crm.acme.com, portal.acme.com — with nothing to do per application. See Addresses and domains. |
| The design systems | Your brand, authored once and available to everything built here. See Your own design systems. |
| The people who build | Who can create, direct, deploy and delete, with a role each. See People and roles. |
| The people who sign in | One directory, under Users, behind every application here. Optionally one login across all of them. See People who sign in. |
| Records, if you ask | Applications keep their own unless you put two of them on one store — a portal and a back office over the same customers. See Where records live. |
A workspace per client#
If you build for clients, use one workspace per client. Their brand, their domain, their colleagues and their applications' own users are all separate from every other client's, and nothing of one is visible from another.
It is also the unit that spend is reported against, so a client is a clean line in that too.
One account can be in several. Somebody working across three clients switches between their workspaces from one sign-in, and holds a role in each — an owner of their own, a builder in one client's, a viewer in another's. See More than one workspace.
The rest of this section#
People and roles is the one to read first — roles govern the builder as well as the buttons. More than one workspace is for anybody building for more than one business. Where records live is worth reading before two applications need to be about the same customers. Organising applications matters once you have more than a dozen. Your own design systems is how your brand, or a client's, gets into the applications you build. Your profile is short.
- People and rolesThree roles, what each can do, how they apply to the builder as well as to the buttons, and why they belong to a workspace rather than to an account.
- More than one workspaceBelonging to several, switching between them, the role you hold in each, and why nothing crosses over.
- Organising applicationsFolders on the dashboard, and how to keep a growing list navigable.
- Your own design systemsAuthoring a design system for your brand, or a client's, by importing guidelines, a website or a Figma library.
- Your profileYour name, your password, your picture, and the theme.
- Where records liveOne store per environment, one across an application's environments, or one the whole workspace shares — what each costs you, and how to change it.