Merge Duplicate User Accounts - Article
Summary
Merge accounts when the same person has learning records under more than one Eurekos identity and a controlled consolidation is the right remedy. The operation brings supported learning history into a selected main account; it should not be used merely because two names or email addresses look similar.
Use this article to:
- Confirm that accounts belong to the same person.
- Choose the correct surviving account and understand relationship consequences.
- Review the merge and any deletion decision before committing.
- Verify transferred evidence and prevent the duplicate from being recreated.
When merging is appropriate
A learner may register personally before an employer creates another account, change an email address and register again, or receive a duplicate during an integration rollout. Consolidation can restore a coherent learning record when the identities genuinely belong to the same person.
However, shared email addresses can be intentional on a platform configured to support them. Similar names may belong to different people. An organization transfer, different job, or second learning purchase does not by itself require a new account or a merge.
Confirm identity using appropriate account identifiers, business context, and the approved support process. Do not combine the histories of different people to simplify reporting.
Establish the main account
| Decision | What to review | Why it matters |
|---|---|---|
| Surviving identity | User ID, current sign-in method, Username/email convention, and integration matching. | The person must continue using the intended account after consolidation. |
| Organizational relationships | The main account’s organization membership and intended management scope. | The documented merge retains the main account’s organizational context; do not assume every source membership is combined. |
| Learning history | Activities, progress, assessment attempts, certificates, and re-certification context. | You need a baseline to recognize a successful transfer or an exception. |
| Overlapping learning | Activities present in more than one account. | The system uses the better progress result for overlapping learning; this is not simply the arithmetic addition of percentages. |
| Operational ownership | Team/group ownership and other responsibilities that need continuity. | Consolidating learning does not remove the need to verify who is responsible afterward. |
| Source-account deletion | The deletion choice presented by the merge flow. | Deleting source accounts is permanent and must be authorized separately from merely recognizing a duplicate. |
Do not select the main account solely because it has more completed courses. If a connected system will continue matching a different account, resolve that design before committing the merge.
Understand what the merge is designed to transfer
The documented merge process transfers supported activity participation and training history to the main account. This includes learning progress, assessment information, certificates and re-certification, and related records such as supported notifications, events, and Transactions.
It also transfers the supported activity participation states and relationships. The source accounts no longer retain the transferred training history. Keeping a source account instead of deleting it does not preserve a second independent copy of that learning record. Confirm which account the person will use afterwards and correct any registration or connected-identity process that could recreate the duplicate.
Treat this as a consequential record operation. Review representative evidence before and after; do not assume it resolves every external identity, custom integration, or business responsibility automatically.
Interpret overlapping progress correctly
| Overlap | Documented result | Review focus |
|---|---|---|
| Completed and In progress | The Completed result takes precedence. | Confirm completion and related certificate evidence on the intended account. |
| Completed and Not started | The Completed result takes precedence. | Confirm the correct activity and account, especially where titles are similar. |
| Two In progress records | The record with greater progress is used. | Inspect representative learning and assessment evidence rather than expecting percentages to be added together. |
| More than two accounts in the same activity | The best progress is used among the merged accounts. | Review the affected activity and any renewal or credential context. |
Do not promise that merging two partially completed records creates a newly completed course. “Best progress” and “combine every completed fragment into a new total” are different interpretations.
Carry out the merge
- Open Users and locate the confirmed duplicate accounts.
- Select the intended accounts using the bulk selection controls. The supported merge selection is 2–10 accounts.
- Choose Merge.
- Select the intended main account in the merge dialog.
- Review the source-account deletion option and the confirmation carefully. Confirm the organizational and identity consequences before proceeding.
- Start the operation only when the selection and decision are approved.
- Allow background processing to complete, then inspect the main account and related records.
If the dialog offers deletion of the other accounts, the accounts other than the main account are permanently deleted when that choice is applied. Do not treat a deletion checkbox as routine cleanup or assume the operation has an ordinary Undo.
The merge runs in the background and can take time. Do not start another merge involving the same users merely because the full result is not visible immediately.
Check business relationships after consolidation
The main account keeps its organizational context. Review the memberships, role, and manager relationships required for future operation rather than assuming the source accounts supply a universal union of permissions.
The documented team-owner handling transfers ownership to the target account when the source was an owner. Still inspect the actual team or group, and review other feature-specific responsibilities relevant to the person.
For connected identities, verify that the next sign-in reaches the surviving User ID. Correct the originating import or integration process if it would otherwise recreate the duplicate. Merging history without repairing the cause can repeat the problem.
Realistic use cases
| Situation | Practical approach | Intended outcome |
|---|---|---|
| Personal learner becomes a customer employee | Confirm identity, select the intended ongoing account, and review organizational membership and old learning evidence. | One useful learning history without automatically combining unrelated access rights. |
| SSO rollout created duplicate learners | Correct account matching, then consolidate approved duplicates into the intended connected identities. | Future sign-ins reach the accounts holding the transferred history. |
| Administrator created an account before the user registered independently | Compare identities and participation, then select the surviving account based on future access and responsibility. | A clear account for the learner and a reconciled history for support. |
| Two accounts share an email by design | Investigate the identity convention instead of merging automatically. | Separate legitimate users remain separate. |
Verify the outcome
| Scenario or check | Expected result or evidence |
|---|---|
| Identity and sign-in | The person uses the intended surviving User ID and approved login method. |
| Representative learning | Selected activities, progress, assessment, and certificates reflect the documented transfer and overlap rules. |
| Business context | Required organizational relationships and operational ownership are correct. |
| Related records | Relevant Transaction and reporting evidence can be traced to the consolidated account. |
| Source accounts and recurrence | Source accounts reflect the chosen deletion outcome, and the upstream cause will not recreate the duplicate. |
Troubleshooting
| Problem | What to check |
|---|---|
| Merge is unavailable | Check the selection count, your permissions, and whether the intended accounts are eligible for the available action. |
| The history has not all appeared | Allow background processing and inspect representative records before repeating the operation. Escalate an unresolved transfer with account and activity IDs. |
| The user can no longer find the expected training | Confirm they are signing in to the selected main account, then inspect the transferred signup and current access conditions. |
| An organization relationship is missing | Review the main account’s intended membership; the merge does not promise to combine every source organization. |
| A duplicate appears again | Investigate the originating registration, import, or connected identity mapping. |
FAQ
-
Will merging two partially completed accounts add their progress percentages together?
No. Overlapping learning uses the better progress result. Do not assume that combining two partially completed accounts produces a completed course.
-
Does merging automatically combine every organization membership?
No. The merge retains the main account's organizational context. Review the memberships and responsibilities required for future operation rather than assuming all source relationships are combined.
-
Which account should remain after merging duplicate users?
Choose the account that should remain as the person’s continuing identity, with the correct User ID, authentication mapping, contact information, and required relationships. Review both accounts before merging because the source account is consolidated into the selected surviving account and should no longer be treated as a separate identity.