Versioning is a way for Atlas Play to keep amendments to your processes organised and easy to understand. Each time you create or remap a process, it will be automatically given a version number, which will be incrementally increased each time you update it.
💡 In this article:
How processes versioning works
When creating a process in Map, your process will exist only in Map and will exist as V1.0. You can continue to work on, update and amend your initial process without this changing. You can even save and come back to your process without the version number being altered.
Processes in Share can be remapped and/or run by yourself and anyone with the corresponding permissions.
How task versioning works
When you create a new version of your process, by clicking Remap in Share, you might also notice that a task has a new version in the Properties Panel.
This version number doesn’t automatically increase with the process versioning, but instead when you interact with a task on a newer version of a process. This is a system function that helps Atlas keep track of task versions within a process.
NB: Because a task only creates a new version of itself when interacted with, you might see tasks with version numbers that don’t match the process version. This is perfectly normal and nothing to worry about!
How process versioning increases a version number
When you, or a user with the appropriate permissions, see a process you can edit in Share, you will have the option to Remap it. Once you click the Remap button, a new version will be created that you can edit.
The version number of this process will be an incremental increase to the previous. For instance, a V1.0 version that you have chosen to remap will become V2.0 and a V2.0 process will become V3.0, and so on.
If you save your process and come back to it later, you’ll notice that, for example, your V1.0 process is still visible in Share but your V2.0 process is in Map, marked as Draft. Once you’ve published your V2.0 process, that will replace the V1.0 in Share.
Any tasks within a process that began running, without being completed, when you started to remap a process will still appear in Run until they’ve been completed.
Versioning and subroutines
From Share, you are able to delete your processes as well, without Remapping them or retaining a draft. If the process you are deleting is called as a subroutine any existing calls may still be executed – consider whether existing calls will need to be removed.
Make sure you keep all subprocesses aligned when they have updated to a new version. Read how to keep new versions of subprocesses aligned through a Call Activity or a Service Task.
How publishing the new version of your process will appear
Once you are happy with the amendments you’ve made to your process, you can publish it again. Now, the latest version of your process will appear in Share and active tasks will appear in Run, as appropriate, marked with the latest version number.
If you take a look in Map, you’ll see that when you published your process, the draft was removed.
How this helps keep things organised
By using versioning, you have a single string of processes that you can keep track of throughout their development. By automatically moving your process from Map to Share and Run, and vice versa, there’s no confusion about which you should be working on and which is functional.
By using the permissions function, you can be sure that only the appropriate users are able to Run or Remap processes that have been published. Any amendments can be seen in the current version of the process and all drafts can be found in Map.
NB: It’s worth remembering that when you publish a new version of a process, you won’t be able to access your previous versions. So, when you choose to remap a process, make sure you’re happy with everything before you hit publish!