Manage projects, workspaces, and roles
Understand project scope, workspace membership, role boundaries, and the agreement required for project creation.
3 min read
- Dashboard
- Projects
- Account menu
Choose the project first; workspace membership and role management are available from the account and workspace controls for that project.
A workspace is the access boundary for a group of people and its projects. A project belongs to one workspace and contains the website domain, agents, knowledge, usage, and visitor-facing settings for that deployment. Select the workspace and project deliberately: membership in one workspace does not grant access to another.
Start with the boundary: workspace membership gives access; the selected project, role, plan, and feature availability determine what a person can actually do.
- Finish with
- The right workspace, project, and role for the task
Create or choose a project
Choose the owning workspaceOpen Projects, select Create project, and choose the workspace that should own it.
Membership in one workspace does not grant access to another.Name the project and confirm domain authorityEnter the project name and website domain, then make the authority attestation.
This covers the project domain, not permission to crawl every URL later.Accept the project agreement packageAn authorized owner or administrator reviews the current linked documents for this project.
The acceptance is recorded for this project and the workspace it belongs to. Creating another project requires a fresh unchecked acceptance.Choose the project subscriptionSelect Free or complete the offered paid checkout.
Paid access begins only after verified provider confirmation.Finish the first launchAdd knowledge, configure an assistant, test it, and install it.
Use the quickstart for the full launch path.
An owner or administrator accepts the current package for each project they create. A member who cannot accept it must wait for an owner or administrator. Acceptance for one project does not approve another project, even in the same workspace.
Role boundaries
| Workspace role | Typical customer-facing access | Important boundary |
|---|---|---|
| Member | Use projects made available through the workspace and perform permitted day-to-day work. | Cannot make owner/admin-only changes such as retention or widget privacy-disclosure settings. |
| Administrator | Operate workspace-restricted project settings and approve applicable workspace actions. | Access remains scoped to the active workspace and project. |
| Owner | Has administrator-level operational access and can accept a required project agreement package. | Ownership is not a substitute for website authority, privacy obligations, or plan availability. |
Exact visibility can also depend on the project’s enabled capabilities and plan. Do not treat a visible page as proof that every action on it is permitted.
Limitations
- Workspace roles do not merge data or configuration between projects.
- A project cannot proceed to subscription selection until an authorized creator confirms domain authority and accepts the current project agreement package.
- Internal platform administration and commercial-catalog management are not customer workspace functions.
Last updated on
Account and project administration
Find the customer-facing controls for projects, workspace access, usage, privacy settings, and legal information.
Configure project settings and domain authority
Update a project’s general, contact, AI, and domain settings while preserving deployment and authority boundaries.