Working with Power Automate Solutions: Version Numbering for Solutions

This article is part of the Working with Power Automate Solutions series and of the larger Working with Power Automate series I am writing on my experiences working with the Power Automate, which is part of the Power Platform from Microsoft. I also have a related series of articles on Power Automate with Microsoft Dynamics 365 BC.

I said in the last article on publishing solutions that I would cover exporting and importing next, but, on reflection, I thought I’d briefly discuss version numbering solutions before doing the export/import.

When you create a solution it is given the version number 1.0.0.0 and when you export a solution, Power Automate automatically updates the last segment of the version number, so it would become 1.0.0.1. However, you can overwrite the numbering to increase the number in different ways.

The four segments in Power Automate are:

1. Major
2. Minor
3. Build
4. Revision

However, I am more used to the version numbering using semver, or Semantic Numbering to give its full name. I use this approach with the ClassicPress plugins I develop.

With semver, the version numbering works using three segments:

1. MAJOR version when you make breaking changes where users will need to take some action during an upgrade.
2. MINOR version when you add functionality in a backwards compatible manner which users can simply apply without taking any other action.
3. PATCH version when you make backwards compatible bug fixes which, like MINOR versions users can apply without taking any other action.

A pre-release number may be appended to the end using a hyphen as separator, but Power Automate does insist on the format n.n.n.n.

To adapt semver to the permitted format, I am inclined to use the following format:

1. Major
2. Minor
3. Patch
4. Pre-release

What this means is that when I create a new solution, the version number would start as 0.0.0.1. I would then increment the pre-release segment each time I exported the solution while I was developing and testing.

When I came to release the solution to a client, the version number would change to 1.0.0.0.

If I did more development to fix a bug, I would increment the pre-release segment (e.g. 1.0.0.1, 1.0.0.2) as I developed and tested and then when I came to release, I would change the patch segment and revert the pre-release to 0 (e.g. 1.0.1.0).

If I made a small change to the functionality of one of the flows in the solution, perhaps adding an extra send email step, I would increment the minor segment and set the patch segment to 0 (e.g. 1.1.0.0).

If I added a whole new flow to the solution, then I would increment the major segment and reduce the others to 0 (e.g. 2.0.0.0).

There are many ways that you can manage versioning and I am not saying that the above is the only, let alone the best method, but it is one which works for how I am used to handling version numbers.

I’ve seen some version numbering done using date, so a release done on the 18^th January 2025, would have the version number 2024.1.18.1. There are many ways to version number; the key though for any version numbering system, is consistency. Making sure that all version numbers you set are done following the same convention.