Students

Manage student records and enrollment.

How Students Are Created

Students are NOT created directly. A person becomes a student when they:

1. Register for their first course, OR
2. Are enrolled by an administrator

The student record links to the person record.

Viewing Students

1. Navigate to Students > Search Students
2. Search by name, ID, or student number
3. Filter by status, program, or term

Student Record

The student record contains:

Enrollment Information

Field	Description
Student Number	Unique identifier
Status	Active, Inactive, Graduated, etc.
Initial Term	First term enrolled
Campus	Primary campus
Cohorts	Every cohort the student holds, with the dates they held it. Multi-valued, not a single field

Academic Information

• Program enrollment
• Major/minor declarations
• Advisor assignments
• Catalog year

Student Status

Status	Meaning
Active	Currently enrolled
Inactive	Not currently enrolled
Leave	Approved leave of absence
Graduated	Completed degree
Withdrawn	Withdrew from institution

Programs and Majors

Assigning Programs

1. Open student record
2. Go to Programs tab
3. Click Add Program
4. Select degree program
5. Set effective date

Declaring Major

1. Go to Majors tab
2. Click Add Major
3. Select major and catalog year
4. Set effective date

Changing Programs

• Add new program with start date
• End previous program with end date
• History maintained

Program-change emails

When a student's program or degree requirements change in the SIS, the student and each of their current advisors are emailed. The changes that send one are: adding, editing or removing a major or minor; creating a degree-progress record; creating or deactivating a requirement waiver; and approving or removing a course substitution. Bulk assignment from a cohort sends them too, one per student, after the change is saved.

The wording is two editable templates in Admin > Email Templates: STUDENT_PROGRAM_CHANGE_STUDENT and STUDENT_PROGRAM_CHANGE_ADVISOR (migration 274). Both cover program and requirement changes through the and variables.

What does not send one

Changes the nightly Colleague import makes send nothing. Sending is best effort -- a mail failure never blocks the change -- and is not de-duplicated, so one edit that touches several rows sends several emails.

Campus Assignment

The Campuses tab on a student record lists the campuses the student is attached to, split into Active and Historical (assignments whose end date has passed). A student can hold more than one at once -- a North Coast Education Center student who also takes Angwin courses, for example -- and one active assignment is marked Primary.

Who can use it: the tab needs both the tab node STUDENTS.TAB.CAMPUSES and ADMIN.CAMPUS_ASSIGNMENTS, which its data endpoints check (migration 302). Since migration 303 the Registrar role holds ADMIN.CAMPUS_ASSIGNMENTS at EDIT, plus VIEW on ADMIN.CAMPUSES for the dialog's campus list. Registrars choose among campuses; they cannot create or change them. Before 303 only the Super Administrator held the assignment node, so registrars either saw an empty table or, after 302, no tab at all.

• Assign Campus -- choose the campus, a start date (today by default) and whether it is the primary campus. The first active assignment defaults to primary.
• Edit (pencil) -- change the campus, start date or primary flag.
• Set as primary campus (the star in the Primary column) -- makes this assignment the primary one and clears the flag on the student's others. Ticking Primary in the dialog does not clear it elsewhere, so use the star to move the primary campus.
• End assignment -- sets an end date (today by default) and clears the assignment's Primary flag. The assignment moves to Historical on the day after its end date. The tab ends assignments rather than deleting them, so the history stays.

Most assignments come from Colleague

The nightly import brings in each student's Colleague home locations (ODSSTUHOMELOCATIONS) and rewrites the primary flag and end date of those assignments from Colleague every time the import runs. A change to either on an imported assignment lasts only until the next import; make it in Colleague. An assignment added here with a start date Colleague does not have is left alone.

The tab's Primary flag is also not the student's primary campus field, which the import sets from Colleague's current home location and which billing, registration transactions and cohort rules read. Setting an assignment primary here does not change that field.

Cohorts

Cohorts group students for tracking, reporting and pricing. Membership is dated and multi-valued: a student can be in Honors, Pre-Med and a nursing cohort at the same time, and leaving one does not delete the record -- it is end-dated, so the history stays. Colleague's own data goes up to four concurrent cohorts for a single student.

