Skip to main content
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. 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 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.
Start with the smallest boundary that will be used repeatedly. You can create more Projects as the organization grows.