> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gocromo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Workspaces and Projects

> Understand Cromo's organization and access boundaries, and choose where work should live.

Cromo separates organization-level administration from the context used to do work.

## Workspace

A **Workspace** is the top-level home for an organization or business unit. It contains Workspace members and one or more Projects.

Use the Workspace level to:

* invite and manage members;
* assign the Viewer, Member, Admin, or Owner role;
* manage Workspace settings and billing;
* create, find, and switch between Projects.

A person's Workspace role determines the actions they can perform. Access to a particular Project also requires Project membership.

## Project

A **Project** is the working boundary for a team, initiative, client, or operational area.

A Project can contain:

* chat conversations and shared references;
* Sources, Knowledge pages, reviews, and the Knowledge graph;
* data models, tables, records, and team files;
* Dashboards;
* Process Skills;
* Workflows, triggers, and run history;
* integrations, MCP connectors, members, and settings.

Project context is intentionally scoped. Chat, Knowledge, Data, and automations operate within the active Project.

## Choose a useful boundary

Create a separate Project when the work has its own people, sensitive context, systems, or operating processes.

| Create one Project when…                  | Create separate Projects when…                        |
| ----------------------------------------- | ----------------------------------------------------- |
| The same team needs the same context      | Different teams should not see the same records       |
| Sources and processes are closely related | Each area has distinct policies or integrations       |
| Data and workflows should interact        | Automations must have different owners or permissions |
| A shared Knowledge graph is useful        | The same term means different things in each area     |

For example, **Customer Operations** can include renewals, escalations, and service policies if one team manages them together. **Internal IT** should usually be separate because its Sources, members, and automations serve a different purpose.

## Membership and roles

Workspace roles are cumulative:

* **Viewer** can use chat and read Project content.
* **Member** can contribute Knowledge and Sources, work with Data and Dashboards, use connectors, and build or run automations.
* **Admin** can also manage members, settings, connectors, and Dashboard deletion.
* **Owner** has every permission, including billing management.

A Workspace Admin can add existing Workspace members to a Project. Removing someone from a Project removes their access to that Project without removing them from the Workspace.

See [Roles and permissions](/reference/roles-and-permissions) for details.

## Naming Projects

Prefer a name that describes the operating area, not a temporary task:

* Customer Operations
* Supplier Management
* Sales Enablement
* Security Reviews

Avoid names such as “Test,” “New Project,” or a single one-off ticket. A stable boundary makes Knowledge and automation easier to maintain.

<Tip>
  Start with the smallest boundary that will be used repeatedly. You can create more Projects as the organization grows.
</Tip>