Publishing and versions

Workflows, Views and Functions can be published and versioned, allowing you to see the history of changes, revert to previous versions, and ensure that the correct version is shared to other users.

Versions are not saved automatically when changes are made to an object. Instead, you choose when to "save" a current version of an object by publishing it.

When you publish a version of an object for the first time it will become version 1.0. If you subsequently make changes and publish the object again, you can choose to make it version 1.1 (a new minor version) or version 2.0 (a new major version). At each publication, you must add publication comments to describe changes made in the latest version. Previously published versions will be saved.


The purpose of publication is to allow a Data Studio installation to continue to function as users make changes, including temporarily breaking changes, to Workflows, Views and Functions. In general, any modifications or enhancements to Workflows are likely to leave them temporarily broken.

Publications and drafts is the mechanism by which we allow users to experiment with changes, but keep them isolated from the rest of the system until they have confirmed the changes are complete.

Publication states

Each version of a Workflow, View or Function will be in one of three states:

  • Draft: This version is still under development, and should not be used except for development purposes. At most there can be one draft
  • Published: This is the current version of the object. At most there can be one published version.
  • Historic: This version was previously a current published version but has been superseded and should no longer be used.

When we use the term "latest version" we mean "the draft version if one exists, otherwise the published versioned".


Along with publication, it is natural to think about the lifecycle of objects as being a sequence of versions: A new version is created with each publication event.

It is useful to be able to view this sequence of versions, so you can understand how the processing logic has changed over time, and investigate any problems that have been introduced. This is particularly important when each Workflow may depend on several Views and Functions, changes to any of which may have caused the behaviour of the overall Workflow to change.

Viewing version history

You can view a list of all versions of an object, which will contain details of the version number, the publication date, and the change description. To view the version history for any Workflow, View or Function, click on the publication status message at the top right of the editor screen and select See all versions.

Using an object's Versions screen you can revert a versioned object to any historic version, or delete a draft version. Published version don't have a revert action.

Selecting a version

When multiple versions of an object exist, you should be careful to ensure you always pick up the correct version depending on the context – in particular to correctly choose between a Published and a Draft version when both are available.

Draft versions of objects are only be available to the group of people who are developing the draft, that is, users working in the same space and have edit rights. If a View, Workflow or Function is shared to another Space, only the published version of the object will be visible and usable in that Space.

Users who are able to work on the draft can choose whether to use the draft version or the published version of a Workflow on execution. They can make a similar choice for any dependencies (Views, re-usable Workflows or Functions used in the Workflow) in the same Space. This is to allow a group of related objects (e.g. a View, a Function, and a Workflow) to be developed together.