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.

​
How configuration is split

  • Workspace configuration controls security, identity, compliance, and workspace-wide behavior.
  • Project configuration controls access and operations for one project.

​
Workspace configuration

Open workspace Settings when your change should affect the whole workspace. Common workspace configuration areas: Use workspace settings when policies should be consistent across all projects in the workspace.

​
Project configuration

Open a project, then open project settings when your change should affect one project only. Project settings cover visibility, collaborators, share tokens, and automations. Workspace-level settings also affect project operations:
  • Settings -> Project labels controls labels available for project organization.
  • Settings -> Issue labels controls labels used in project issues.

​
Manage project collaborators

Projects can be shared with workspace members and, depending on workspace rules, with guest collaborators. Project visibility and membership together determine who can view and edit project content. From project home, open the Collaborators tab to view and manage project access.

​
Access levels

A project can have one visibility state:
  • Workspace: Accessible to workspace members.
  • Private: Accessible only to project collaborators and admins.
  • Public: Accessible to anyone with the link in the web interface and API.

​
Change project visibility

To update visibility in the web interface:
1

Open project settings

Open the project, then open project settings.
2

Select visibility

Locate the visibility control and choose the target level.
3

Save

Save changes to apply new visibility.
Public projects expose project data to anyone with the link. Validate project content before switching to Public visibility.

​
Share tokens

In Project settings -> Tokens, you can create share tokens that give read-only access. Share tokens are commonly used for:
  • Presentations.
  • Intelligence dashboards.
  • Power BI syncing.
Share tokens can be revoked from the tokens list when access is no longer needed.

​
Automations

In Project settings -> Automations, you can review and manage automations configured for that project. This can include:
  • Active sync automations connected to cloud integrations.
  • Automations running your custom code.
  • Enabled Speckle pre-made automations.
Use this page to check current automation status and manage what runs against project models. For setup and implementation guidance, use the developer docs: Speckle Automate and Create Automation.

​
FAQ

Workspace admins can change workspace-level settings. Members can view most settings pages but cannot apply workspace-level changes.
Project Owners and Workspace Admins can change project visibility, collaborators, tokens, and automations in project settings.
Use workspace settings when policies should apply across all projects in a workspace. Use project settings when the change should apply to only one project.
No. Labels are for organization and filtering. Permissions are controlled by workspace role, project role, and project visibility.
No. Project labels are managed in Settings -> Project labels. Issue labels are managed in Settings -> Issue labels.
Yes, if they are explicitly added as collaborators. Private visibility blocks users who are not project collaborators.
Share tokens provide scoped read-only access for specific sharing workflows. They do not change workspace or project roles. Revoke tokens when they are no longer needed.
Not by itself. SSO handles authentication. Use SCIM provisioning for automated provisioning and deprovisioning.
Data residency is available in Speckle Cloud on Enterprise plans. If you need strict sovereignty and infrastructure control in your own jurisdiction, use an Enterprise self-hosted deployment.
Yes, on Enterprise plans. Governance controls can enforce exclusivity based on verified email domains. Confirm your operating model first if your organization intentionally uses separate regional workspaces.
Last modified on May 4, 2026