Workspace fundamentals
A workspace holds one set of AI systems: the workflows you build and the resources they use — tables, files, knowledge bases, integrations, and secrets. It also decides who sees them. Every resource belongs to exactly one workspace, and only that workspace's members can access it. A workflow in one workspace cannot read a table in another.
Think of a workspace as a project folder for AI systems. Open it and everything one team needs is in one place: the procedures, the data, the connected accounts, the run history, and the settings.
What a workspace contains
The sidebar is the map of a workspace. Each section is one kind of resource:
Workflows
A workflow is a saved, repeatable procedure made of blocks: the primary resource in a workspace. You edit it, deploy it to surfaces like an API or a chat, and version it. See Workflows for the full model.
Tables
A table is structured data in the workspace, used as a source or an output inside workflows.
Files
A file is a document or binary stored in the workspace, readable by workflows and organized into folders.
Knowledge bases
A knowledge base is a collection of documents or structured data that workflows search to give a model context at run time.
Integrations
An integration is a connected account for a third-party service (Gmail, Slack, GitHub, and so on). Each carries its own access control, so a team shares one connection. See Integrations.
Secrets
A secret is an API key or environment variable stored securely in the workspace. Secrets come in two scopes: Workspace secrets are shared with the workspace, and Personal secrets are private to you. See Secrets.
Logs
A log is the execution trace of one workflow run: the trigger, the blocks that ran, and each block's input, output, and error. Logs are how you verify what happened.
Deployments are not a sidebar section. A deployment is a versioned snapshot of one workflow, published for outside use through an API, chat, or MCP server. Editing a workflow does not change a live deployment until you promote the new version, and rollback means promoting an earlier one. See Deployments.
Access and isolation
Everything is scoped to the workspace, so access, settings, and isolation work the same way:
- Access. Membership is per workspace. A member sees every resource in it, at the level their permission allows.
- Settings. Each workspace has its own configuration: integrations, secrets, access control, API keys, and more. The Settings page lists the full menu.
- Isolation. Resources never span workspaces. To reuse a workflow elsewhere, move or copy it into that workspace.
Members join with one of three permission levels: Read, Write, or Admin (the creator is Owner). Read can view, Write can build and run, Admin can also manage members and settings. See Roles and permissions for the full breakdown.
Personal and organization workspaces
Most workspaces are one of two kinds.
A personal workspace lives under your own account. Use it for experimentation and individual work. Your plan sets how many you can create.
An organization workspace (also called a shared workspace) lives under an organization, available on Team and Enterprise plans. You invite members, each with a permission level. Internal members join the organization and count toward its seat total. External members keep their own organization membership and don't use a seat — that's how partners and clients get access. For agencies and enterprises, this is the workspace you hand to the customer: the app they use, own, and maintain.
Plan limits, seat counts, and the internal-versus-external distinction live in Roles and permissions. This page covers what a workspace is, not how billing works.