Implementers work on a live configuration. You add a data type, adjust a view, wire up an automation, refine a permission — and the platform changes shape as you go. Most of those changes are improvements, but every so often one turns out to be a mistake, and you want a way back to how things were before. Version management gives you that: named checkpoints of your configuration that you publish at good moments and, if a later change goes wrong, roll back to.
A version is a recovery point. Publishing one does two things at once. It records the human-facing entry in your release ledger — a version code, release notes, and operator-only internal notes — and it captures a snapshot of the platform's configuration as it stands at that moment, together with a record of the database structure. Because a published version holds the actual configuration state rather than just a label, it is somewhere you can return to.
A version captures your configuration. The snapshot covers the same surface that moves between tenants during synchronization: data types and their properties (including custom properties added to system types like User), modules, views and queries, roles, groups, roots and permissions, automations, canvases, email templates and scheduler definitions, connectors, apps and MCP servers, legal grounds and purposes, and schema translations. The option lists of enumeration types are configuration too, so they are captured as well. Alongside all of this, the version stores a fingerprint of the database structure — which tables and columns existed at publish time — which is what later lets a rollback tell you exactly what a revert would drop.
It captures configuration, not data. Some things are deliberately left out: the transactional records your users create (projects, tasks, orders), the user accounts themselves (the User type and its custom properties are captured, but not the individual rows), uploaded files, and secrets — connector credentials are stripped from the snapshot. The mental model is simple: a version remembers how the platform is shaped, not what is inside it.
Publishing a recovery point happens from the Versions screen. Once you submit the version code and notes, the snapshot is captured in the background — on a large tenant that can take a moment — so a new version moves from capturing to captured before it can be used as a rollback target. Versions you published before this capability existed remain valid release-ledger entries, but they carry no recovery point and can't be rolled back to.
Rolling back reverts your live configuration to a chosen recovery point and publishes the result as a new version. It is a forward operation, not a secret rewind of history: the platform works out the reverse changes, applies them, and records them as the next entry in the ledger. That keeps your version history honest and linear.
The rollback preview shows you exactly what will happen before anything changes. It has three parts: what will be re-applied (configuration from the checkpoint that gets re-created or updated), what will be deleted (configuration you added after the checkpoint, which the rollback removes — and removing a data type drops its table), and the physical database changes (the precise tables and columns the revert will drop, read from the stored structure fingerprint). Read the deletion list carefully; it is your data-loss surface.
Rollback restores structure, not data — the single most important thing to tell stakeholders. A data type or property you added since the checkpoint is removed, and its data goes with it. A data type or property you deleted since the checkpoint is re-created, but it comes back empty, because that data was already lost when it was first dropped. Rollback is not a backup: to recover lost rows, restore from a database backup. It also runs as a background operation that, like any live schema change, can't be transactionally undone — if you need to undo a rollback, roll forward to a different recovery point instead.
Precise for the core, best-effort for the rest. Rollback is exact for the structural heart of your configuration — data types, properties, and the main objects like modules, views, queries, roles, canvases and automations created after the checkpoint are pruned cleanly. For permissions, translations, enumeration items, and connectors, apps and MCP servers, the checkpoint's values are re-applied, but extras added after it are not necessarily removed. And because secrets are never part of a snapshot, a connector that gets rolled back may need its credentials re-entered.
Configuration drift is the honest answer to "what version is live?" The version a tenant reports through the API is its last published recovery point — not a promise that nothing has changed since. Because you keep working live, the configuration almost always drifts ahead of the last version you published. To make that visible, the platform exposes a live configuration fingerprint next to the published version; when the two differ, the configuration has drifted. An integration that needs to know whether production is exactly the published version can compare the two.
Versioning is a history, not a set of branches. Versions are a linear list of checkpoints. Editing stays live — there is no staging area where changes wait unpublished, and there are no parallel branches to merge. The workflow is straightforward: work live, publish a checkpoint whenever the configuration is in a known-good state, and roll back if you need to. When you want to move tested configuration between environments rather than back in time, that is what tenant synchronization is for.
A few habits make the feature pay off. Publish a recovery point before you start a risky or large change, not only after it — that is the checkpoint you'll want if it goes wrong. Use stable, meaningful version codes and release notes written for the people who implement and operate the tenant. Read the preview's deletion and physical-change panels before you confirm a rollback. And keep a real database backup strategy for your transactional data: rollback recovers the shape of the platform, not its contents, and the two protect different things.