Guides

Work as a team

Create a workspace, invite people, publish into it, and share one warehouse connection without hitting the scope trap that publishes a dead dashboard.

A workspace gives a group of people a shared URL prefix, shared dashboards, shared folders, and one shared warehouse data source.

Create a workspace

Open Settings, then Workspaces, and create one. You become its admin automatically.

You choose the slug, and it becomes the subdomain your team's dashboards live at: https://<workspace-slug>.dashies.ai/<slug>. It must be 2 to 63 characters of lower-case letters, digits, and hyphens, and may not start or end with a hyphen.

Workspace slugs and user handles share one namespace

A workspace cannot be named after any existing user handle, including your own. The refusal is:

slug already taken

This is the most surprising failure in workspace creation, and it is not a bug: <label>.dashies.ai has to resolve to exactly one thing, so a handle and a workspace slug cannot both claim it. Sixteen infrastructure labels such as www, api, and docs are also reserved.

Roles

There are three: Admin, Creator, and Viewer. An admin picks the role when inviting someone. A viewer reads every dashboard in the workspace and publishes none; the table below is about admins and creators.

Creator is member on the wire, in the API and in the audit log. The app names it after the seat it spends, because an admin and a creator both hold a creator seat and only one of the two said so.

Anyone in the workspace	Admins only
See the member list	Invite, change a role, remove someone else
Publish and republish workspace dashboards	Rename the workspace, change its logo, delete it
Restore and label a workspace dashboard's versions	Manage the workspace plan
See and edit the shared folder tree	Manage security: SSO, email domain, SCIM, audit
Author against a workspace data source	Delete, rotate, rename, resync, or re-test a workspace data source

Leaving is an admin action too. A member cannot remove themselves; ask an admin to remove you.

You cannot demote or remove the last admin. Both refuse with cannot_demote_last_admin or cannot_remove_last_admin. Promote someone else first.

Invite people

Settings, then the workspace's Members section. Invitees get a sign-in link by email and land already added.

The result tells you which of four things happened:

Result	Meaning
`invited`	We created an account for them and added them.
`added_existing_user`	They already had a Dashies account. Added.
`already_member`	Nothing to do.
`added_no_link`	The membership exists but the link could not be minted. Re-invite to retry.

Sent is not the same as delivered

A successful send means the email service accepted the request. It does not confirm the message reached an inbox. "I invited them and nothing arrived" is a delivery problem, not a membership problem: check the member list first, because they are almost certainly already a member and can just sign in normally.

Invites are rate-limited per email address, at roughly one a minute. Past that you get Too many invites - wait N s. Re-clicking does not help, so wait.

The member list also shows a last sign-in time. That is the last sign-in, not the last activity, so a colleague using Dashies daily on a long-lived session will show an old date. An empty value means an invited account that has never been used.

Publish into a workspace

Your AI needs to be told which space to publish into. Two ways:

Pass the workspace slug on the publish, which your AI does when you say so:

Publish that dashboard into the acme-analytics workspace.
Or authorize a connection that is locked to that workspace, on the consent screen. See Sign in and authorize.

A workspace dashboard is visible to that workspace's current members, and there is nothing to set: where it lives decides who can open it. Getting a dashboard into a workspace is the only way to let anyone but yourself read it, whether you publish it there or move an existing one in. See Share a dashboard.

Any member may republish a workspace dashboard, including one they did not create.

This is the part that goes wrong most often, so it gets the most space.

A data source belongs permanently to the pair of who created it and which workspace they created it in. Neither half can be changed afterwards, and there is no move path in either direction. The reasoning is in scope is an immutable pair.

Once it exists in a workspace:

Any current member with a creator seat can use it, whoever created it, to author dashboards and bind them to it. A member with a view-only role cannot read its schema or run queries against it; their AI tool is told that a creator seat is needed and that a workspace admin can change their role. The full permission split is in what you can and cannot do with a connection. Current membership is required with no exemption for the creator, so someone removed from the workspace stops being able to author against the team's warehouse.
The creator, or any current admin, can change it: delete, rotate, rename, resync, or re-test.

A data source cannot back another workspace's dashboard

To use a warehouse on a workspace's dashboards, create it from inside that workspace. Open the workspace first, then add the data source. It cannot be moved to another workspace later. Full explanation: the workspace trap.

The refusal you hit if you get this wrong is:

source_config.connection is not an active warehouse connection available to this dashboard

That message is deliberately identical for an unknown id, an inactive data source, a non-warehouse one, and a wrong-scope one, so it cannot be used to probe what exists. If the id came straight out of your own connection list and the data source is active, scope is the only remaining explanation, and the fix is to publish into the data source's own workspace, or to point the dashboard at one created in the space you are publishing into.

If the message instead says the connection is not active, that is a different problem with a different fix: test it in the web app. Changing scope will not help.

On a spec publish, the wrong scope does not stop the publish

This is the worst version of the trap, because everything looks like it worked.

The SQL validates, the seed runs against that very data source, and the dashboard is written and live at a real URL. Only the refresh manifest is refused, leaving a live dashboard that can never update. Your AI sees refresh installation failed plus a sentence naming the mismatch.

A dry run does not catch it either. A dry run stops before the manifest is installed, so a clean dry run is not evidence the data source is bindable in the space you are publishing into.

How to catch it: after publishing into a workspace, check the dashboard has a schedule and a next run. See the check at the bottom of this page.

One more surface that reads oddly until you know why: listing your data sources without naming a workspace comes back empty, however many you have. That list was the personal scope's, and there is no personal scope any more, so it has nothing left to return. Name the workspace instead.

Two different empties meet here, and they mean opposite things. An unscoped list is empty because the scope it described is retired. A non-member asking for a workspace's list is empty because we refuse to confirm whether that workspace has any data sources at all, which is the same anti-probing reason the binding refusal is worded like an unknown one.

Plans in a workspace

The plan that applies is the plan of the workspace you are working in, not the best plan you can reach from it. See what is gated.

So a free user who is a member of a paid workspace is entitled inside that workspace and nowhere else. Nothing in another workspace that has not paid starts refreshing. Adding someone to a paid workspace gives them that workspace's plan while they are in it, and nothing beyond it.

Teams inside a workspace

A team is a group of people inside a workspace with a name, a description, a colour, and a screen of dashboards. Find them at dashies.ai/app/teams.

The important property: a team screen references dashboards, it does not contain them. Removing a tile from a team screen removes the reference, never the dashboard. One dashboard can appear on any number of team screens.

A team is either open, visible to every workspace member, or private, visible only to its own members. Open is the default.
Team membership is a subset of workspace membership, enforced by the database. Removing someone from the workspace removes them from every team automatically.
Team names are scoped to the workspace, so two workspaces can each have a sales team.
A private team whose last member leaves stays visible to workspace admins, so it is always recoverable.

Check it worked

The member sees it. Ask a colleague to open the workspace dashboard URL. Your own view proves nothing, because you are a member too.
The refresh is actually installed. This is the check that catches the scope trap:

What is the refresh status of the <slug> dashboard in the acme-analytics workspace?

A working dashboard reports a schedule and a next run. A dashboard that published fine but reports no schedule and no next run is the scope trap, and the page will never update. Recreate the data source inside the workspace and republish.
The data source is visible to the team. Have another member list the workspace's data sources. If they see nothing, either they are not a member or the data source belongs to a different workspace.
Confirm the last admin is safe. Removing the only admin of a workspace is refused, so check there are at least two before removing anyone with that role.