Understanding flow versioning for virtual environments
Introduction
If you've been building and running process flows before the introduction of virtual environments, you'll be used to the 'normal' rules around process flow versioning, where (in a nutshell) a process flow can have one deployed
version, one draft
version, and multiple inactive
versions .
With virtual environments, the same statuses are used, but we need to think differently about how they are applied. Each version of a process flow moves through its own status cycle, and different versions can be deployed to different virtual environments. So instead of asking (for example):
Is this process flow deployed?
...ask instead:
How many deployed versions does this process flow have?
How it works
With virtual environments, statuses are tied to flow versions, rather than the process flow as a whole. A process flow version can move through three statuses:
Draft
Deployed
Inactive
When a process flow is created, a draft
version is generated automatically. This version can then become deployed
(whereupon a new draft
version is generated) and subsequently inactive
when the current draft
is deployed. So, each new draft
is a new flow version that moves through its own lifecycle, as illustrated below:

Flow version rules are detailed below, but in essence:
A process flow will only ever have ONE
draft
version.Only ONE version of a process flow can be deployed to a given virtual environment.
Multiple versions of the same process flow can be deployed to different virtual environments.
A flow version can be deployed to a single virtual environment, to multiple virtual environments, or to no virtual environment.
Deploying flow versions to virtual environments
You can deploy any existing draft
or inactive
version of a process flow to any active virtual environment, provided there's no existing version of that flow in the selected virtual environment.
When deploying to multiple virtual environments, you would typically deploy the same version (so all virtual environments include the same flow setup). However, it is possible to deploy different versions to different environments - in this case, you would see multiple deployed
versions of the process flow (in process flow settings) - for example:

Let's break this down with an example, where we're deploying to two virtual environments (Virtual Environment A) and (Virtual Environment B):
User creates process flow
-
-
User deploys draft
version #1
without a virtual environment.
1
-
User disables version #1
2
-
User deploys version #2
to Virtual Environment A
2
1
User deploys version #3
to Virtual Environment B
2 and 3
1
User un-deploys (i.e. deletes) version #2
from Virtual Environment A and version #3
from Virtual Environment B
4
-
1, 2, and 3
Flow versioning rules for virtual environments
The following rules apply when working with process flow versions in virtual environments:
Draft
Yes
A new process flow is created (a
draft
version is generated automatically).An existing
draft
version is deployed (the version number associated with the existingdraft
is incremented for the new one).A user chooses to copy an existing
deployed
orinactive
version todraft
(content in the existingdraft
is overwritten but the version number is NOT incremented).
No. A process flow will only ever have one version set to a draft
status.
Deploy (
deployed
status)
Deployed
No
A user chooses to deploy a flow version.
Yes. If different process flow versions are deployed to different virtual environments then multiple deployed
versions will be present.
The number of deployed versions allowed is x+1, where x
is your number of virtual environments and 1
is a deployment to no environment).
Alternatively - if the same flow version is deployed to all virtual environments, you'll only have one deployed version.
Disable (
inactive
status)Delete (
inactive
status)Copy to draft (overwrite existing
draft
version, no change todeployed
version)
Inactive
No
A user disables ALL deployments of this version.
A user deletes deployments of this version from ALL virtual environments.
Yes. Each time a flow version is un-deployed, it's set to an inactive
status. This status remains unless:
The same version is deployed again (in which case it becomes
deployed
)The version is deleted.
Deploy (
deployed
status)Copy to draft (overwrite existing
draft
version, no change toinactive
version)Delete (version removed entirely)
Last updated