Skip to main content
Blueprint versions provide a history of the changes made to a Blueprint. Use versions to review earlier configurations, restore a working state, compare changes, or create an independent fork.

​
How versioning works

Each saved version is a snapshot of the Blueprint at that point in time. Version history preserves the sequence of changes so collaborators can understand what changed and when. If your workspace uses semantic version labels, the version number communicates the scope of the change: Your current working version is the version used by the editor and the next save creates a new point in the Blueprint’s history.

​
Save a new version

  1. Make and test your changes in the Blueprint editor.
  2. Open the version controls in the editor.
  3. Choose the version increment or save option available in your workspace.
  4. Add a short change note so collaborators can understand what changed.
  5. Save the version.
The saved version appears in the Blueprint’s history and can be reviewed later.

​
Restore or roll back a version

Version rollback is available in Blueprint.
  1. Open the Blueprint’s version history.
  2. Select the historical version you want to review.
  3. Inspect the snapshot or compare it with the current version.
  4. Choose Restore or Roll back.
  5. Confirm the restoration when prompted.
The selected version becomes the active configuration. Blueprint preserves the version history so the restoration remains auditable and you can continue forward from the restored state. Before restoring, check the version’s connected data sources, tools, variables, and model settings. A rollback changes the Blueprint configuration; it does not automatically undo external changes made in connected systems.

​
Fork a Blueprint

Forking creates an independent copy of a Blueprint that you can adapt without changing the original.
  1. Open the Blueprint you want to reuse.
  2. Choose Fork.
  3. Give the new Blueprint a clear name and description.
  4. Review its nodes, variables, connections, permissions, and required inputs.
  5. Test the fork before sharing or deploying it.
Fork a Blueprint when you need a new direction, a team-specific version, or a safe place to experiment.

​
Publish to Public Libraries

When a Blueprint is ready to share, publish it to Public Libraries so other Blueprint users can discover it. Before publishing:
  • Remove confidential, personal, or regulated information.
  • Confirm that connected data sources, tools, and variables are safe for the intended audience.
  • Test the Blueprint with representative inputs.
  • Add a clear description, categories, and tags.
  • Confirm the visibility and organization policy.
Publishing creates a public listing that people can review and, when supported, fork as a starting point. Public Libraries listings should be treated as reusable examples, not as a substitute for reviewing and governing a Blueprint before use.

​
Review history responsibly

Use version history as part of your team’s governance process:
  • Record the purpose of meaningful changes.
  • Test a version before restoring or publishing it.
  • Review permissions and data handling after a rollback.
  • Keep public descriptions and tags aligned with the current Blueprint behavior.