This article outlines how Enrollment into a Session of an Instructor Led Course (ILC) works in Absorb LMS. The standard workflow involves a Learner selecting a Session after enrolling in an ILC. Admins can also enroll Learners into Sessions through the Admin Experience or the Integrations API.

Admins can enable a Department Template Setting under Courses > Catalog to hide ILCs that have no upcoming Sessions. These Courses will not appear in the Catalog until new Sessions with available seats are added. This helps reduce catalog clutter and improves course discoverability for Learners.

Manual Learner Session Enrollment

A Learner enrolls in a Session after enrolling in the ILC. The following steps outline this process in the Learner Experience.

1. Access the Learner Experience.

2. Navigate to My Courses or the Catalog. 
   

    

   • This depends on whether the Learner is already enrolled in the ILC.

3. Select the ILC. 
   

    

4. Click Choose Session or open the Sessions tab. 
   

    

5. Click Enroll. 
   

Admin Experience Session Enrollment

Admins can enroll Learners into specific ILC Sessions through the Admin Experience. This method provides direct control over enrollment and is useful for assigning training.

Standard Enrollment Process

Follow these steps to enroll a Learner into an ILC Session.

1. Access the Admin Experience.

2. Navigate to Courses Report from the Courses menu. 
   

    

3. Select the ILC. 
   

    

4. Click Enroll User.

5. Select the User. 
   

    

6. Select a Session. 
   

    

7. Click Save. 
   

ILC Waitlist Override Permission

The permission, ILC Waitlist Override, allows eligible Admins to bypass standard wait-list behavior when enrolling Learners into Sessions.

• When enabled, Admins can enroll a Learner directly into a Session, even if the Session would normally place the User on a Waitlist.
• When disabled, Admins must follow standard Waitlist rules and cannot bypass capacity constraints.

This permission is configured at the Role level under the Enrollments section and appears below Enroll Anyone. It is automatically enabled for several default Administrator Roles and may be applied to Custom Roles through migration or manual configuration.

This feature does not change how Learners interact with Waitlists and does not modify existing enrollment rules, it only controls whether an Admin can override them.

Integration API Session Enrollment

Use the Integrations API to enroll a Learner into one or more Sessions for the same Instructor Led Course (ILC) in a single request. Multi-session Enrollment requests respect the same capacity, eligibility, conflict, prerequisite, and waitlist rules that apply when enrolling through the LMS interface.

Multi-Session Enrollment Overview

Multi-session Enrollment allows an integration to submit a single request that includes a Learner, an ILC, and multiple Session identifiers associated with that ILC. The request is processed as one operation, simplifying automation for multi-day or blended programs that require attendance across several Sessions.

Depending on configuration, the operation can behave in one of two ways:

• Atomic (All-or-Nothing): Either all requested Sessions are successfully enrolled (or waitlisted, where applicable), or the entire operation fails.
• Per-Session Outcomes: Each Session returns its own result while still being processed as part of the same operation.

Enablement and Compatibility

Multi-session Enrollment is a non-breaking enhancement to existing Integrations API behavior. Existing single-Session Enrollment workflows continue to function as before and do not require changes.

• Backwards Compatibility: If a request is submitted in the existing single-session format, it is processed using the current behavior.
• Feature Configuration: Some environments may require multi-session behavior to be enabled before these requests are accepted. If multi-session requests are not yet permitted, single-session requests remain fully supported.

Submitting a Multi-Session Enrollment Request

To enroll a Learner into multiple Sessions of the same ILC:

1. Identify the Learner and the target ILC.
2. Collect the identifiers for each Session that should be included in the enrollment operation.
3. Submit a single Integrations API request that:
   • References the Learner.
   • References the ILC the Sessions belong to.
   • Includes an array or list of the selected Session identifiers.
   • Optionally specifies whether the operation should be treated as atomic or allow per-session outcomes, based on your integration design and available configuration.

The service processes the request as a single operation, applying capacity checks, eligibility and prerequisite rules, scheduling conflict detection, and other Portal policies consistently across all requested Sessions.

Validation and Outcomes

When a multi-session Enrollment request is processed, the following rules and checks are applied:

• Capacity and Waitlist: If a Session is full, the Learner is enrolled, waitlisted, or denied according to the Course and Portal settings for capacity, overbooking, and waitlists.
• Eligibility and Prerequisites: Standard checks for Prerequisites, Department and Group rules, and other access policies are enforced in the same way as in the LMS interface.
• Scheduling Conflicts: Overlapping Session times are detected. Depending on configuration:
  • In atomic operations, any conflict causes the entire operation to fail.
  • In per-session operations, only the conflicting Sessions fail, and other Sessions may still enroll successfully.
• Result Details: Responses can indicate a separate outcome per Session such as Enrolled, Waitlisted, or Failed when partial results are allowed.

Idempotency and Concurrency

Multi-session Enrollments include safeguards to prevent unintentional duplicate Enrollments and race conditions in high-demand scenarios.

• Idempotency: Repeating a request with the same idempotency key or operation identifier does not create duplicate Enrollments. The original outcome is reused.
• Concurrency Control: Locking and de-duplication mechanisms help avoid conflicting updates when multiple systems or processes target the same Sessions at the same time.

Reporting and Auditing

All Enrollments created by a single multi-session request are linked together for reporting and auditing purposes. This linkage:

• Groups related Session Enrollments under a shared operation identifier.
• Simplifies reconciliation between external systems and Absorb LMS.
• Supports downstream reporting that can identify which Enrollments were created together as part of the same multi-session operation.

Typical Use Cases

Multi-session Enrollment is particularly useful when a Learner needs to be enrolled into a series of related Sessions that function as one program or path. Common examples include:

• Multi-day bootcamps where attendance at every Session is required for completion.
• Blended learning programs combining virtual and in-person Sessions.
• Recurring or recertification programs that enroll Learners into a new series of Sessions on a predictable cadence.

Behavioral Details and Safeguards

When designing integrations that use multi-session Enrollments, consider the following behavioral details:

• Scheduling Conflicts: Overlapping Sessions are automatically detected and handled according to the chosen atomic or per-session behavior.
• Overbooking: Requests must follow existing overbook settings; API requests cannot bypass configured limits unless allowed by Portal and permission settings.
• Rule Consistency: The same eligibility, prerequisite, waitlist, and overbook logic used in the LMS interface is applied to API-driven multi-session enrollments, ensuring consistent outcomes for Admins and Learners.
• Integration Design: You can treat multi-session operations as strict all-or-nothing transactions or accept per-session outcomes, depending on the needs of your automated workflows.