Recurring LP / Course Reassignment
Design Proposal — LP-Sequential with Extensions
Approach: LP-Sequential with Extensions
Extend the existing Learning Program structure to support recurring certification. The admin builds an LP as a sequence of courses, each with its own activation rule and optional end date. The LP is a stable container that grows over time — each certification cycle is a Course (or set of components) added to it.
Why this approach:
- Reuses the LP data model — well-tested, understood by admins
- Each cycle is naturally a separate Course instance (clean reporting)
- Admin gets a review/edit touchpoint each cycle (supports "Reversioned" content)
- Bounded feature list: 6 specific extensions to LP
- Lights-out automation can be layered on top in v2
Core Concept: LP as Growing Sequence
LP grows over time — one stable container, many certification cycles
Three Core Use Cases
1
Cohort-Start-Date (Annual Compliance)
Fixed calendar dates for all learners. Example: Annual IT security training, HR policy compliance.
Admin Workflow
Learner Timeline
2
Individual-Completion-Date (Badge Renewal)
Each learner's renewal activates N days after THEIR completion. Example: Product certification valid 12 months.
Admin Workflow
Learner Timeline (Per-Learner Clocks)
3
Individual-Start-Date (Enrollment-Relative)
Each learner's cycles are relative to their enrollment date. Uses existing "Shift relative to enrollment" (isEnrollAtPace). LP level only.
Admin Workflow
Learner Timeline (Shifted Per Enrollment)
Six v1 Extensions to LP
New capabilities added to the existing LP model
Benefit to Admins After v1
With these six extensions in place, the admin's recurring certification workflow goes from 8 manual steps to 1 manual step (content review):
| Step | Today (workaround) | After v1 |
|---|---|---|
| 1. Copy content items | Manual — find each item, copy individually | Automated (deep copy creates new entities) |
| 2. Copy the Course | Manual — create new Course, add items | Automated (new Course + content items in one action) |
| 3. Review/edit content | Manual — update title, add/remove items | Manual — same (intentional admin touchpoint) |
| 4. Create audience + assign | Manual — set up audience, configure dates | Eliminated (LP audience persists across cycles) |
| 5. Set start/due/end dates | Manual — per audience, each cycle | Pre-filled from previous cycle |
| 6. Handle late enrollees | Manual — figure out who needs what | Automatic (new-assignee skip logic) |
| 7. Cancel expired learners | Manual — or doesn't happen at all | Automatic (end-date batch cancellation) |
| 8. Track cross-cycle progress | Impossible (separate courses, no continuity) | Built-in (one LP, all cycles visible) |
Net result: Steps 1–2 become one action ("Copy as Next Cycle"). Steps 4–8 are eliminated entirely. Only step 3 (content review) remains manual — and that's intentional for "Reversioned" content where the admin needs to update material each cycle.
Single Schedule Principle
Core rule: The LP schedule (activation rules + end dates) is per-component and LP-wide. It is NOT per-audience. Multiple audiences on an LP are access grants sharing one schedule.
How Multiple Audiences Work
Multiple audiences = multiple access grants, one shared schedule
Channel-to-LP Audience Mechanism
- When an LP is listed as reference content in a Channel, the system auto-creates an LP audience matching the Channel's audience.
- Users who can access the Channel automatically get LP access (they become audience members).
- If an LP is listed in multiple Channels, multiple audiences are created. All share the same schedule.
- This is an access-only mechanism — it does not affect the LP's schedule in any way.
When You Need Different Schedules
Different schedules = different LPs. If EMEA needs Jan–Dec cycles and Americas needs Jul–Jun cycles, create two LPs: "Security Compliance — EMEA" and "Security Compliance — Americas". Each has its own schedule and audiences.
| Scenario | Solution |
|---|---|
| Same training, same dates, multiple groups | One LP, multiple audiences (all share schedule) |
| LP listed in multiple Channels for catalog browsing | One LP, auto-created audiences per Channel (all share schedule) |
| Same training but different cycle dates per region | Separate LPs per region (each with own schedule) |
| One group needs annual, another needs quarterly | Separate LPs per cadence |
"Copy as Next Cycle" — Deep Copy Explained
Available on all use cases via the Actions menu (...) on any LP component. Creates the next cycle with one action.
Why deep copy is required (not optional): Content-item completion is global. If Course-2027 references the same Quiz entity as Course-2026, the system considers it already complete. The new cycle is instantly "done" — defeating the entire purpose. Deep copy creates new content-item entities with their own IDs and empty completion records.
Shallow copy (broken) vs Deep copy (required)
What "Copy as Next Cycle" Does Per Use Case
| Use Case | Source | Result | Pre-filled activation |
|---|---|---|---|
| Cohort-start-date | Course-2026 (Jan 1 – Dec 31) | Course-2027 (deep copy) | ABSOLUTE: Jan 1, 2027. End: Dec 31, 2027. |
| Individual-completion-date | Renewal 1 (365d delay) | Renewal 2 (deep copy) | DELAY: 365 days after completing previous. |
| Individual-start-date | Course-1 (day 0–365) | Course-2 (deep copy) | Relative start: day 365. End: 365 days after start. |
Deep Copy Scope
| Content Type | New Entity (own ID, empty completion) | Shared (same reference) |
|---|---|---|
| Quiz | New Quiz entity + question structure | Question media assets |
| Video | New Video entity + metadata | Video file (S3/CDN) |
| Document | New Document entity + metadata | Underlying file |
| SCORM/HTML5 | New SCORM entity + config | SCORM package file |
| Exercise | New Exercise entity + rubric | Rubric templates, media |
| Event | New Event entity + details | — |
Admin UX: Interactive Prototype
No wizard, no isRecurring flag. Per-component configuration via the existing Manage Collection view. New columns: Start (activation rule) and End (end date). New action: "Copy as next cycle".
Key Design Decisions
| Decision | Result | Rationale |
|---|---|---|
| Architecture | LP-sequential with extensions | Bounded scope, existing model, admin edit window |
| Schedule model | Single schedule per LP | Audiences = access grants only. Different schedules → separate LPs. |
| v1 triggers | Cohort + Individual-completion + Individual-start (LP only) | Covers compliance + badge renewal + enrollment-relative |
| LP completion | Computed dynamically | Derived, not stored. Flips when new component activates. |
| New-assignee skip | Skip ended components only | New hires get current cycle. Rule: assignment_date > end_date → skip. |
| End-date behavior | Hard cancel + revoke | Doesn't block LP. Progress preserved for audit. |
| Stall on no-completion | Dependent never activates | Can't renew what you never earned. |
| Copy as Next Cycle | All use cases, deep copy | New content-item entities required (completion is global). |
| Badges | Orthogonal (decoupled in v1) | Avoids coupling complexity. Reversible. |
| Admin UX | Per-component config only | No wizard, no global flag. v2 adds automation. |
Roadmap
v1 — Build Now
- Per-component activation rule
- Per-component end date + cancellation
- New-assignee skip logic
- Dynamic LP completion
- Nightly batch (end-date + activation eval)
- "Copy as Next Cycle" (all use cases)
v2 — Lights-Out
- Cycle entity (group LP-components)
- Recurring config + auto-creation
- Multi-component deep copy
- Admin notification before activation
- "Deep Copy a Course" as standalone tool
Future (Unlikely)
- Per-assignment completion records
- No content duplication needed
- True LP-level recurrence
- The "dragon" — only if required
Out of Scope (v1)
| Item | Why |
|---|---|
| User-triggered reassignment ("my badge expired, restart") | Doesn't fit date-driven model; separate feature |
| Badge-as-activation-signal | Coupling creates inconsistency; decoupled is simpler |
| Lights-out auto-creation | v2 — system auto-creates without admin trigger |
| Bulk "create N years" wizard | v2 — requires cycle entity |
| Per-audience schedule overrides | Different schedules = separate LPs (single schedule principle) |
| Cross-cycle aggregated reporting | Per-Course views exist; roll-up is v2 |
| Individual-start-date for standalone Courses | isEnrollAtPace is LP-level only |
Open Items
- Deep-copy implementation per content type: Each type has own copy semantics — bounded but real engineering scope.
- Cycle-as-label vs cycle-as-entity: v2 decision. v1 just uses sequential components.
- Back-dated component UX guardrail: Confirm dialog showing affected learners (designed, not detailed here).
- Notification on cancellation: Reuses existing assignment notification system — confirm behavior.
Alternative Approach Considered: "Recurring" Auto-Copy (Approach A)
An alternative design was explored that introduces a new "Recurring" modality on LP/Course. In this approach, the system owns the schedule and automatically creates copies of the LP/Course on a cadence, managing ACTIVE and NEXT-ACTIVE states.
How Approach A Works
- New
isRecurringflag on LP/Course with cadence configuration - Nightly batch job evaluates all Recurring LPs/Courses
- System auto-creates a full copy when next recertification date arrives
- ACTIVE / NEXT-ACTIVE state machine manages which copy learners see
- Three sub-modes of increasing complexity: Fixed → Semi-Relative → Relative
- Most complex variant (badge-renewal/relative) requires badge expiration as gating signal
Why LP-Sequential (This Proposal) Is Preferred
| Dimension | This proposal (LP-Sequential) | Alternative (Auto-Copy) |
|---|---|---|
| Scope | 6 bounded extensions to existing LP model | Open-ended: state machine, deep-copy, 3 sub-modes, badge integration |
| Data model | Reuses existing LP structure | New entities: Recurring config, ACTIVE/NEXT-ACTIVE states, copy metadata |
| Content review | Admin has natural touchpoint each cycle — matches "Reversioned" need | Auto-copy happens silently; admin notification is an added feature |
| Audience overlap | Single schedule principle — clean and simple | Multiple audiences with different schedules unsolved |
| Badge renewal | Handled by DELAY_FROM_PREVIOUS_COMPLETION (per-learner) | Requires most complex "Relative" variant + badge expiration coupling |
| Reporting | Natural: each Course in LP = one cycle. One LP = full history. | Requires new cross-copy aggregation (copies are separate LPs or separate entities) |
| Risk | Lower blast radius — extensions are additive | Deep-copy of LP is a feature on its own; state machine adds failure modes |
| Path to automation | v2 adds lights-out on top of v1 primitives | Automation is built-in from day 1 (but all complexity ships together) |
Summary: The Auto-Copy approach solves the same problems but hides complexity inside automated machinery. The hard problems (audience overlap, badge renewal, content versioning) aren't actually solved better — they're just less visible. LP-Sequential keeps the complexity explicit and bounded, ships faster, and doesn't foreclose adding automation later. The one genuine advantage of Auto-Copy — lights-out scheduling — becomes v2 layered on top of v1's primitives.