Holds
Configure registration and account holds.
Holds mirror Colleague's restrictions. The nightly import maintains them: it creates a hold when Colleague applies a restriction and removes it when Colleague releases one. Only restrictions currently in force are imported — cleared history stays in Colleague.
Hold Types
Navigate to Admin → Registration Setup → Hold Types.
Most fields come from Colleague and are refreshed nightly. Three do not, because Colleague has no equivalent: what the hold blocks, who may place and clear it, and the transcript/graduation flags. Those are yours to set, and the import never overwrites them.
What a hold blocks
Every hold type has one enforcement level.
| Level | Plan a course | Join a waitlist | Register |
|---|---|---|---|
| Blocks everything | No | No | No |
| Blocks completion | Yes | Yes | No |
| Informational | Yes | Yes | Yes |
"Blocks completion" is the useful middle ground: a student with an outstanding balance can still build a schedule and hold their seats while they sort the payment out, and is only stopped at the point of registering. "Blocks everything" is for cases where the student should not be planning at all — a disciplinary dismissal, a medical withdrawal pending clearance.
A new hold type defaults to Informational, so an unfinished configuration cannot stop anyone registering.
Two independent flags sit alongside the level, because they have nothing to do with registration:
- Withholds transcripts — the student cannot obtain a transcript.
- Blocks graduation applications — the student cannot apply to graduate.
Colleague's three Transcripts - restrictions use exactly this combination: informational for registration, transcript withheld.
Who may place and clear it
Each hold type carries two role lists. A member of a place role may put the hold on a student; a member of a clear role may lift it. The two are separate on purpose — the office that applies a financial hold is not always the office allowed to release it.
The check is against the role you are currently acting as, not every role you hold. If you have more than one role, switch to the right one first.
WARNING
A hold type with no roles selected can only be placed or cleared by a superuser. An empty list means "nobody yet", not "anyone".
Registrars are granted both capabilities on every hold type, as the office of last resort when the owning office is unavailable.
Messages the student sees
- Resolution instructions on the hold type are the default message, imported from Colleague's self-service text. They usually explain what to do and name the office to contact.
- A message to the student on an individual hold overrides that default for that student only.
- Visible to the student controls whether the student sees the hold at all. Staff and advisors always see it regardless.
Both messages hold HTML, sanitized to an allowlist of formatting tags on the way in (paragraphs, bold, lists, links); anything else is stripped when saved. The interface renders them as markup, not as text — so a message written with tags appears formatted rather than showing its tags. Do not display the same message twice as both markup and text.
Hold Management
Placing holds
Registration → Student Holds, then Apply Hold for one student or Bulk Apply for a saved student list.
A hold with no term applies to every term, which is what all imported holds are. Set a term only for a hold that should apply to one term alone.
Reason is an internal note; students never see it. Use message to the student for anything they should read.
Clearing holds
Find the hold and clear it, optionally recording why. Cleared holds stay visible for audit, marked with who cleared them and when.
An expiration date clears a hold automatically once the date passes.
TIP
A hold released in Colleague disappears from SIS on the next nightly import. Conversely, clearing an imported hold here is undone by the next import if Colleague still shows the restriction — fix it in Colleague, not here.
A hold gates finality, not the request
This is the part that most often surprises people, and it follows from "blocks completion" above.
A student with a clearance (blocks-completion) hold can submit a registration request and have it approved. What the hold prevents is the last step — the enrollment itself. The transaction is therefore parked: its workflow step is APPROVED while its status stays SUBMITTED, and the approval decision returns the outcome APPROVED_PENDING_CLEARANCE, naming the hold that is holding it up.
The student is not sent back to the beginning, and the approver does not have to remember to come back.
Enrollment happens when the hold clears
Two paths finalize a parked transaction, and both attribute the enrollment to the original approver rather than to whoever cleared the hold:
- Inline — releasing a hold finalizes that student's parked transactions immediately, as part of the same action.
- Hourly sweep — a scheduled pass picks up anything the inline path missed (a hold that expired by date, a failure during release).
So clearing a financial hold enrolls the students who were waiting on it, without anyone re-submitting.
What an approver sees
The approval screen shows three states rather than two: completed, bounced, and approved-pending-clearance. Bounced is the all-or-nothing failure — a section filled between submission and approval, so nothing was enrolled and the transaction went back to the student with a reason. A HOLD_CLEARANCE warning marks the parked ones.
Automatic hold evaluation
Not implemented. The auto_create_query, auto_clear_query and auto_clear_script fields on a hold type are stored but never evaluated, and the run action returns 501 Not Implemented. The nightly Colleague import is the only automation that maintains holds.