Infohub Version History
How Infohub versions are numbered, how to find the version you are running, and what maintenance entitlement means for upgrades.
Finding the version you are running#
Several places, and they should agree:
| Where | Shows |
|---|---|
| Programs and Features | The product version, taken from Flow Config.exe |
| Flow Config | The version in its About information |
Flow Config.exe file properties |
The file version, which is the authoritative figure |
| The web client | The Flow Server version |
The installer takes its product version from Flow Config.exe, so that file is the one to trust if they disagree.
Check every machine, not one. An instance spans a database, one or more servers running Flow Bootstrap, and any number of Flow Config workstations. "What version are we on?" has to be answered for all of them — a partially upgraded estate is a real and awkward state. See Upgrading to Flow 7.2.0.
How the numbering works#
Infohub versions are major.minor.patch.
| Component | Changes when |
|---|---|
| Major | A substantial platform change |
| Minor | A feature release — new capability, and a schema upgrade |
| Patch | Fixes and small improvements within a minor line |
The practical rules that follow:
A minor release brings a schema upgrade. Moving from 7.1 to 7.2 upgrades the database, and that is not reversible. Treat it as a planned change with a verified backup.
A patch release within a line is a smaller step. Still back up first, but the change is narrower.
Every machine in an instance moves together. Flow Config writes the schema version, so an older Flow Config refuses an upgraded database.
The 7.x line#
| Version | Released | Notes |
|---|---|---|
| 7.2.0 | October 2026 | Current feature release. Config CLI expansion (506 options, including model, template and toolbox import, local-template operations and change-log listing), full OAuth 2.0 for the Web Service data source, SQL connection security, chart authoring automation, event scheme Skip To, a Time Slice Aggregation template lock, refresh triggers linked directly to a data source, and one hundred and twenty tracked correctness and performance fixes across the engine, integration, templates, charts and the configuration tool. Schema upgrade: yes. See What's New in Flow 7.2.0. |
| 7.1.x | The preceding patch line. Fixes and incremental improvements within 7.1. The 7.1.7 refresh-trigger changes are included in 7.2.0. | |
| 7.0.x | The 7.0 line. |
Per-version detail comes with the build. This knowledge base documents 7.2.0 in detail. For the specific contents of an earlier 7.1.x or 7.0.x patch release, refer to the release notes issued with that build, or ask Flow Software support — patch-level change lists are not reproduced here, and describing them from memory would be worse than not describing them.
If you are on a 7.1.x build and trying to establish whether a particular fix is present, the reliable route is to ask support with your exact version number rather than inferring it. Several fixes were delivered to specific sites ahead of a general release, so two instances reporting the same minor version can differ.
Maintenance entitlement governs upgrades#
An Infohub licence carries two independent dates:
| Date | Controls |
|---|---|
| Licence expiry | Whether Infohub runs at all |
| Maintenance expiry | Whether you are entitled to versions released after that date |
A perpetual licence has no licence expiry and still has a maintenance date. So an instance can run for years and then refuse an upgrade — because operation and upgrade entitlement are separate.
Check maintenance before planning an upgrade window, not during it. See Licensing Infohub.
Which version should you be on?#
Stay within a supported line. Running a version several minor releases behind means fixes are not reaching you and support conversations begin with "upgrade first".
Do not upgrade during a reporting period. Month-end is the wrong week.
Upgrade for a reason. A specific fix you need, a capability you want, or because you have fallen behind — rather than reflexively on release day.
Test first where you can. A test instance restored from production, upgraded, and exercised is the cheapest way to discover an upgrade surprise. Note that a restored instance needs its own licence and its Platform host name corrected, and that its consumers should be undeployed so it does not write to production systems. See Backup and Recovery.
Version skew in a multi-site estate#
Sites will not all upgrade on the same day. Decide a policy rather than improvising:
- Which combinations you will run between a site and the central instance.
- The upgrade order. A pilot site, then the centre, then the rest is common — but verify the pilot site's replication to the still-older centre before continuing.
- Template server compatibility, if the centre publishes templates to sites.
Verify replication end to end after each step rather than at the end of the programme. See Multi-Site Architecture.
When you cannot upgrade yet#
Sometimes an upgrade has to wait — a validated environment, a change freeze, a maintenance renewal in progress.
In that situation:
- Record which known issues affect you, so that when a symptom appears somebody recognises it rather than investigating from scratch.
- Note any workaround alongside it.
- Keep the upgrade on a roadmap with a date, rather than deferring indefinitely. The gap only grows, and each deferred minor release makes the eventual step larger.
Getting help with a version question#
Have these ready:
- The file version of
Flow Config.exe, from every machine. - The Flow Server version, if the web client is involved.
- Your licence and maintenance expiry dates.
- The plugin package versions under
%ProgramData%\Flow Software\Flow\Config\Packages. - Whether the estate is uniformly versioned.
Item 5 is the one that most often turns out to be the answer.