There is currently no supported, configuration-level way to enroll a group of people into an LMS Learning Class. Every existing "add people to a group" tool in Rock — Group Sync, the Group Member Add workflow action, and the Bulk Update block — is unaware of the LMS and cannot produce a valid enrollment. The only built-in enrollment paths are the manual class roster and public self-enrollment, both of which are one-person-at-a-time and person-initiated.

We would like Rock to provide official ways to enroll people into a Learning Class in bulk and from automation, so that common scenarios (e.g. "everyone in this group/data view should be enrolled in this class") don't require custom plugin code.

Why the existing tools don't work

A LearningClass is a Group and a LearningParticipant is a GroupMember, but both use Table-Per-Type (TPT) inheritance — the LMS record is a subtype row layered on top of the base Group / GroupMember row.

• LearningClass : Group (Rock/Model/LMS/LearningClass/LearningClass.cs)
• LearningParticipant : GroupMember (Rock/Model/LMS/LearningParticipant/LearningParticipant.cs)

Because of this, the generic "add a group member" tools all insert a base GroupMember and never create the LearningParticipant subtype row:

• Group Sync inserts a plain GroupMember (Rock/Model/Group/GroupSync/GroupSyncService.cs, new GroupMember { ... }).
• Bulk Update inserts a plain GroupMember (RockWeb/Blocks/Crm/BulkUpdate.ascx.cs, new GroupMember()).
• Group Member Add workflow action inserts a plain GroupMember (Rock/Workflow/Action/Groups/AddPersonToGroup.cs).

The LMS reads its roster from the LearningParticipant subtype (LearningParticipantService.GetStudents → GetParticipants, which queries LearningParticipant). A base GroupMember added by any of the tools above therefore never appears as an enrolled student, even though the person is technically sitting in the underlying group. This is a silent failure: the admin sees the group updated but the class roster stays empty.

There are also no LMS-specific workflow actions and no enrollment job in the codebase today (the only LMS jobs are SendLearningNotifications and UpdateLearningProgramCompletions).

Requested capabilities

Any one of these would solve the core problem; ideally more than one:

1. A "Learning Class Enroll" workflow action. Given a person and a target Learning Class, create a proper LearningParticipant (student role, LearningCompletionStatus = Incomplete), honoring the same eligibility checks as LearningParticipantService.CanEnroll (already-enrolled, class-full, enrollment-closed, unmet prerequisites), with an option to bypass the non-critical checks for administrative enrollment. This would let staff drive enrollment from group-member-added triggers, data views, or any workflow.
2. A bulk enroll action in the LMS / roster UI. From the Learning Class roster, allow selecting a Group, Data View, or a set of people and enrolling them all as students in one action.
3. LMS awareness in Group Sync (or an LMS equivalent). Allow a Learning Class to be kept in sync with a Data View so that qualifying people are enrolled (and optionally un-enrolled) automatically. If reusing Group Sync, it would need to create LearningParticipant subtype rows rather than base GroupMember rows.
4. At minimum, guardrails. If bulk enrollment isn't built, please prevent the generic tools from appearing to enroll people into a Learning Class (e.g. exclude LMS class group types from the Group Sync / Bulk Update / Group Member Add pickers, or warn), so the current silent failure mode is less of a trap.

Notes for implementation

Rock already contains the correct, self-contained enrollment logic in the self-enrollment block — the request is essentially to expose that same logic through bulk/automation surfaces:

• Build the participant exactly as PublicLearningClassEnrollment.GetNewLearningParticipant does (PersonId, LearningClassId, GroupId = classId, student GroupRoleId from LearningClassService.GetClassRoles(...).FirstOrDefault(r => !r.IsLeader), LearningCompletionStatus.Incomplete, LearningGradePercent = 0).
• Gate with LearningParticipantService.CanEnroll(...).
• Add via LearningParticipantService.Add(...) + SaveChanges(); the existing LearningParticipant.SaveHook already creates the LearningProgramCompletion record automatically.

Because the building blocks already exist and are proven in the public enrollment flow, the incremental work to surface them as a workflow action or bulk action should be modest.

Use cases

• A membership class or volunteer track: everyone in the "New Members" group should be enrolled in the "Membership 101" class automatically.
• Staff onboarding: a workflow adds a new staff person to a group and should also enroll them in required training classes.
• Cohort management: enroll an entire small group or team into a course for a semester without hand-adding each person.

Current workaround

The only reliable option today is custom plugin code (a custom job or workflow action) that instantiates LearningParticipant entities directly. This works, but bulk enrollment is a common enough need that it should be a first-class, no-code capability.
*Claude assisted write up!