ALM Octane versus Jira integration licensing context

ALM Octane often runs alongside Jira, synchronising work items so that test and quality data flows between the two. When an audit looks at that integration, it can count every Jira user whose items appear in Octane as an Octane license, or count the service account that drives synchronisation as an interactive user. Both readings inflate the finding by attributing Octane licenses to people and processes that only ever touch Octane through an integration. Understanding what the integration actually meters is the heart of the defense.

ALM Octane, the modern test and delivery management product that came to OpenText through the Micro Focus acquisition, is designed to sit inside a wider toolchain rather than replace it, which is why Jira integration is common. Synchronisation moves work items, statuses, and links across the boundary, and the data those flows leave behind can look, to an audit, like a much larger Octane population than the one that actually logs in and uses the product. The licensing context is what separates an Octane user from a Jira user whose data merely crosses over.

What the Octane and Jira integration actually does

The integration synchronises records between the two systems through a connector that authenticates with a service account and exchanges data on a schedule or on change. A Jira user who creates a defect that synchronises into Octane has not used Octane; the connector has carried their record across. Counting that Jira user as an Octane license charges for someone who never opened the product, and counting the synchronisation account as an interactive user charges for a process rather than a person. The metric Octane is licensed under, set out in ALM Octane license metrics explained, governs who is genuinely a chargeable user, and a record arriving through a connector is not the same as a user logging in.

The same principle that keeps automation out of a user count applies directly here, because the synchronisation account is integration infrastructure, the category examined in how ALM API and integration users are counted. Octane also draws DevOps pipeline data, and the way pipeline activity is counted raises a parallel question, the subject of ALM Octane pipeline and DevOps user counts. In each case the dividing line is the same: interactive human use is licensable, and machine to machine flow is not.

Where the integration context decides the finding

The decisive question is who actually used ALM Octane interactively during the measured period. The user records, login data, and license assignments answer that question, while the synchronisation logs reveal which records merely crossed the boundary. A finding that rests on the presence of Jira sourced items in Octane is counting data flow, not usage, and the rebuttal separates the two by showing which accounts logged in and worked in Octane against which records arrived through the connector.

Establishing the licensed metric first is what makes that separation meaningful, because the metric defines whether Octane counts named users, concurrent users, or another unit, and the wrong metric produces the wrong count regardless of how the integration is read. That reconciliation is the discipline set out in reconciling ALM entitlements before an audit, and it precedes any argument about Jira, because the integration only matters once the metric is fixed.

How the integration maps to the count

The reason this matters is that an integration produces a rich audit trail, and that trail is easy to misread as evidence of a large user base. Every synchronised item carries a reference to its Jira origin, and an audit that tallies those references can arrive at a count that approaches the entire Jira population. The defensible count is far smaller, the set of accounts that logged into Octane and used it, and shifting the basis from synchronised references to interactive logins is the core of the rebuttal. The integration trail is evidence of connectivity, not of licensing.

This is also why the synchronisation account deserves explicit treatment, because it appears in the logs constantly and can be mistaken for the most active user in the system. It is the connector, not a person, and excluding it is the same correction that removes any service account from a named user count, the line by line work described in defending an ALM named user overclaim line by line.

How we defend an Octane integration finding under the four Rs

Respond. OpenText gives seven days notice before an audit and the right to copy relevant records, and the seven day notice clock starts immediately. Within that window we take over the single controlled channel and preserve the Octane user records, the login data, and the synchronisation logs together, so interactive use can be separated from integration flow.

Reconstruct. We build the effective license position against entitlements and the Additional License Authorizations independently, establishing the Octane metric and identifying the accounts that genuinely used the product, distinct from the Jira users whose records merely synchronised across.

Rebut. We challenge every line that counts a Jira user or the synchronisation account as an Octane license, presenting the login data and the synchronisation logs that show which records crossed the boundary without a user ever opening Octane. The finding falls by the integration sourced population.

Resolve. We settle on the count of genuine Octane users and, where it serves you, convert forward into an OpenPass agreement that records how Octane is measured and that integration accounts and synchronised records are out of scope, so the next review cannot rebuild the finding from the Jira boundary.

An anonymised outcome

The integration context matters because the remedy is severe. On noncompliance the licensee is deemed to have acquired licenses at then current list price, owes back maintenance and support, owes first year maintenance on the new licenses, and reimburses the cost OpenText incurs performing the audit, so counting an entire Jira population as Octane users multiplies the error across every charge. Our anonymised case files show what correcting the basis of a count achieves: an insurance ECM seat count finding fell from $7.2M to $1.6M, a 78 percent reduction built on disqualifying accounts that the raw count had treated as licensable. An Octane integration finding answers to the same correction, because a synchronised record is not a user.

Separate use from integration before you accept the count

The durable point is that an ALM Octane finding involving Jira is defended by separating interactive use from integration flow, because a synchronised record and a connector account are not Octane licenses. A buyer who confirms the metric and produces the login data holds the finding to the people who genuinely used the product. To build the position, read ALM Octane license metrics explained, how ALM API and integration users are counted, ALM Octane pipeline and DevOps user counts, and reconciling ALM entitlements before an audit. For the full method see our ALM and LoadRunner audit defense track and our complete OpenText audit defense playbook for 2026. If an Octane finding has counted your Jira integration, open a case.