Skip to main content
This page explains what is common to every Speckle cloud integration before you enable a specific one. It is written for administrators who govern access on the source side — an Autodesk hub, a ProjectWise datasource, a Microsoft 365 organization, a Databricks or Snowflake account — and need to know what Speckle will and will not be able to reach.

​
The rule that applies everywhere

Speckle never has more access than you grant on your side. There is no Speckle-side switch that widens what an integration can read. Every integration authenticates with an identity you control, and the permissions attached to that identity in your platform are the whole boundary. Two consequences follow:
  • You govern in your own tools. Access reviews, revocation, and scoping happen in Autodesk admin, ProjectWise, Unity Catalog, or Snowflake roles — the places your team already audits. Speckle adds nothing that needs a parallel policy.
  • Nothing is crawled. Speckle does not index your hub, datasource, catalog, or lake. It reads only the specific files or tables a user selects, only when a sync or query runs, and only if the identity is permitted to read them.

​
Two kinds of integration

​
Syncs (BIM and CAD)

A sync takes a file the user can already open in the CDE and converts it into Speckle’s object model — atomised into individual elements with their properties, normalised so a Revit wall and an IFC wall can be queried the same way. That conversion is what enables the viewer, dashboards, AI chat, and the SQL join to your tables. The source file is read, not modified, and the sync does not trigger paid translation or consume cloud credits on the CDE side.

​
Subscriptions (data)

A subscription points at a table or view in your warehouse. Speckle presents a browser of what the service identity can see; a user picks a table, and Speckle queries it read-only when a dashboard, AI chat, or SQL join needs it — for example, joining a cost table to the elements of a synced model. Queries run on your warehouse compute under the service identity, so they appear in your query history and consume your compute like any other client.

​
Sync guarantees

This section applies to every sync integration — Autodesk Forma Data Management (ACC), Bentley ProjectWise, Trimble Connect, SharePoint, and any integration added later. It states what Speckle guarantees when a sync runs and what it does when a sync does not.

​
Terms

  • Source platform — the system Speckle reads from. It is the system of record for its own files and version history; Speckle never is.
  • Sync — a standing link between one file in the source platform and one Speckle model. Created once, it produces Speckle versions over time. Pausing or disconnecting a sync stops new versions; existing versions stay.
  • Source version — one saved state of a file in the source platform. The source platform numbers and retains these.
  • Change detection — how Speckle learns a new source version exists. ACC notifies Speckle at publish time. ProjectWise, Trimble Connect, and SharePoint are checked on a schedule, so Speckle sees only the source version current at check time; versions superseded between checks are never seen.
  • Sync attempt — one run of a sync against one source version Speckle has seen: download, convert, store. Each seen source version gets exactly one attempt, which either succeeds (a Speckle version now exists) or fails (it does not).
  • Speckle version — the converted copy a successful attempt stores. Speckle versions are ordered by their creation date, not by source version number. A version from an automatic sync is dated when Speckle created it; a version from a historical import is dated when the source version was created in the source platform.
  • Latest version — the most recently created Speckle version of a model, and what the viewer, dashboards, and API show by default.
  • Retry — running a new sync attempt against the same source version as the sync’s most recent attempt. Available from the sync’s status in the UI, and only while that source version is still the newest one Speckle has seen. Once a newer source version has been seen, the earlier one can no longer be retried.
  • Missed source version — a source version whose attempt failed and that can no longer be retried because a newer source version has since been seen, or that Speckle never saw because the integration was disconnected, its authorisation had lapsed, or the sync was paused. Both cases are handled the same way.
  • Re-publish — producing a new source version in the source platform (re-issuing, re-saving, or re-uploading the file). Speckle treats it as any other new source version.
  • Historical import — a user choosing earlier source versions from the source platform’s version history and syncing them into the model, up to five at a time. Available for ACC syncs. Each imported Speckle version is dated when that source version was created, so it takes its place in the past and never becomes the latest version.

​
The guarantee

Syncs are forward-only. A sync acts only on the source version current when it runs, and each new Speckle version comes from a source version at least as new as the one before it. A model’s latest version always reflects the most recent successful sync attempt. It is never an older source version brought in out of order. A user can import earlier versions where the integration supports it. A historical import is an explicit user action, not something Speckle does on its own. The imported Speckle version is dated when the source version was created, so it slots into the model’s history behind newer versions and the latest version is unchanged. Currently ACC only; see Import earlier versions. A failed attempt can be retried only while its source version is still the newest. If the most recent attempt failed, retry it from the sync’s status. The retry runs against the same source version, so it cannot disturb version order. Once a newer source version has been seen, the earlier failure is a missed source version and the retry is no longer offered. Missed source versions are not replayed by Speckle. Whatever the cause — a Speckle-side fault, or the source platform’s availability, authorisation, permissions, or rate limits — Speckle does not retry a missed source version later or backfill it on its own. The next successful attempt produces the next Speckle version. To get a missed version into Speckle, import it from the file’s version history where the integration supports it, or re-publish it on the source platform. What Speckle does when attempts fail. Speckle surfaces the failure in the sync’s status, fixes the cause so subsequent attempts succeed, and confirms with the reporting customer. Where the cause was on Speckle’s side, Speckle notifies affected workspace admins with the models involved, the date window, and how to recover the missed versions. How a failure is surfaced — auto-pause, email to the sync’s creator — is described on each integration’s page. Responsibility boundary. Every integration is a two-party arrangement. Speckle is not responsible for source versions that fail to sync because of the source platform’s availability, authorisation, permissions, rate limits, or content Speckle cannot process. Speckle’s service commitments cover Speckle’s half. Disconnection gaps. If an integration is disconnected, a sync is paused, or authorisation lapses, source versions during the gap are missed. Reconnecting or resuming continues from the next source version Speckle sees, not from the gap.
The source platform keeps its full version history regardless of what Speckle synced. Treat Speckle’s version list as the record of what was successfully converted, not as a mirror of the source platform’s history.

