This article explains why a user can appear to have the same position listed more than once in eADM, and how to confirm that the cause is a future-dated position change in Visma Enterprise HRM rather than genuinely two different positions.
Cause
Visma Enterprise HRM (VEP) is the source system for this issue. When a position change is registered in VEP with an effective date in the future (a re-organisation, a percentage change, a new manager, and so on), VEP does not simply update the existing position record. Instead, it sends two separate versions of the same position in the export:
-
One version valid from the position's original start date.
-
A second version valid from the future effective date of the pending change.
eADM imports both versions as they are delivered. Because both versions share the same PositionCodeId and most attribute values, they appear in eADM as the same position occurring twice, not as two different positions.
Note: This is expected behaviour on the part of Visma Enterprise, not an import error. It is not the same issue as a duplicate user account in Active Directory; see "Related articles" below for that separate scenario.
How to identify this in eADM
Positions tab
Open the user's profile and go to Positions. The tab header shows a count of 2 (or more) even though the user has only one real position. Selecting each entry shows near-identical position data (same APositionCodeName, AUnitName, APositionManager), which is the visible symptom of this issue.
Source data tab
The Source data tab shows the raw values eADM received for each attribute. When a position has been sent as two versions, most attributes show the same value twice in a pipe-separated pair, for example:
AUnitId: 3200|3200|
The attribute that differs between the two versions is AValidFromDate. This is the field to check to confirm the cause:
AValidFromDate: 2026-08-03|2026-11-01|
Here, the first value is the position's current start date and the second value is the future date on which the pending change takes effect. Any other attribute showing two different values (not two identical ones) marks what will change on that future date — for example a new AUnitId, APositionPercentage, or APositionManager.
Please note that the impending change may be something that is not imported to eADM, for example a wage adjustment.
Resolution
In most cases, no action is required. The duplicate is a display artefact of how VEP delivers pending changes, and it resolves itself once the future-dated change becomes current and VEP stops sending the superseded version. It does not indicate a broken account, a synchronisation failure, or a duplicate identity.
If a downstream process depends on the position count, the primary position flag, or a specific attribute value (for example, a message flow triggered by APositionStartDate), verify against the Source data tab which version is currently governing eADM's output, rather than assuming the first or the most recently added entry.
Related articles