When you deploy an automation, you can attach an optional version tag — a short, human-friendly label that makes the version easy to recognise later in the Versions tab.
Overview
When you deploy an automation, you can attach an optional version tag — a short, human-friendly label that makes the version easy to recognise later in the Versions tab. Tags are useful for marking release milestones, identifying a hotfix, or grouping related deploys under a shared name. The version number (V1, V2, V3 …) is always assigned automatically by the platform; the tag is supplementary, searchable text you control.
_1.png&w=1920&q=75)
_1.png)
The tag field pre-fills with the next version number as a suggestion — for example, V5 — so you can either accept that suggestion, replace it with a more descriptive label, or leave the field empty to deploy without a tag.
Note: The tag is the only label you add at deploy time. There is no separate release-notes field in the deploy panel. To review what changed between versions, use the Compare view.
Adding a Tag to a Version
In the automation builder, click Deploy in the top-right toolbar.
The deploy panel opens with a single field: Tag this version. The field pre-fills with the next version number as a suggested value.
Type your chosen tag label, or clear the field to deploy without a tag.
Click Confirm to deploy.
If the tag value does not meet the naming rules, the platform surfaces an inline validation message: "Invalid format, please follow the guidelines." Correct the value and click Confirm again.
Once the deploy succeeds, the tag appears alongside the version number in the Versions tab and is searchable from the search field at the top of that list.
Naming Rules
If you choose to add a tag, it must conform to the following rules:
Rule | Detail |
|---|---|
Must start with a letter | The first character must be an alphabetic letter (A–Z, a–z). Numbers and symbols are not valid as the first character. |
No spaces | Spaces are not allowed anywhere in the tag. Use a hyphen (-) or underscore (_) to separate words. |
Hyphens and underscores allowed | Both - and _ are valid word separators within the tag. |
Special characters not allowed | Characters such as @, &, and * are not permitted. The underscore _ is the only permitted non-alphanumeric, non-hyphen character. |
Tag is optional | Leaving the field empty is valid. The version deploys and receives its version number without a tag. |
Note: Breaking any of the above rules causes the platform to display "Invalid format, please follow the guidelines." The deploy is blocked until you correct the tag or clear the field.
Best Practices
Tags are most useful when they convey the purpose or scope of a release at a glance. To make the most of it:
Use descriptive labels that reflect the change — for example, fix-null-check or add-approval-step — rather than repeating the version number the platform already assigns.
Adopt a consistent convention across your team so the Versions tab remains scannable: for example, prefix bug fixes with fix- and feature releases with feat-.
Use the tag search field in the Versions tab to locate a specific release quickly when the version list grows long.
Use hyphens to separate words rather than underscores when legibility is a priority — both are valid, but hyphen-separated labels are easier to read at a glance.
Avoid generic tags like test or V5-copy; they become meaningless over time and make auditing harder.
Notes
Keep the following in mind when tagging automation versions:
Tags are optional but strongly recommended for any version deployed to a non-development environment; untagged versions are harder to identify in the version list later.
Once a tag is added, it cannot be changed; apply the final tag only after verifying the version is correct.
Tag names are case-sensitive and must follow the naming rules exactly; a misspelled tag will not be recognized by tools or processes that reference it by name.
Use a consistent tagging convention across your team (for example, v1.0.0 or PROD-2026-Q3) and document the convention so collaborators follow the same format.
Use the Notes field on a version for contextual comments and descriptions; keep tags short and machine-readable.