User Syncing

​

LMS Integration Types

​

Tenant-Specific Integration

In this type of integration, content is pushed to a single LMS customer (tenant), and we have access to user-specific context. This allows us to match users based on their unique identifiers (SSO IDs). For each user in the LMS system, we can track progress and completions.

In this case, the user syncing flow is crucial for retrieving the user ID to handle completions properly. The SSO ID provided by the LMS will be the key identifier to link users to the content and their progress.

​

Content Distribution Integration

In this type of integration, a single StackOne linked account pushes content to an LMS, which then makes that content available to multiple customers. We do not have access to the specific user context or individual users associated with each piece of content in the LMS.

As a result, we do not have direct access to the user IDs. In these cases, we typically rely on the SSO ID used in the previous request or pass through a random user ID if specific user context is unavailable.

---

​

Unified User Syncing Flow

​

General Flow for Both Integrations

Regardless of the type of LMS integration, the user syncing flow follows these basic steps:

1. Sync Users: List users or filter users by external reference (typically matching the LMS’s provided SSO ID).
2. Handle Responses:
   • If the request succeeds (with a valid user list or external references), proceed with matching users to their respective content or completions.
   • If the response returns a 501 Not Implemented error, it means that the integration is a content distribution type, and we don’t have direct access to user context.

​

Handling Different Scenarios Based on LMS Type

• For Tenant-Specific Integrations:

  • After retrieving the list of users or filtering by external reference (SSO ID), we will have enough context to link users to their content and track completions. The SSO ID is passed as the user ID for processing completions.

• For Content Distribution Integrations:

  • Since we don’t have access to user context, the SSO ID from the previous request (if available) should be passed straight in as the user ID for tracking. However, if no user context is available:
    • Pass a Random User ID: This ensures that the request can proceed without failing due to a lack of user context.
    • Pass Query Params as a Passthrough: For integrations like Cornerstone, information will be provided in the query parameters. In this case, pass a random user ID and the entire query parameters as passthrough values to ensure the correct processing.

​

Handling Cornerstone Integration

• For Cornerstone LMS integrations, the SSO ID or user ID will be provided in the query parameters.
• When this occurs, a random value can be used as the user ID, but all the query parameters should be passed along as passthrough values, as they might contain other essential details needed for the request.

---

​

Error Handling and Return Codes

• 501 Not Implemented:
  • If the request returns a 501 Not Implemented response, it indicates that the integration is of the content distribution type. In this case, user context is not available, and we proceed with a workaround (such as passing a random user ID or using the SSO ID as the user ID).
• Missing User Context:
  • If no user context is provided (for content distribution integrations), passing a random user ID should allow the request to proceed, though tracking individual user completions will be less precise.
  • For Cornerstone, the entire query parameters should be passed through as passthrough values.

---

​

Flow Diagram

---

​

Practical Examples and Use Cases

​

Example 1: Tenant-Specific LMS Integration (SSO ID usage)

​

User Identification

To ensure reliable user matching between your system and the LMS, we provide multiple identification points:

• LMS system ID
• Email address
• User name
• Additional system-specific identifiers (returned as external_reference)

Filtering

• We support email filtering when natively supported by the LMS.
• Currently, email filtering is supported on GO1.

Recommended Sync Process

• Initial Setup:
  • Store the StackOne ID for each matched user in your database.
  • This ID is essential for creating assignments, recording completions, and maintaining user relationships.
• Ongoing Maintenance:
  • Implement a regular synchronization process:
    • Fetch current user data from /lms/users endpoint.
    • Compare against your local user database.
    • Update local records with any changes.
    • Store new StackOne IDs for newly matched users.
  • This approach ensures consistent user identification and data accuracy.

​

Example 2: Content Distribution LMS Integration (Random User ID)

For a content distribution LMS integration, since we do not have access to user context, we:

1. Pass the SSO ID from the previous request as the user ID if available.
2. If the SSO ID is not available, generate a random user ID and pass it in the request.
3. For Cornerstone integrations, pass a random user ID and include all query parameters as passthrough values.

---