Skip to main content

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

Workspace Projects page: Search projects field, Labels filter and Only show my projects, table with Name, Visibility, Models, Versions, Members, label chips, row menu, and New project control
The workspace Projects page is your operations surface for project administration. It lists every project visible to the current user in that workspace.

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.
Open a project by clicking its name.

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 +N chip 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
Bulk actions are available only when your permissions allow edits on the selected projects.

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

Projects list row with applied label pills, plus control to add labels, and open label picker dropdown with grouped options and checkmarks
1

Open Projects

Open the workspace Projects page.
2

Open label picker

In the project row, select the + button in the Labels column.
3

Apply labels

Toggle labels on or off in the picker. Changes save immediately.
You can set labels only on projects you can edit.

Label many projects at once

1

Select projects

Select projects with row checkboxes, or select project rows directly.
2

Start bulk labeling

In the bulk action bar, click Set labels.
3

Apply shared labels

Toggle labels to add or remove them across selected projects.
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.
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.
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.
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 home (top): project name, workspace badge, Invite and New model, description and labels, Models Versions Issues summary cards, model activity timeline by model
The masthead shows the project name, workspace badge, summary text, and project labels. Summary cards report Models, Versions, and Issues totals. Model Activity is a scrubbable timeline of publishes and events per model in the project.
Project home (middle): version timeline strip, Models list with thumbnails and last published, Issues list with status badges
Still on Home: a project-wide versions strip, the models table with thumbnails and last published times, and an issues snapshot with status badges. The full Models and Issues experiences live on their sidebar pages (below). A Collaborators tab on the project (not shown in these crops) is where project access is visible and editable when your permissions allow it.
Project home (lower): Data Validation check cards, Live Syncs section, Latest dashboards table
Lower on Home, Data Validation surfaces KPI cards when checks are configured. Live Syncs shows recent cloud integration activity when syncs exist. Latest dashboards lists Intelligence dashboards scoped to this project. The Data Validation cards on project home are high-level check results (score/status/trend heads-up). Use View check to drill into check details. For validation workflows and interpreting results, see Data Validation Overview, Checks, and Viewing Results. The screenshot below shows that navigation in the project sidebar for an open project.

Project sidebar

Project view for Tokyo Hotel: sidebar with back to workspace, Home, Models, Versions, Issues, Data Validation with Beta, Intelligence, Collaborators, Integrations, Settings; main area shows project header and model activity
Use the left sidebar to switch between Home and the other areas in the list below. For Data Validation navigation in an open project:
  • 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.
You can click a version row to open version details, or click the model name in the row to move to that model. For version behavior and history, see Versions.

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.
When an issue is selected, the detail panel shows status, assignment, due date, labels, and discussion details. Issue labels used in project issues come from workspace-level label configuration under Settings -> Issue labels.

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.
For dashboard setup and usage details, see Intelligence Dashboards, Layout and sharing, and Common 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

Create a new project when access boundaries, client context, or governance rules differ. Use models when work belongs to same project boundary.
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.
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.
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.
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.
Users with sufficient project ownership permissions can change visibility in project settings.
No. Project labels and issue labels are for organization and filtering only. Permissions are controlled by workspace role, project role, and project visibility.
No. Archive removes it from active workflows but keeps data recoverable. For details, see Archive and unarchive projects.
Last modified on May 7, 2026