Registration Transactions

Registration transactions track every registration action in the system. Each transaction represents a set of course adds, drops, or other enrollment changes for a single student in a single term. The Registrar Transaction view gives you a centralized place to monitor, review, and process all registration activity.

Viewing Transactions

The transaction list displays all registration transactions across all students. By default, the list excludes cancelled transactions and sorts by most recent first.

Table Columns

Column	Description
Student Number	The student's institutional ID
Student	The student's display name
Term	The academic term for the transaction
Campus	The campus associated with the transaction
Type	The transaction type (e.g., registration, add/drop)
Items	Number of course items in the transaction
Status	Current status: In Progress, Submitted, Completed, Cancelled, or Rejected
Step	Current workflow step
Override	Shows "Yes" if an override has been applied

Filtering Transactions

Use the filter bar at the top of the page to narrow results:

• Student search -- Type at least 2 characters to search by student name or number. Select a student to filter to only their transactions.
• Term -- Select a specific academic term.
• Campus -- Select a specific campus.
• Status -- Use the multi-select to choose which statuses to display. By default, In Progress, Submitted, Completed, and Rejected are shown.
• Clear -- Click the clear button to reset all filters.

Transaction Detail

Click the view icon on any transaction row to open the detail dialog. The detail view shows:

• Student information -- Name and student number.
• Transaction metadata -- Status, term, campus, type, current workflow step, and who initiated the transaction (student, advisor, or registrar).
• Override status -- If an override has been applied, the reason is displayed.

Items Tab

The Items tab shows all course items in the transaction:

Column	Description
Action	ADD or DROP
Course	Course code
Section	Section number
Title	Course title
Credits	Credit hours
Status	Item status (e.g., Approved, Pending)
Validation	Validation result: Passed, Failed, or Override
Seat	Lock icon if a seat has been blocked for this item

History Tab

The History tab shows the workflow step history for the transaction, including:

• Date and time of each transition
• From step and to step
• Who performed the transition
• Transition type (automatic or manual)
• Any notes added during the transition

Transaction Actions

From the detail dialog, you can perform the following actions depending on the transaction's current status:

Validate

Available when the transaction is In Progress or Submitted. Runs validation checks against all items in the transaction: the registration window, credit load, seats, prerequisites (with minimum grades), sequencing, campus, schedule conflicts, repeats and corequisites. Schedule conflicts, corequisites and prerequisites that are only planned are warnings. The full list is under Registration Workflows.

Submit

Available when the transaction is In Progress and validation has passed. Submits the transaction for processing. If validation fails, the system displays detailed error messages including:

• Transaction-level messages (e.g., credit limit exceeded)
• Item-level messages (e.g., prerequisite not met for a specific course)

Complete

Available when the transaction is Submitted. Processes all enrollments in the transaction -- this is the final step that creates or removes the student's course enrollments.

Cancel

Available for transactions that are not already Completed or Cancelled. Cancels the transaction. The system records the cancellation as performed by the registrar.

Override

Available when the transaction has validation failures that require an override. To apply an override:

1. Click Override to open the override dialog.
2. Enter a reason for the override (required).
3. Check the applicable override types:
   • Override prerequisite requirements
   • Override registration deadline (also lets a student in before their registration window, and lets a DROP item through after the withdrawal deadline)
   • Override credit limit (overload)
   • Override campus restriction (cross-campus approval)
   • Override course sequencing deadline
   • Override course repeat restriction (already passed, in progress, or out of attempts). This one also needs REGISTRATION.OVERRIDE.DUPLICATE.
4. Click Apply Override.

The override is recorded with the transaction and visible in the transaction detail. Your reason is also added to the transaction's notes. Overrides accumulate: applying a second one never removes the first. An excused finding stays listed, marked (overridden).

Notes

Every transaction has a Notes thread, shared by the student, the advisor and the registrar. Add a note at any step to ask a question or record a decision. Override and rejection reasons appear in the thread automatically, labelled Override and Rejected.

Notes are permanent. Once added, a note cannot be edited or deleted by anyone, so the thread is a complete record of the conversation.

Credit overload requests

A transaction submitted above the student's normal credit load is an overload request. It carries the student's reason and the term's credit total. The student's primary advisor must approve it first. Your approval then sets the credit-limit override and registers the courses. You cannot approve it ahead of the advisor, unless the student has no primary advisor. See Credit Load and Overloads.

Drop items

A DROP item is judged by the term's deadlines, as of the day the transaction was submitted. After the drop deadline it carries a WITHDRAWAL warning (it will be a W). After the withdrawal deadline it needs the registration-deadline override. When the institution requires advisor approval for students' own drops, a student's drop arrives as a one-item transaction like this. See Drops and Withdrawals.

Change Workflow Step

Available when the transaction is In Progress or Submitted. Allows you to manually move the transaction to a different workflow step:

1. Click Change Step.
2. Select the target step from the dropdown.
3. Optionally add notes explaining the change.
4. Click Change Step to confirm.

Transaction Lifecycle

DRAFT -> PENDING_VALIDATION -> VALIDATED -> PENDING_APPROVAL -> APPROVED -> COMPLETED
  ^                                                                |
  |                                                                v
  +---- rejected (with a reason; seats kept) ----+          CANCELLED

Every step before COMPLETED and CANCELLED holds the transaction's seats, so a student assembling a registration does not lose a seat to someone who started later.

Four behaviours are worth knowing at the counter:

Rejection is not a dead end. Rejecting returns the transaction to DRAFT with a reason and keeps its seats. The student fixes the problem and resubmits without losing their place. There is no separate rejected state to clean up.

Approval is all-or-nothing. Approving enrolls every course together. If any one of them cannot be enrolled — typically a section that filled since submission — nothing is enrolled and the transaction bounces back to the student with the reason. A student never ends up partially enrolled.

A held student's approval parks rather than failing. With a blocks-completion hold, the approval is recorded and the transaction waits at APPROVED; the result says APPROVED_PENDING_CLEARANCE and names the hold. Enrollment happens automatically when the hold clears, attributed to the original approver — so you do not need to chase it.

Cancelling cascades — preview it first. Giving up a transaction's courses can take down downstream plans and enrollments. The preview computes the whole consequence and writes nothing. Run it before you cancel.

At any point before completion a registrar can apply overrides, change workflow steps, or cancel.