Lazy Registration Overview

Lazy registrations is adaptaption of the common term 'lazy loading' for image loading. It refers to the ability to register a learner to a course in Bright, without creating an associated registration in SCORM Cloud.

The registration is finally created in SCORM Cloud on course launch. The typical use case is to avoid the cost overhead of creating SCORM Cloud registrations that may never be launched.

Setting up Lazy Registration

lazy_registration is a CourseProvider setting that primarily changes invitation-driven registration creation:

Bright still creates a local Registration row immediately.
That row is created with externally_initialized = false.
For lazy providers, Bright does not immediately create the remote SCORM Cloud registration.
The external registration is created later (typically on first launch/initialization path), after which externally_initialized becomes true.

For non-lazy providers, invitation flows queue or run external initialization right away.

API behavior

1) Invitation APIs

Relevant endpoints include:

POST /bright/api/v2/invitation/create_multiple
POST /bright/api/v2/invitation
PUT /bright/api/v2/invitation/:id (and v3 equivalents for standard CRUD)
GET /bright/api/v2/invitation/add_learners (legacy route; still used)

In invitation processing (Invitation#handle_registrations):

New registrations are always created with externally_initialized: false.
If course.course_provider.lazy_registration == false, Bright schedules or runs external init immediately.
If lazy_registration == true, Bright leaves the registration uninitialized externally at creation time.

2) Registration API (direct create)

Direct registration create (POST /bright/api/v2/registration) is separate from invitation flow and has its own behavior:

It creates the Bright registration row (externally_initialized = false initially).
Then it attempts provider-side creation unless dont_initialize is set.
On success, it updates externally_initialized = true.

So this endpoint is not governed by invitation lazy logic in the same way; it is controlled by request flags and immediate service call behavior.

3) Course API with `include_registrations`

For course index responses that embed registrations (for example GET /bright/api/v2/course?...&include_registrations=true):

Non-lazy providers typically filter embedded registrations to externally_initialized = true.
Lazy providers relax that filter so pre-initialized invitation registrations can be included.

Important nuance: if querying multiple providers in one call, filter behavior can vary depending on provider context, so mixed lazy/non-lazy provider data may produce mixed embedded registration states.