Documentation Index
Fetch the complete documentation index at: https://docs.speckle.systems/llms.txt
Use this file to discover all available pages before exploring further.
What are projects?
A project is the main container for shared work in a workspace. Use projects to define collaboration boundaries, access rules, and delivery ownership. This page is for workspace admins and discipline leads defining project structure, but it’s also for anyone needing to find and access relevant work. The projects list helps organisational users navigate to the right project, while each project homepage is for that project’s collaborators to coordinate, manage, and contribute to their shared work.What can a project contain?
A project contains models and their versions. Use models to separate technical content inside that project boundary.Why project structure matters
Project structure affects security, navigation, and reporting quality. If unrelated teams share one project, permissions and issue workflows become hard to manage. If work is split too aggressively, teams lose shared context. Use separate projects when any of these are true:- different teams need different member access
- different clients or contracts need separate rules
- deliverables need separate issue tracking or review schedules
What you can do on the projects listing page

Find projects
Search by name and filter by labels to locate active work fast.
Manage access and rules
Manage visibility, labels, archive state, and collaborator access.
Run bulk changes
Select multiple rows to set labels, archive, or delete in one action.
Open project operations
Use the row menu for per-project actions and settings.
Search and filter
- Use Search projects… when you know the project name.
- Use the Labels filter for category-driven browsing.
- Click label chips in rows for quick filtering.
Manage labels from the list
- Use the + button in the Labels column to assign or remove labels.
- If a row has many labels, open the
+Nchip to view and manage overflow labels.
Create and act on projects
- Use New project when you need a new collaboration boundary.
- Use the row … menu for per-project actions such as archive and delete (permission dependent).
- Archive from the list when a project should stay recoverable but leave active workflows.
- For archive details, see Archive and unarchive projects.
- For visibility, collaborators, share tokens, and automations, see Configuration.
Run bulk actions
Select projects with row checkboxes, or click project rows to select them. The bulk action bar supports:- Set labels
- Archive
- Delete
Project labels
Project labels help you organize workspace projects in a shared, consistent way. Teams usually label by stage, sector, client, office, or delivery status so anyone can filter quickly without memorizing naming conventions.Apply labels to a project

You can set labels only on projects you can edit.
Label many projects at once
Bulk Set labels is available only when the selected projects are editable.
Filter projects by label
Use the Labels filter at the top of the projects list, or select label chips in project rows. When multiple labels are selected, the list shows projects matching any selected label.Where can I change available labels?
Where can I change available labels?
Workspace admins can create and edit available project labels in
Settings → Project labels. Issue labels are managed separately in
Settings → Issue labels. For more details, seeWorkspace configuration.
Who can modify available labels?
Who can modify available labels?
Only workspace admins can change the set of available project labels. Other members
can use labels on projects they can edit, but cannot modify the list of available
labels.
Can labels be project specific?
Can labels be project specific?
No—project labels are shared across the entire workspace. Workspace admins
create a single set of available project labels for all projects in the workspace.
What you can do on a project home page
After you open a project from the workspace Projects list, you land on that project’s home page. Use this page when you need model-level activity, issue state, and collaborator actions for one project.


Project sidebar

