Documentum federation and the multi repository count

Documentum federation links several repositories so that one identity works across all of them. It is built to keep a person consistent everywhere they go, yet an audit can read that consistency in reverse, counting the same person once in every repository they can reach.

Large Documentum estates rarely run on a single repository. Business units, geographies, and applications each have their own, and federation ties them together so that a user provisioned in one place is recognised across the federated group. Federation exists to reduce duplication, not to create it. But because each repository keeps its own account table, a self assessment script run repository by repository will return the same person in several tables, and a finding that sums those tables turns one federated identity into many licensable seats. The multi repository count is one of the most reliable sources of overstatement in a large Documentum finding, and it is also one of the most clearly answerable, because the federation is precisely the evidence that the identities are the same. Since the OpenText EULA places compliance on the licensee, assembling that evidence is the buyer's responsibility.

How federation shapes the user count

Under federation a governing repository propagates user identities to the members of the federation, so a single person has a consistent presence across them. Operationally this is a feature: access, groups, and permissions stay aligned without manual duplication. For licensing, the consequence is that the same person legitimately appears in multiple repository account tables. The licensed unit remains the person, defined by the entitlement, and federation is the mechanism that confirms a presence in repository A and a presence in repository B belong to one user, not two. The count that matters is the count of distinct people across the federation, not the sum of the per repository totals.

The principle to hold to is that federation collapses, rather than multiplies, the count. A finding that adds repository totals without deduplicating across the federation is counting the same individuals repeatedly, and the correction is to resolve every account back to the federated identity it belongs to.

Where the multi repository count inflates a finding

Per repository totals added without deduplication

The central overstatement is treating each repository as an independent population and summing them. Federation guarantees overlap, so the sum always exceeds the true headcount. Deduplicating across the federation against the governing identity is the answer, and it is the same reconciliation discipline described in how to challenge a Documentum repository headcount.

Federation members that are dormant or decommissioned

A federation can include repositories that have been retired or that hold only archival content. Counting their account tables alongside active repositories adds users who consume nothing, the same issue examined in decommissioned Documentum repositories still on the audit and in the broader pattern of Documentum repository sprawl and its license exposure.

Service and integration identities propagated across the federation

Federation propagates system and service accounts just as it propagates people, so a single non chargeable identity can appear in every member repository. Those accounts should be disqualified once, not counted many times, as set out in service and dormant accounts counted as Documentum consumers.

Defending a federated count under the four Rs

Respond. OpenText gives seven days notice before an audit and the right to copy relevant records. In that window we take over the channel and ensure the federation topology, the governing repository, and the member repositories are documented before any per repository extract is summed.

Reconstruct. We build the effective license position independently. We map the federation, identify the governing identity store, deduplicate every account back to a single federated person, and disqualify service identities and dormant or decommissioned member repositories. The reconstructed count is a count of distinct people across the whole federation.

Rebut. We challenge the finding line by line. Where per repository totals have been summed, we apply the deduplicated federated count. Where retired members have been counted, we remove them. Where propagated service accounts have been counted in each repository, we disqualify them once. Each correction rests on the federation topology and the identity evidence.

Resolve. We settle on the corrected count and, where it serves you, convert forward into an OpenPass agreement that records the federated identity as the licensed unit, so the next audit cannot rebuild the finding by adding repository tables.

An anonymised outcome

The reason a federated overcount is expensive is the standard remedy. 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 duplicated federated identity multiplies through four charges. In our anonymised insurance engagement, case file E-01, a Documentum centred ECM finding fell from $7.2M to $1.6M, a 78 percent reduction, driven by disqualifying ineligible accounts and resolving the population to genuine distinct users. In a federated estate the deduplication across member repositories is exactly that same discipline applied to a topology that guarantees overlap.

One person, one license, however many repositories

The lasting lesson is that federation is the buyer's strongest evidence against a multi repository overcount, because the feature that produces the overlap is the same feature that proves the entries are one person. A finding that sums repository tables is exploiting an architecture designed to keep identities consistent, and the answer is to show the federation and resolve the accounts back to the people behind them. The defensible count is the number of distinct individuals the federation recognises, no matter how many repositories they touch.

For a buyer, the practical step is to document the federation topology and the governing identity store, so a multi repository finding can be answered with the deduplicated count rather than the sum of the tables. To prepare that material, read how to reconcile Documentum entitlements before an audit, and to see how federation fits the wider defense, read our ECM and Documentum audit defense track. If a finding has summed account tables across a federation, open a case.

Where to go next

For the full method behind a Documentum finding, read our complete OpenText audit defense playbook for 2026. To understand how repository growth itself drives exposure, read Documentum repository sprawl and its license exposure.