Users Managed Through SSO and Integrations - Article

Understand how connected systems create, identify, and maintain users in Eurekos. Resolve account and profile issues with the correct owner while keeping authentication, membership, and learning access distinct.

Updated: 29 Sep 2026

6 min read

Summary

Connected identity and business systems can reduce account administration and give users a familiar way to enter Eurekos. A dependable setup requires more than a working login button: account matching, profile ownership, organizational relationships, and departure handling must fit the business process.

Use this article to:

Distinguish authentication from account creation and maintenance.
Understand where connected user information comes from.
Investigate missing history, overwritten information, and access problems without creating unnecessary duplicate accounts.

Authentication and account maintenance solve different problems

Function	What it does	Administrator question
Authentication	Confirms the person through the configured sign-in method, such as an external identity provider.	Which login route should this audience use?
Account creation	Establishes the user record in Eurekos.	Is creation performed before first login or as part of that login journey?
Identity matching	Connects an incoming identity with the intended Eurekos account.	Which identifiers prevent a returning learner from receiving a second account?
Profile mapping and updates	Supplies agreed fields from the connected source.	Which source owns each field, and when is an update applied?
Membership and learning processes	Establishes organizations, responsibilities, or participation where configured.	What additional configuration turns a recognized identity into the intended learning experience?
Departure handling	Changes access when the relationship ends.	What happens in the identity provider, Eurekos, and any other connected process?

SSO and account provisioning are therefore related but not synonymous. An integration may create users independently of login, while a configured SSO route may create the account when the person first authenticates.

Understand the supported connection model

Eurekos supports configured SAML and OpenID Connect sign-in routes. An academy can also use approved API or business-system integrations to maintain users as part of its operating process.

This article explains the administrator’s responsibilities, not the technical implementation of a connector. The identity or integration owner should maintain the approved mapping, credentials, error handling, and support arrangements. A named external system does not imply that every possible synchronization behavior is included automatically.

Match the person to the correct account

In a configured SSO flow, a new account can be created when the incoming identity has no matching Eurekos account. Existing-account matching depends on the supported identifiers and configuration. Where shared email addresses are allowed, Username can distinguish accounts that have the same email.

Before introducing a connection to an existing audience, reconcile sample identities against current User IDs and learning history. Pay particular attention to renamed accounts, changed email addresses, multiple identity providers, and people who previously registered as customers.

Do not use a second account as a convenient workaround for a matching problem. It can fragment training history and leave two identities that later require controlled consolidation.

Establish a source of truth for important fields

Information	Typical ownership decision	Why it matters
External identifier and login identity	The identity or source-system owner defines the stable mapping.	A change can affect which Eurekos account receives the login or update.
Employment, department, or job information	The approved HR or business source supplies the agreed fields.	A local correction may be replaced by a later source update.
Organization membership	Define whether the integration, central administration, or delegated organization process maintains it.	Membership affects more than a profile label and can change management or audience context.
Immediate Manager relationships	Agree which system supplies the relationship and how changes are applied.	Staff oversight should follow the intended person, not a stale text value.
Language, time zone, and preferences	Decide which values users may maintain and which are externally supplied.	A recurring update should not unexpectedly reverse legitimate preferences.
Roles	Define permitted mappings and approval for elevated responsibilities.	An external field must not be treated casually as authorization for broader administration.

There is no universal rule that every profile field is refreshed at every login. Document the behavior of the actual connection, including fields that are not mapped and updates that occur outside login.

Membership and tags require coherent mapping

Where organization-specific tags are used, a tag sent during SSO can be ignored if the user does not belong to the required organization. Check the membership relationship as well as the tag value when investigating missing segmentation.

Avoid “fixing” such a symptom by granting broader organization membership without considering its other effects. The correct result is an agreed combination of identity, membership, and profile information—not simply making every imported value visible.

Learning assignment remains a separate process. A mapped department may be an input to an onboarding rule, but the department field alone is not an enrollment record. See Onboarding Rules for the learning-assignment configuration.

Understand approval and local sign-in

New SSO-created accounts can still be subject to Pending-account approval where configured. Authentication by the external provider does not universally establish that the person should enter the academy immediately. Integration-specific exceptions must be understood within the actual setup.

Some platforms allow regular email-and-password login for SSO users in addition to the connected route. Do not assume this fallback exists, and do not assume disabling an identity-provider account automatically removes every possible Eurekos access route.

Local password recovery and identity-provider credential recovery are different support processes. Direct the person to the owner of the sign-in method they actually use.

Plan departure handling explicitly

An employee or partner leaving the source system raises several questions: will future authentication be denied, will the Eurekos account be blocked, will organizational membership change, and what learning evidence must remain?

Do not describe these outcomes as automatic unless the integration has been configured and verified to perform them. Blocking, deletion, enrollment cancellation, and certificate expiration are separate actions with different consequences.

For a temporary customer program, the source system may remain active after the training relationship ends. For an employee, the identity provider may disable login immediately while the learning team retains permitted historical evidence. The design should reflect the actual relationship and retention policy.

Common connected-user designs

Situation	Practical design	Outcome
Employee academy	Agreed identity matching, selected employment fields, manager relationships, and a documented departure process.	A consistent employee account lifecycle with fewer conflicting local changes.
Customer portal learning	Match the portal identity to the intended Eurekos account and establish the relevant organization and learning route.	The customer enters the correct learning context without unnecessary second registration.
Existing academy adopts SSO	Reconcile existing identities and learning history before enabling the new route for the full population.	Returning learners retain continuity rather than appearing as new users.
Mixed internal and external audiences	Define the approved sign-in method and profile owner for each population.	Support can distinguish an identity-provider issue from a local registration or account-status issue.

Verify the outcome

Use representative new and existing users before broad rollout. Confirm that the intended User ID is used, mapped information is correct, expected membership and learning participation exist, and a planned departure follows the approved access process. Record any differences between local and connected accounts in the support procedure.

Troubleshooting

Problem	What to check
SSO works but learning history appears missing	Compare User IDs and matching identifiers. The person may have reached a different account.
A corrected profile value changes back	Identify the mapped source and update timing before editing the same local field again.
The user signs in but has no expected learning	Check membership, profile values used by rules, the rule outcome, and the actual activity signup.
The account remains Pending	Check the configured account-approval process rather than repeatedly resetting credentials.
A departed user still has access	Review all enabled login routes, the Eurekos account status, and the agreed departure actions.
A tag is missing after SSO	Check the mapped value and whether its organizational scope matches the user’s membership.

FAQ

Does SSO update every profile field whenever someone signs in?

No universal behavior should be assumed. The connection's mapping and update configuration determine which fields are supplied and when. Confirm ownership and timing with the integration owner before correcting a mapped field locally.
Why does a user appear to have lost their learning history after SSO was introduced?

Check whether the login reached the original User ID. An identity-matching problem can create or select a different account while the history remains on the original. Resolve the matching issue before creating more accounts or considering a merge.
Where should I correct information that is managed by SSO or an integration?

Correct it in the authoritative source or its mapping whenever that system owns the value. A local profile change may be replaced at the next sign-in or synchronization. Confirm the field owner and update timing before deciding whether a local correction is appropriate.