- Open Data Validation
- Use Run check for new checks
- Use Checks for saved checks and their results
- Use Project standards for reusable standards
Models list
Open Models in the project sidebar to browse model containers in that project. The models list supports nested structure using/ in model names as a quasi-folder path.
For example, Building A/Floor 01/Architecture appears in a nested tree view.
You can expand or collapse nested groups, then click a model row to open that model.
Versions list
Open Versions in the project sidebar to review published versions in that project. The versions list supports:- Search versions… to quickly find specific versions.
- A table view with key fields such as Version, Model, Author, Created, and Issues.
- Row-level actions from the … menu for version-specific workflows.
Issues list
Open Issues in the project sidebar to manage issue tracking in that project. The issues list supports:- List and detail split view, with issue details opening on the right when you select an issue.
- Filters such as Status, Priority, Assignee, Labels, Model, and Overdue.
- A New issue action for creating new issues in the project.
Intelligence list
Open Intelligence in the project sidebar to review dashboards with content for the current project. The intelligence list supports:- A searchable dashboard list for this project.
- Quick access to create dashboards with Add dashboard.
- Row-level actions from the … menu for dashboard-specific workflows.
Cloud integrations (ACC)
Open ACC (Autodesk Forma Data Management; sidebar labels may still say ACC) in the project sidebar to explore connected hubs and systems you can access from this project. Use this area to select source locations and set up syncs into the project. Synced data is then available as Speckle models in the project, alongside models created through connector publishing. Keep detailed setup, permissions, and sync-step guidance in the dedicated Forma Data Management documentation. For setup details, see Autodesk Forma Data Management (ACC). Together, activity, quality, issue, integration, and reporting surfaces give an at-a-glance view of project pulse. These signals are surfaced on the project home page so teams can assess project pulse without digging through multiple pages. From project home, you can click through to a model home page from either Model Activity or the models list. Use this distinction when navigating:- Workspace Projects page: all projects visible to you in the workspace.
- Project home page: one selected project and its internal activity.
Project settings and access
Use Configuration when you need to:- Change project visibility.
- Manage project collaborators.
- Create or revoke share tokens.
- Review project automations.
- Maintain project and issue labels in workspace settings.
FAQ
When should we create a new project instead of a new model?
When should we create a new project instead of a new model?
Create a new project when access boundaries, client context, or governance rules
differ. Use models when work belongs to same project boundary.
What is the ideal project structure of models?
What is the ideal project structure of models?
There is no one template that fits every team. A good structure is one your team
can explain to newcomers, align with access rules, and publish to
consistently without constant rework. Start from Why project structure
matters for when to split projects, then read
Models for when to split models inside a project
(ownership, discipline, release timing, naming with
/). Warning signs include one
project where unrelated teams fight over permissions, or so many tiny models that
nobody knows where to publish.Should we pre-create many empty nested models?
Should we pre-create many empty nested models?
Usually no. Seeding a project with dozens of empty nested models looks
organized but becomes admin noise: people cannot see where real versions land. A
shelf of empty folders mostly consumes list and sidebar space for little gain
beyond legacy filing habits. Prefer creating models when work starts, use
predictable model naming (for example grouped paths with
/ as in
Models) instead of a deep empty tree, and agree
conventions with the team rather than chasing a perfect taxonomy up front.
Project labels apply to rows on the workspace Projects list; they do not
classify individual models inside a project.Can I post the same models in more than one project?
Can I post the same models in more than one project?
You can publish the same authoring work into more than one Speckle project.
Each destination is its own Speckle model with its own version history. Those
copies are not linked: Speckle does not treat them as one logical model across
projects. That still fits Why project structure
matters when permission boundaries are strict
enough to justify separate containers. The tradeoff is operational: updates must
be published in every project that should stay aligned.
How else can we separate client deliverables from internal work?
How else can we separate client deliverables from internal work?
When boundaries are looser, prefer one Speckle model history and control
exposure with project visibility, collaborators, and share tokens
instead of parallel publishes. Use two projects with duplicate publishes only
when separation is non-negotiable for governance. Project labels help organize
the workspace Projects list only; they do not tag models inside a project
and do not hide data, so do not use them as an access boundary for model
content.
Who can change project visibility?
Who can change project visibility?
Users with sufficient project ownership permissions can change visibility in project
settings.
Do labels change permissions?
Do labels change permissions?
No. Project labels and issue labels are for organization and filtering only.
Permissions are controlled by workspace role, project role, and project visibility.
Does archiving a project delete it?
Does archiving a project delete it?
No. Archive removes it from active workflows but keeps data recoverable. For
details, see Archive and unarchive projects.