DataMosaicDocs · Concepts
Workspaces and roles
What a workspace contains, what it does not, and what each of the four roles can do.
A workspace is a container for work that belongs together — a team, a department, a migration. Most people need one. You switch between them from the top bar, and switching reloads the page.
#What belongs to a workspace
Checks and everything under them, apps, environments, integrations, and the library — its data sources, collections and variables. Business Locations and the agreed meanings of columns belong to the workspace too.
Things underneath a Check — its data sources, aggregations, parameters, triggers and investigations — do not carry a workspace of their own. They inherit it through the Check they belong to.
Three settings are per workspace and worth knowing about:
- Time zone. The calendar this workspace keeps. It decides the hour a schedule fires, what
TODAYandYESTERDAYmean inside a query, which day a run counts towards on the Overview, and the times shown beside a run. - AI. Off by default, and off for everybody until an owner turns it on.
- Retail Pack, where the licence includes it.
#What does not belong to a workspace
Accounts. A person exists once per installation, and holds a role in each workspace they can reach. The People screen says so plainly: "Roles apply to this workspace only. Disabling an account, or listing everybody on this installation, would reach into workspaces you may not be able to see, so neither is done from here."
The licence. It covers the installation. A workspace does not have its own plan.
The database file. One file holds every workspace.
#The four roles
Roles run weakest to strongest, and each includes everything below it.
| Role | What it adds |
|---|---|
| Viewer | Reads everything in the workspace — and runs it |
| Editor | Changes definitions: Checks, data sources, aggregations, parameters, investigations |
| Admin | Distribution and shared credentials: publishing, triggers, environments, integrations, systems, the library, API keys, people |
| Owner | The workspace itself, the licence, accounts, and the AI switch |
Two boundaries are worth understanding, because they are deliberate and they surprise people.
Running is a viewer's right. A viewer can run a Check, an aggregation, a data source or an investigation, and can export the result. The reasoning is that a person who is allowed to read last night's answer is allowed to ask for tonight's.
Testing a connection is an editor's. Editing a data source means choosing the SQL that runs against a production database — which turns may read this Check into may read anything that credential can reach. That is why editing sits a rung above reading, and why a viewer cannot open a connection even to test it.
Triggers are admin-only to create or change, because a trigger is a standing instruction to move data out of Mosaic — to a file, a mailbox or an endpoint — rather than an edit to a Check. Reading the list of triggers is a viewer's right.
Marking a difference as known is a viewer's. It is a note a reader leaves, not a change to a definition.
#API keys
An API key carries a role, and that role is capped: never more than an editor, whatever the person issuing it can do. Two choices, labelled for what they permit rather than by role name:
- Run and read
- Run, read and edit
A key runs Checks and reads what they found. It can never publish one or reach the integrations.
#Switching and creating
The switcher in the top bar lists every workspace your account can reach, ticks the active one, and offers New workspace at the bottom. Creating one asks only for a name — the placeholder suggests the shape: Finance, Retail operations, Migration…
Renaming and deleting a workspace are the owner's.