Workspaces

What lives in one

Documents and tables, and nothing else. The workspace has two views: its files, which is everything uploaded to it, and its tables, which is every question you have asked of those files. A table can only see documents in its own workspace.

Because access is granted per workspace, one workspace is one audience. If a set of documents should be visible to a different group of people than another set, those are two workspaces even when the work is related.

Creating one

Whether you can create a workspace is governed by your role in the organisation, not by anything workspace-level — for the obvious reason that there is no workspace yet to hold a permission. Owners, admins and members can; guests cannot. See team and roles.

A new workspace starts one of two ways, chosen when you create it: readable by everyone in the organisation, which is where the switch starts, or reachable only by you and the organisation’s owners and admins. You hold Manage as its creator, and owners and admins hold Manage on every workspace either way; anyone else reaches it only through a sharing rule.

Getting around one

A workspace has three views — Tables, Bundles and Files — on a control beside the workspace name, so the name says which workspace and the control says which part of it. The name itself is a switcher: it lists the ten workspaces you visited most recently, with all of them a click further on.

Share, at the far end of that header, opens the settings modal at the access tab. It is the way in to the rest of the settings too — the tabs are all there once it is open.

Settings

The general tab holds four things worth knowing about:

• Name. Editable, and it should be unique — the workspace switcher and the usage breakdown both identify a workspace by name, and two called “Q3” are indistinguishable in both.
• Created by and created on. Fixed, and useful for exactly one question: whose workspace this was before it was shared.
• Workspace ID. A copyable reference. It is what support will ask for.
• Delete. Final — see below.

The access tab is where sharing rules live, and it is covered separately in sharing a workspace. Editing any of this needs Manage on the workspace.

Deleting a workspace

Deleting is final. It removes the workspace’s tables, bundles, API keys and sharing rules, and every document uploaded to it, and there is nothing to restore afterwards. The dialog asks you to type the workspace’s name before it will go ahead.

Manage is not enough on its own. Only the workspace’s creator or an owner or admin of the organisation can delete it, so someone given Manage by a sharing rule does not see the option.

Nothing about deleting reclaims credits. The reading was paid for at upload and does not come back.

API keys

A workspace can hold API keys, created with a label and an expiry of 30, 60 or 90 days or never, under the same Manage level as its other settings. A key is shown once, at creation, and stored hashed — if you lose it, you create another. What to do with one is the API reference’s subject: a workspace key authenticates the same endpoints a personal key does, but only for the workspace it is bound to.

A workspace key is scoped to this workspace, which is the difference between it and a personal key — a personal key belongs to a person and reaches every workspace that person can, and is created under Integrations → API keys in the app’s settings rather than from here.