A student with both an undergraduate and a graduate record can also hold two federal cohorts -- one per academic level -- because that is how Colleague records an entering cohort. That is a real pair, not a duplicate; the same code appearing on both levels is collapsed to one membership on import.

What kind of cohort something is comes from its cohort type (Admin -> Cohort Types), and the type decides how it behaves:

Flag	Effect
uses_dates	The cohort itself carries a start and end date
allow_multiple	A student may hold more than one open membership of this type at once
requires_major	The cohort must name a major
allows_bulk_assign	Majors, minors and an advisor can be assigned to every member at once (on for Lockstep; migration 277) -- see Cohorts

Most cohorts come from Colleague and are refreshed nightly -- the "Pre: X" advising tags, the teaching-credential tracks, Honors, and the lockstep nursing and MBA cohorts that tuition rules key on. Those arrive as Demographic and can be reclassified here; the importer will not revert the change. Cohorts created by hand are never touched by the import.

To add or end a membership, use the Cohorts panel on the student's detail page, or assign in bulk from Admin -> Cohorts.

Communications tab

The Communications tab on a student record lists every staff email the SIS sent that student (staff-to-student email, migration 268), newest first, with the sender and the message body. It never shows the message's other recipients.

It is gated on COMMUNICATIONS.STUDENT_HISTORY (migration 272), an action node granted only by explicit row: Advisor at ADVISEES, Academic Administrator at UNIT, Registrar and Super Admin at ALL. The scope is applied per student, so an advisor sees the tab only on their advisees. Faculty, who can send mail to their sections, cannot read other staff's mail to a student, and students do not see this tab about themselves.

Notes tab

The Notes tab holds notes staff write on the student's record (migration 308). How staff use it is in the user guide: Student Notes. Notes cannot be edited or deleted by anyone, administrators included; the author can only widen who sees a note or retract it.

Who gets the tab

The tab is STUDENTS.TAB.NOTES, a child of STUDENTS.SEARCH like the other student tabs, so every role that can open the student record has it, with the same scope: Registrar for all students, Advisor for their advisees, Academic Administrator for their unit. Faculty also hold it at OWN_SECTIONS, which opens the notes, and nothing else on the record, for students enrolled in a section they teach in a term that has not ended. Every notes action, writing included, needs only View on the tab.

Three further nodes widen what a role can read. They sit at the root of the tree, so no role can inherit them; a role gets one only by an explicit row, and only Registrar is seeded with them:

Node	Allows
STUDENTS.NOTES.VIEW_ALL	Reading every note on a student that is not private, including retracted notes
STUDENTS.NOTES.VIEW_PRIVATE	Revealing private notes: a written reason, logged, opens them for 30 minutes
STUDENTS.NOTES.ACCESS_LOG	Reading the log of private-note reveals

Grant these sparingly. Private notes exist so that an author can keep a note from everyone else, and every reveal is logged with its reason.

Students read the notes shared with them on My Notes (STUDENT.MY_NOTES, granted to the Student role).

What can be configured

Setting	Where
Note categories (General, Advising, Academic Concern, Conduct, Records, Financial)	The NOTE_CATEGORY lookup, under Admin > Lookup Tables
Files allowed on notes	The NOTES surface under Admin > Email Sending > Attachments. Seeded on, with PDF, Word, Excel, PowerPoint, CSV, text and image files, up to 5 files of 5 MB each and 10 MB in all, always inside the organization-wide ceiling
Notification emails	Admin > Email Templates: STUDENT_NOTE_ADDED goes to staff a note is shared with, STUDENT_NOTE_SHARED_WITH_YOU to the student

Keep note content out of the email templates

The notification emails deliberately carry only who wrote a note, about which student, and a link. Their variables do not include the note's subject or text; do not add them by hand. The link is built from the server's APP_PUBLIC_URL, which defaults to SAML_SP_BASE_URL.

Note tables are not row-audited, so note bodies never reach the general audit log. The notes carry their own record of who added, shared and retracted them and when, and the private-note access log records every reveal.

Student Lists

Create saved lists:

1. Navigate to Student Lists
2. Create static or dynamic lists
3. Use for communications, reports

Related Topics

• Person Records
• Registration