Dimensions CM and RM user counting traps
Dimensions CM and RM user counting inflates a finding when an audit counts everyone who appears anywhere in a configuration management or requirements repository as a full licensed user, including stakeholders who only review, reviewers who comment occasionally, and service accounts that move artifacts between systems. The gap between everyone associated with a Dimensions repository and the genuine licensed user population is where the finding either holds or comes apart.
Dimensions CM is a configuration and change management tool, and Dimensions RM manages requirements; both sit at the centre of a development lifecycle where many people touch the artifacts but only a subset are full working users. That breadth of contact is exactly what makes Dimensions user counting prone to inflation. A requirements repository in particular attracts stakeholders, analysts, and reviewers who read or approve but do not author, and an audit can sweep all of them into a single full user count. Because the EULA makes compliance the sole responsibility of the licensee, the buyer must show which individuals are genuine licensed users and which only review, integrate, or no longer participate, and the access records that prove it belong to the buyer.
How Dimensions user counting goes wrong
The defensible count reflects genuine working users, the people who create and manage configurations in CM or author and edit requirements in RM. The inflation comes from counting everyone with any relationship to the repository as if they all required the same full license. Reviewers and approvers who only read and comment are treated as full authors. Stakeholders given visibility into requirements are counted as RM users. Service accounts that synchronize artifacts with other tools are counted as people. And users from completed projects whose access was never removed continue to appear. Each of these adds to the raw count without adding a genuine working user, and the reconstruction removes them by showing what each account actually does.
This is the same access versus genuine use distinction that runs through the testing family, set out in named versus concurrent user counting in ALM audits, and it is especially pronounced in RM, where the value of a requirements repository depends on wide visibility that should not be confused with wide licensing.
An audit counts everyone associated with a Dimensions CM or RM repository, reviewers, stakeholders, integration accounts, and finished project users, as a full licensed user. Requirements repositories in particular attract many read only stakeholders. Counting visibility as full use inflates the finding well beyond the genuine working population.
Where the Dimensions count overstates
Read only reviewers and stakeholders
People who only read or approve requirements do not exercise the tool the way authors do, and counting them as full users overstates the requirement. The same read only distinction is examined for the wider family in Quality Center read only access and consumer counts, and the principle carries directly into RM.
Service and integration accounts
Dimensions integrates with build, test, and tracking tools, and those integrations run under system accounts. How automated access should be treated is set out in how ALM API and integration users are counted, because a synchronization account is not a person consuming the tool.
Concurrent versus named entitlement
Dimensions can be entitled on a concurrent basis, and applying named logic to a concurrent pool overstates the count, the same trap addressed in Dimensions CM concurrent versus named licensing, which establishes which model the entitlement actually grants.
How we defend a Dimensions user finding under the four Rs
Respond. OpenText gives seven days notice before an audit and the right to copy relevant records. We take the single controlled channel and preserve the user lists for CM and RM, the role assignments, and the access history, because the user argument depends on showing what each individual actually does in the repository.
Reconstruct. We build the effective license position by classifying every account, genuine working user, read only reviewer, stakeholder, service account, or dormant entry, before any vendor measurement script runs, so the count rests on the people who genuinely work in CM and RM.
Rebut. We challenge every line that counts a reviewer, stakeholder, integration account, or finished project user as a full licensed user, and every line that applies named logic to a concurrent entitlement. The finding falls by the difference between everyone associated with the repository and the genuine working population.
Resolve. We settle on the reconstructed user count and, where it serves the buyer, convert forward into an OpenPass agreement that records how Dimensions users and roles are defined, so the next review cannot recount the stakeholders as authors.
An anonymised outcome
The reason role classification matters is the remedy behind the finding. 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 every reviewer or service account removed from the full user count strips a fourfold charge. The pattern echoes our anonymised insurance ECM case, where a seat count finding fell 78 percent from $7.2M to $1.6M after service and dormant accounts were disqualified as consumers; a Dimensions finding follows the same logic, because the inflation lives in the read only stakeholders and the automation, and once those are separated the count drops to the genuine working users.
Count working users, not everyone who can see the repository
The lasting lesson is that Dimensions CM and RM license genuine working users, not the wider population of reviewers, stakeholders, and integrations that surround a configuration or requirements repository, and a buyer who classifies every account by what it actually does holds the count to the real working population. To prepare that classification, read reconciling ALM entitlements before an audit, and to address the named definition that governs related products, read Quality Center named user definitions and traps. For the full method see our ALM and LoadRunner audit defense track and our complete OpenText audit defense playbook for 2026. If a Dimensions finding has counted your reviewers and stakeholders as full users, open a case.
When an OpenText or Micro Focus audit notice arrives, the first seven days carry more weight than any week that comes after. OpenText Audit Defense is an independent, buyer side practice founded in 2020 by former vendor compliance leadership. We have defended more than 200 audits, reduced the average finding by 68 percent, and mitigated more than $90M in claims against vendor positions. We do not resell OpenText software and we are not affiliated with OpenText Corporation. To open a case, use the contact form on this site.