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
draftversion.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
draftversion is generated automatically).An existing
draftversion is deployed (the version number associated with the existingdraftis incremented for the new one).A user chooses to copy an existing
deployedorinactiveversion todraft(content in the existingdraftis overwritten but the version number is NOT incremented).
No. A process flow will only ever have one version set to a draft status.
Deploy (
deployedstatus)
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 (
inactivestatus)Delete (
inactivestatus)Copy to draft (overwrite existing
draftversion, no change todeployedversion)
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 (
deployedstatus)Copy to draft (overwrite existing
draftversion, no change toinactiveversion)Delete (version removed entirely)
Last updated
Was this helpful?