Registration Workflows
A registration transaction moves through a configured sequence of steps. The workflow decides who may act at each step, whether the transaction holds seats there, and where it can go next.
Administration → Registration Workflows.
The standard workflow
One workflow, STANDARD, ships configured:
| Order | Step | Holds seats | Who may act |
|---|---|---|---|
| 10 | DRAFT | Yes | Student, Advisor, Registrar |
| 20 | PENDING_VALIDATION | Yes | Student, Advisor, Registrar |
| 30 | VALIDATED | Yes | Student, Advisor, Registrar |
| 40 | PENDING_APPROVAL | Yes | Advisor, Registrar |
| 50 | APPROVED | Yes | Advisor, Registrar |
| 100 | COMPLETED | No | — |
| 110 | CANCELLED | No | — |
The approver is defined by the step, not by a separate setting
Who may approve comes from the step's allowed_roles configuration. There is no second place to configure approvers, and changing the step changes who can act.
COMPLETED and CANCELLED are terminal and have no role list — nothing acts on a transaction once it is there.
Seats are reserved while the transaction is open
Every non-terminal step has blocks_seats = true. A transaction in progress therefore holds its seats, so a student building a schedule does not lose a seat to someone who started later.
This is a second counter, not the enrollment count
Reserved seats are tracked separately from occupancy (course_sections.seats_reserved, migration 221). A plan reserves a seat without occupying it.
If you are writing a query or a report about section fullness, decide which question you are asking. The occupancy trigger's count and the reservation count answer different ones, and widening the occupancy predicate to include reservations would corrupt every figure derived from it.
Seats are released when the transaction reaches a terminal step.
Rejection returns the transaction to the student
There is no separate rejected state. Migration 219 added one and migration 220 collapsed it back: rejecting sends the transaction to DRAFT with a reason, and keeps its seats. The student can fix the problem and resubmit without having lost their place.
Approval is all-or-nothing, and can bounce
When an approver approves, every course in the transaction is enrolled together. If any one of them cannot be — a section filled between submission and approval — then nothing is enrolled and the transaction bounces back to the student with the reason.
Partial enrollment is not a possible outcome. A student never ends up with three of their four courses and no indication why.
A hold parks the transaction rather than failing it
If the student has a blocks-completion hold, approval is recorded but enrollment waits: the transaction sits at APPROVED with status SUBMITTED, and the approval returns APPROVED_PENDING_CLEARANCE naming the hold.
Enrollment then happens automatically when the hold is released — inline as part of the release, with an hourly sweep as the backstop — and is attributed to the original approver, not to whoever cleared the hold.
See Holds.
Cancelling cascades, behind a preview
Cancelling a transaction gives up its courses, which can take down downstream plans and enrollments that depended on them.
The cascade is previewable. The preview computes the whole consequence and writes nothing, so the operator sees what will be affected before committing. Use it.
Validation and overrides
Validation runs over every item in the request. Each finding is a blocking error, an overridable error, or a warning:
| Code | Check | Kind | Excused by |
|---|---|---|---|
REGISTRATION_CLOSED | The term, or the student's registration window, is not open | Overridable | Registration deadline |
CREDIT_LIMIT | The term would pass the student's normal load (Credit Load) | Overridable | Credit limit (overload) |
SECTION_FULL | No seat left | Blocking | — |
ALREADY_ENROLLED | The student already has this section | Blocking | — |
MISSING_PREREQ | A prerequisite rule is not met | Overridable | Prerequisite |
PLANNED_PREREQ | A prerequisite is only planned | Warning | — |
SEQUENCE_DEADLINE | A 1xx/2xx sequencing deadline has passed | Overridable | Course sequencing deadline |
CAMPUS_MISMATCH | The section is at another campus | Overridable | Campus restriction |
SCHEDULE_CONFLICT | Meeting times overlap | Warning | — |
COURSE_REPEAT | Already passed, in progress, or out of attempts (Repeats) | Overridable | Course repeat restriction |
COREQ | A corequisite is not arranged for the term | Warning | — |
A DROP item is checked only against the term's deadlines. After the drop deadline it carries a WITHDRAWAL warning (it will be a W). After the withdrawal deadline it carries an overridable DROP_DEADLINE error, excused by the registration-deadline override (see Drops and Withdrawals).
An excused finding stays on the request, marked (overridden), so the registrar can still see what was excused.
Requisites come from Colleague's course requisite rules (records.course_requisite_links, migration 285), walked through the requirement blocks they point to. Rules timed prior must be met in a strictly earlier term, and rules timed either may also be met in the same term. Rules timed concurrent are corequisites and only ever warn. Rules Colleague marks recommended are never enforced. A course meets a rule with a passing grade at or above the rule's minimum (migration 286), with a grade the rule explicitly allows, while in progress, with approved transfer credit, or when planned in an earlier term (reported as pending). See Courses.
Overrides are applied on the request with Override, which needs REGISTRATION.OVERRIDE and a reason. The reason is kept as a permanent note. Overrides accumulate: a second override adds to the first and never removes it. A repeat override additionally needs REGISTRATION.OVERRIDE.DUPLICATE.
Outside a request (planning a course, or registering a student directly), each kind of override has its own permission:
| Override | Permission node | Migration |
|---|---|---|
| Prerequisite | REGISTRATION.OVERRIDE.PREREQ | 222, 224 |
| Planned-course capacity | REGISTRATION.OVERRIDE.CAPACITY | 223 |
| Course sequencing | REGISTRATION.OVERRIDE.SEQUENCE | 095 |
| Course repeat | REGISTRATION.OVERRIDE.DUPLICATE | 096, enforced since 287 |
| Registration deadline (also drop deadlines and windows) | REGISTRATION.OVERRIDE.DEADLINE | 114; windows 289 |
Approval
Who decides a request at PENDING_APPROVAL is the step's role list. An advisor decides only for students they are primary advisor to. A student's other advisors can see the request but not decide it, and a student with no primary advisor is decided by the registrar.
A credit overload request needs both: the primary advisor approves first, then the registrar. See Credit Load and Overloads.
When the institution requires it, a student's own drop or withdrawal also arrives here, as a one-course request (see Drops and Withdrawals).
Notes on a request
Everyone working on a request (the student, the advisor, the registrar) can add a note at any step, and everyone reads the same thread. Override and rejection reasons are written to the thread too, so it holds the whole conversation.
Notes are permanent. Once added, a note cannot be edited or deleted by anyone, through any path. The database refuses it (migration 278), and a request is never deleted, only cancelled. A note is up to 2,000 characters and records its author, the role they were acting under and the step the request was at.
An override node granted to nobody is a hard block
A prerequisite override that no role holds does not mean "anyone may override" — it means the prerequisite cannot be overridden at all. If staff report being unable to override a prerequisite they are supposed to be able to, check that the node is actually granted before looking anywhere else.
Automation rules are stored but not evaluated
workflow_automation_rules exists, and the registration workflow's automation fields are stored, but nothing evaluates them. For the configurable approval engine that is implemented — leave of absence, and generic multi-stage approvals — see Workflow Engine.
Related
- Holds — parked transactions
- Credit Load and Overloads — the two-signature overload
- Drops and Withdrawals — drop deadlines and advisor approval
- Registration Windows — staged start dates
- Cohort Registration — the same lifecycle, for a whole cohort
- Transactions (registrar) — working with them day to day
- Registration API