Overview
Stellic's flexible exception system accommodates diverse institutional policies and approval processes. This guide helps you design an exception workflow that aligns with your institution's governance structure, user permissions, and business processes.
Understanding Stellic Exceptions
Exceptions allow administrators to modify student audit requirements for individual circumstances. Exceptions can be made on a course or on a requirement. They can include waivers, substitutions, exclusions, moving excess credit from one requirement to another, and modifying or waiving specific audit constraints for individual students.
Exception Types
Exception Type | Purpose | Example |
Exclude Courses | Remove courses from requirements | A student has a unique situation, such as a combination of programs or transfer courses, that means they are not eligible to take a specific course from a list of eligible courses. |
Substitutions/Additional Courses | Add courses to the eligible list for a requirement, with advanced options to respect or override certain constraints within the requirement (like minimum grades) | Allow COMM 360 to count for an elective requirement |
Manually Pick/Forced Courses | Automatically fulfill requirement with selected courses, overriding all constraints | Force a transfer course to satisfy a major requirement |
Modify Constraints | Adjust specific audit rules | Reduce credit requirement from 6 to 4 credits |
Waive Courses/Requirements | Remove entire courses or requirements | Waive MATH 101 for transfer students |
Waive Constraints | Remove specific audit rules | Remove GPA requirement for specific student |
Move Excess Credits | Where courses counting towards a requirement have, in total, more credits than are required to meet the requirement, move the unneeded credits to another requirement | Count 2 credits of ENGL 102 towards free elective total requirement |
Permission Structure
Required Admin Permissions for Exception Management
student-make_exception
Scope: All programs across the student's entire record
Use case: Registrar offices, academic deans
program-make_exception
Scope: Specific program only (e.g., History Minor)
Requirements: Must also have student_view access
Use case: Department advisors, program directors
Exception Request Options
Stellic has two flags that can be turned on or off at your institution.
Advisors requesting exceptions: This enables advisors who do not have permission to make exceptions to request them. The request will route in one of two ways, depending on which structure is in place at your institution:
If your institution does not have Exception Workflows, the request will go to all admin users who have permission to make the exception.
If your institution has built Exception Workflows that apply to the student in question, and the advisor is included in a group allowed to initiate the Exception Workflow, the request will route to whichever group or individual admin user is set to approve the next step.
Students requesting exceptions: This enables students to request an exception (such as a substitution or waiver) from within their audit. The request will route in one of two ways, depending on which structure is in place at your institution:
If your institution does not have Exception Workflows, the request will go to all admin users who have permission to make the exception.
If your institution has built Exception Workflows that apply to the student, and if the student is included as an allowed initiator in the Exception Workflow, the request will route to whichever group or individual admin user is set to approve the next step.
Choosing Your Exception Process
Simple Exception Process
Best for institutions with:
Single-layer approval requirements
Advisor-level decision authority
Minimal central oversight
Process: Request → Notification to All Authorized Users → Single Approval/Denial
Initiating request: The ability to initiate a request is flag-based. There is one flag for students and one for admin (non-student) users.
Students initiate requests
Admins initiate requests
Notifications: A notification of the request will go to all admin users with permission to make the exception
Permissions: In order to approve the request, the admin user must have either student-make_exception or program-make_exception permission.
Multi-Step Exception Workflow
Best for institutions with:
Multiple approval layers required
Department/school-level governance
Centralized oversight requirements
Process: Request → Step 1 Approvers → Step 2 Approvers → [Additional Steps] → Final Approval
Initiating request: The ability to initiate a request is configured when you design the exception workflow. You may choose from one or more of these options:
Student
Admin users with a relationship with the student, as defined in the data feed
Specific individual admin users
Specific groups of admin users, as managed in Stellic
Any admin user who has permission to edit the student’s plan
Notifications: A notification of the request will follow one of these paths:
If the workflow is set to enforce order of steps, the notification will go to the approver of the next step
If the workflow is not set to enforce order of steps, notifications will go to all approvers in the workflow
Permissions: The intermediary approvers only need student_view permission. The final approver in the workflow must have either student-make_exception or program-make_exception permission.
Implementation Decision Framework
These frameworks can be mixed within a single institution, allowing different populations to use the approach that best fits their academic requirements. For example, you may have one college that only needs the simple process and another college that needs a multi-step approval process. You are not required to choose just one process for the entire institution.
1. Approval Complexity Assessment
How many approval layers does your institution require?
Which roles must be involved in exception decisions?
Are approval processes consistent across all programs?
2. Permission Strategy
Who should request exceptions (students, advisors, specific advising roles or admin groups)?
Should exception processes vary by program type?
How will you handle cross-departmental exception requests?
3. Business Process Integration
What documentation and audit trail requirements exist?
How will you ensure consistent exception application?
What reporting and oversight mechanisms are needed?
Real-World Implementation Examples
Example 1: Streamlined Liberal Arts College
Profile:
Single approval layer (academic advisors)
Student self-service encouraged
Annual exception auditing by registrar
Solution: Simple exception process with student-initiated requests and advisor approval
Configuration:
Enable student exception requests
Grant advisors student-make_exception permissions
Implement annual reporting reviews
Example 2: Research University with Complex Governance
Profile:
Multi-layer approval (advisor → dean → registrar)
Restricted student access
Centralized oversight required
Solution: Multi-step exception workflow with role-based routing
Configuration:
Disable student exception requests
Create workflow: Advisor Request → Dean Review → Registrar Approval
Implement program-specific permissions for deans
Best Practices
Start Simple: Begin with basic processes and add complexity as needed
Documentation: Establish written policies for exception criteria and processes
Regular Auditing: Schedule periodic reviews of exception patterns and outcomes. Bulk exporting CSV is a best practice for reviewing.
User Training: Ensure all stakeholders understand their roles in the exception process
Feedback Loop: Collect user feedback to refine processes over time
Additional Resources
By carefully considering your institutional needs and following this implementation framework, you can create a process for exceptions that maintains academic integrity while providing necessary flexibility for student success.