> ## 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. > ## Agent Instructions > These docs contain multiple Speckle product experiences. For Speckle 2026.9, prefer /next/ pages for the topics and changes they cover. The navigation label Current does not override this version-specific precedence. > Coverage under /next/ is incremental. Use Current documentation for unchanged topics and when a /next/ page says coverage is unavailable or explicitly refers you to Current. Do not infer a feature was removed from a missing page. > Read the page-specific documentation status, applicability, affected guidance and replacement links in agent-only content. Impacted, changed and superseded apply only to the stated scope; they do not mean the entire feature is deprecated. Historical connector guides apply only to the legacy connector described. > Match guidance to the customer's deployment version, model data format and connector. Respect plan, permission and compatibility restrictions. If an unknown version or data format changes the answer, ask a focused clarification; do not infer deployment version from the date alone. # Cloud Integrations: Access and Governance > How Speckle cloud integrations authenticate, what they can see, and what they never do — for IT administrators governing a CDE or data platform. 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 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 | Subscriptions | | - | - | - | | **Source** | BIM and CAD files in a CDE — Autodesk Forma Data Management (ACC), Bentley ProjectWise | Tables and views in a data platform — Databricks, Snowflake | | **What Speckle does** | Reads the file, converts it into Speckle objects, and stores the result in the Speckle project | Registers the table and runs read-only `SELECT` queries against it on demand | | **Where the data lives** | A converted copy lives in Speckle; the source file is untouched | Data stays in your platform; Speckle stores the query results it needs to render a view or answer a question | | **Direction** | Read only. Speckle never writes back to the CDE | Read only. Speckle never writes, alters, or deletes | ### 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, 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 and Trimble Connect 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 when they were created in Speckle, not by source version number. * **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. ### 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 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.** Whatever the cause — a Speckle-side fault, or the source platform's availability, authorisation, permissions, or rate limits — a missed source version is not retried later and is not backfilled. The next successful attempt produces the next Speckle version. To get a missed version into Speckle, 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 the re-publish remedy. 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. | Integration | Identity Speckle uses | What a user can reach | | - | - | - | | **Autodesk Forma Data Management (ACC)** | The signed-in user's own Autodesk account, via OAuth with read-only scopes | Exactly the hubs, projects, and folders that user already has in Autodesk — no more, no less | | **Bentley ProjectWise** | A Speckle service account you add to projects, plus the user's own Bentley credentials | Only projects the service account has been added to **and** the user is permitted to see | | **Databricks** | A service principal you create, with SQL grants you assign | Whatever the service principal has `SELECT` on — the same for every user in the Speckle workspace | | **Snowflake** | A service user you create, with a role you grant | Whatever the role can read — the same for every user in the Speckle workspace | **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. 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. ## Recommended scoping patterns 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. ## Enable a specific integration Register the Speckle integration on your hub Add the service account, or configure an on-premises WSG server Create a service principal and grant it read access 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. If it is the sync's most recent attempt, retry it from the sync's status. If a newer source version has been seen since, no: syncs are forward-only and missed source versions are not replayed, whatever the cause. Re-publish the file on the source platform; Speckle syncs it as a new version. See [Sync guarantees](#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. 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.