Cohort Registration

Register an entire lockstep cohort into the same sections in one action, instead of enrolling each student individually.

Registration → Cohort Registration (/registration/cohort), gated on REGISTRATION.COHORT_REGISTRATION (migration 247).

When this applies

Lockstep programs — nursing, some graduate programs — move a fixed group of students through the same courses in the same order. Registering them one at a time is both tedious and error-prone.

Only LOCKSTEP cohorts appear here. That type requires a major, a campus and a start term, and allows a student only one such membership at a time. See Cohorts for the type model.

Who can use it

Two independent checks apply, and both must pass:

1. The permission node opens the routes.
2. The service additionally requires an open cohort_advisors row for that specific cohort — or the REGISTRAR role, or superuser.

So holding the node is not enough to register any cohort: an advisor reaches only the cohorts they actually advise. A registrar reaches all of them.

Plan versus register

Planning is a separate capability, REGISTRATION.COHORT_REGISTRATION.PLAN (migration 254).

Action	Endpoint	Capability
List the cohorts you may act on	GET /registration/cohort/cohorts	node, VIEW
List a cohort's members	GET /registration/cohort/{cohortID}/members	node, VIEW
Check a section against every member	POST /registration/cohort/validate_section	node, VIEW
Plan the courses for the cohort	POST /registration/cohort/plan	.PLAN child, EDIT
Register the cohort	POST /registration/cohort/register	node, EDIT

Registrars and cohort advisors reach planning by inheritance from the parent node, so "whoever may register may also plan" holds without a second grant to keep in step. The split exists so a role can be given planning only — build the schedule without being able to commit it.

validate_section is a POST that reads

It computes each member's verdict for one section and writes nothing, so it is bound at VIEW rather than EDIT. That is deliberate: it is the call the whole screen depends on, and binding it at EDIT would 403 a plan-only role on page load and make the grid unusable for them.

Using the screen

1. Choose a cohort. Only cohorts you advise appear, unless you are a registrar.
2. The members grid lists the cohort's current students.
3. Search for a section and add it. Each member gets a verdict for that section — eligible, already enrolled, blocked by a prerequisite, no seat, held.
4. On a section where students choose their credits, set the credits for the column (see variable-credit sections). Every member is planned or registered at that value.
5. Review the verdicts, then Plan or Register.

Terms offered in the picker are scoped to the cohort's own campus, so a cohort at one campus is not offered another campus's calendar.

Section search lives on its own route

The section search this screen uses is not gated on REGISTRATION.REGISTER. If it were, a cohort advisor who may register a cohort but has no general registration grant would be unable to find a section to add — the screen would load and then be useless.

What happens on register

Each member is enrolled into each chosen section, subject to the same rules an individual registration obeys: prerequisites, seat availability, holds and the registration workflow. A member who fails a check is reported rather than skipped silently, so the outcome is a per-student result list, not a single success or failure.

Holds behave as they do everywhere else: a hold gates finality, not the request. A held student's registration can be parked and finalized when the hold clears. See Holds.

Auto-sync membership

A lockstep cohort may have auto_sync_membership turned on, which keeps its membership in step with its majors.

Auto-sync writes only its own rows

Sync maintains source = 'AUTO' memberships and never touches source = 'ODS' rows, which belong to the nightly Colleague import. Turning auto-sync on will not disturb Colleague-sourced membership, and turning it off will not strand it.

Related

• Cohorts — types, membership, ownership
• Holds — how a hold interacts with a registration
• Registration Workflows — the approval lifecycle
• Registration API