​
Who the integration acts as

This is where the integrations differ, and it determines where you scope access. For ACC, permissions are per user and follow the user. If Sarah is a member of two hubs — full read on one, a single project on the other — she can sync anything she can read across both, and nothing else. Change her Autodesk permissions and her Speckle reach changes with them. There is nothing for you to enable beyond registering the Speckle integration on the hub once. For Databricks and Snowflake, permissions are per workspace and follow the service identity. Everyone in the Speckle workspace sees the same set of tables: the ones you granted. This is deliberate — it lets you publish a curated, governed surface (specific schemas, views with row filtering applied on your side) without mirroring individual user entitlements into Speckle. If different teams need different data, use separate Speckle workspaces with separate service identities. ProjectWise is both. The service account must be added to a project for it to be reachable at all, and within that the user’s own ProjectWise permissions still apply. SharePoint browses as the user and syncs as Speckle’s app. A user picks files with their own Microsoft account, so they see only what they can open. The approval covers every site in your organization, and you cannot narrow it to chosen sites today. Speckle reads only the files users picked for a sync, but Microsoft does not enforce that limit. See Approve Speckle for SharePoint.
Speckle’s own project roles govern what happens after data is in Speckle — who can view, comment, or load a model. They do not extend anyone’s reach into the source platform.

​
What Speckle never does

  • Write back. No integration modifies, uploads, or deletes anything in the source platform. Scopes and grants are read-only by design; in ACC, the requested scopes are account:read, user-profile:read, data:read, data:search, bucket:read, viewables:read, and openid.
  • Crawl or enumerate beyond the identity’s permissions. Speckle lists only what the identity can list, and only when a user opens the browser view.
  • Escalate. Speckle cannot request broader access on a user’s behalf; broadening access is always an action you take in your own admin console.
  • Expose credentials. Service principal secrets and private keys are encrypted in the browser before they are sent, stored encrypted at rest, and never displayed again after you save them.
For ACC, if you want tighter control than per-user inheritance, create a dedicated Autodesk account with access to only the projects you want synced and have users sign in to Speckle with it. For Databricks and Snowflake, treat the service identity as a publishing surface. Grant it access to a dedicated schema or set of views rather than to raw tables, and apply any row- or column-level policies on your side — Speckle only ever sees what the query returns. For ProjectWise, add the service account only to the projects that need syncing; unlisted projects are invisible regardless of user permissions. For SharePoint, the approval cannot be scoped to sites. To stop all access, remove Speckle’s app in Microsoft Entra, as described in Remove Speckle’s access.

​
Enable a specific integration

Autodesk Forma Data Management (ACC)

Register the Speckle integration on your hub

Bentley ProjectWise

Add the service account, or configure an on-premises WSG server

SharePoint

Approve Speckle for your Microsoft 365 organization

Databricks

Create a service principal and grant it read access

Snowflake

Create a service user, role, and key-pair credentials

​
FAQ

No. ACC access is the user’s own Autodesk permission set, requested read-only. If they cannot open it in Autodesk, they cannot sync it.
New syncs and queries stop immediately. Data already converted into a Speckle project stays there, governed by Speckle project roles, until a project owner removes it — the same as any file a user had legitimately exported while they had access.
Because the integration authenticates as the service principal, not as each user. Scope the service principal to a governed set of views; use separate workspaces if teams need different surfaces.
Syncs read existing files and derivatives and do not trigger paid translation. Warehouse queries run on your compute under the service identity and are billed by your platform like any other client.
Not on its own: syncs are forward-only and Speckle does not replay missed source versions, whatever the cause. If it is the sync’s most recent attempt, retry it from the sync’s status. Otherwise, on ACC, a user with access to the sync’s settings can import it from the file’s version history; on other integrations, re-publish the file on the source platform and Speckle syncs it as a new version. See Sync guarantees.
It can lag — by the check interval on scheduled integrations, plus conversion time — and it can be missing a version that failed to sync. It will never be an older version brought in after a newer one: the latest Speckle version always comes from the most recent successful sync, and earlier versions a user imports are dated at their source creation time, so they never displace it.
Speckle stores the query results it needs to render a dashboard or answer a question, not a copy of the table. The table of record stays in your warehouse.
Last modified on October 21, 2026