Constraints - Restricting criteria

• May only be satisfied manually by an institution [Primary Constraint]
• May only be satisfied by a course set manually defined by an institution [Primary Constraint]

---

Constraint Details

Restrict based on term

Count [xx-xxx] only if taken at [x] term [xxxx] year or later and if taken at [x] term [xxxx] year or earlier with section [x] [Primary Constraint]

• Requirement can only be met if the course is taken during and before or during and after a specific term and/or with a specific section. You do not need to specify the section if you're just looking to add the constraint on the course level, and not a specific section level.

Allow ungraded courses to count for specific terms only [Secondary Constraint]

• This will allow courses that are ungraded, or have grades that are not factoring into the GPA, to count for the requirement. This is usually used for Pass/Fail grades. This constraint will allow P or Passed grades to count. A common use for this constraint were the extenuating grading circumstances that happened for many universities in Spring 2020 with COVID 19 changes.

 

Only count courses taken before/after specified term, or in the given range [Secondary Constraint]

• This constraint will limit the courses listed in the constraint to only be counted if they were taken during the time range specified in the constraint. This constraint does not allow for the term that you list to count - for example, if you state that you can only count BIO 100 if taken before Spring 2021, the course would count if it was taken during Fall 2020 or earlier. 
  • You can add courses to "Allow Additional Courses Regardless Of Term" field, which would allow these courses to count even if they were taken outside of the range specified. 

 

Do not count courses taken prior to [x] years before the current term. [Secondary Constraint]

• This constraint is similar to the one above, with the exception being that instead of specifying a term, you specify the number of years prior to the current term where a course cannot count. This constraint is particularly useful for any program that enforces a term limit on how old courses are allowed to be in order to count toward requirements. This constraint is dynamic and will move with time - in other words, it looks at the term you're currently in, and will not allow courses taken prior to [x] number of years before that.
  • Within this constraint, you can specify that additional courses can count regardless of the term they were taken. In the event that there are courses that are always accepted, or to allow the user to exception in courses that are able to be taken prior to the time limit. 

 

---

 

Restrict based on requirement/program

Only courses from the following subrequirements can count toward the units total [Program Level Constraint] [Secondary Constraint]

• Can only be used once the "at least [x] units in total" constraint has been added.
• This requires only the courses and requirements listed within this program to count toward the total units required - courses that fall outside of the program will not contribute to the units in total.

 

Only the courses counting towards the current program will be considered for this requirement. [Primary Constraint]

• This constraint can be added to a subrequirement which enables that subrequirement to only double count courses that are already counting requirements within the same program. This can also be added to a shared requirement to dynamically attach to and check any program where the shared requirement resides.
• Uses of this constraint may include scenarios such as:
  • You want to add a requirement that checks for a specific combination of characteristics that can't be managed within other constraints. For example, the subrequirement below is used to verify that out of all of the courses within a minor, there are at least 8 units of upper division courses that have a GPA of at least 2.0.

 

For plans with [x] programs, only the following [y] subrequirement can be used [Secondary Constraint]

• This constraint can be used to specify a specific sub-requirement that students in a particular program (major/minor/etc) must take. This is very useful for Core or General Education requirements that may be similar, but not the exact same, for all students. If the majority of the student population can choose Math or Honors Math, but students in the Physics major must take Honors math, build out as shown below.
• Note that you must have the sub-requirement categories built before you can select them in the constraint. You can select multiple programs and/or multiple sub-requirements. 

 

For plans with [x] programs, any of the following subrequirements can be used except [y] [Secondary Constraint]

• Similar to the above constraint, this specifies that for students in a specific program  (major/minor/etc) they cannot fill the requirement using a specific category or sub-requirement. This is very useful for Core or General Education requirements that may be similar, but not the exact same, for all students.
• Note that you must have the sub-requirement categories built before you can select them in the constraint. You can select multiple programs and/or multiple sub-requirements.

 

This requirement can only be used for plans with the following programs: [Secondary Constraint]

This constraint is somewhat similar to For plans with [x] programs, only the following [y] subrequirement can be used, with the caveat being that this constraint adds the ability to add in a requirement to a list of courses that can only be used by particular majors. This can come in handy for scenarios like general education requirements that are applied to large swaths of students, but only some are able to use a particular course or requirement. In the example below, FIN 303 is part of a larger list, but is only allowed to be taken by students with an Accountancy major.

This requirement will not appear for students not in the programs specified - it will be hidden from students that it doesn't apply to when they view their audit. This feature is unique to this constraint - other constraints are visible for all students. Admin users will still see this constraint. 

One other important note about this particular constraint is that it only functions if the student has a published audit for their program. In the example below, this requirement will only apply to the student if the Kinesiology audit has been published.

 

---

 

Restrict based on tag/attribute

For students with [x] student tags, only the following [y] subrequirements can be used [Secondary Constraint]

• This constraint is similar to the ones above, but restricts students to specific subrequirements based on the student's tag. This constraint can only be used by institutions that have implemented student tags.

For students with [x] student tags, any of the following subrequirements can be used except [y] [Secondary Constraint]

• This constraint is similar to the ones above, but excludes specific subrequirements to students based on the student's tag. This constraint can only be used by institutions that have implemented student tags.

 

---

 

Restrict based on grades

At most [x] courses/units with defined grades [Secondary Constraint]

• This constraint allows you to dictate how many courses above or below a certain grade, or how many transfer courses, can be allowed to count for the requirement. To make sure that no courses of a certain grade or no transfer courses would fill the requirement, set the count to ‘0’.
• You can select the scope of the "defined grades" to be:
  • Grade, Grade or lower, Grade or better, Multiple grades, Transfer grades, Transfer status

 

At most [x] courses/units with transfer grades [Secondary Constraint]

• This constraint checks for if the grade of a course is marked as a transfer grade within the backend of the system (this would have been established during initial Stellic set up - contact your campus Stellic admin for more information), and then limits the number of units of courses with transfer grades. There can be multiple grades that fall within this constraint (for example, if your institution used all of these for various types of transfer credit, they would all fall under this constraint: T, TA, TR, etc.)

 

The following courses [x] will not count with these grades [x] [Secondary Constraint]

• This constraint allows you to specify a grade criteria for specific courses (or courses with attributes, course range, or a course pattern) that are exceptional to the rules. In the example below, C- is the standard grade for the courses in the program, but we want computer science courses to have a higher grade standard than the other courses.

 

---

 

Restrict based on course/course type

Count [xx-xxx] only with topic [x] [Primary Constraint]

• This constraint allows for only a particular topic of a course to be used. (Note: this can only be used if your institution uses course topics.) In the example below, only one particular topic of the course can count - all other topics within HY200 cannot be used for the requirement.

 

Count [xx-xxx] only with section [x] [Primary Constraint]

• This constraint allows for only a particular section of a course to be used. All other sections of the course will not count for the requirement.

 

Exactly [x] courses/credits from a given course set [Primary or Secondary Constraint]

• If you have courses or requirements where students can potentially take a variable number of units, but you need them to take no more and no less than a specific number of courses or credits, this constraint will require students to take the exact number specified. In the example below, GPHY 5980 is a course that can be a variable number of credits, and students are required to take exactly 4 credits of this course.

 

At most [x] courses/units from a given course set [Secondary Constraint]

• This constraint limits the highest number of units that can be taken from a course set.

 

At most [x] courses/units excluding the given course set [Secondary Constraint]

• This constraint limits the highest number of units that can be taken from courses that do not include the courses specified

• Specifying "0" causes the constraint to not allow any units for that requirement.

 

Do not count courses from a given set [Secondary Constraint]

• This constraint should be used if you don’t want to count a course or a specific list of courses from a requirement. This also utilizes the course set behavior, so you can also limit courses based on ranges, attributes, or patterns.

 

Courses with codes between [xx-xxx] and [xx-xxx] do not count [Secondary Constraint]

• This constraint can be used when you have courses in a range that should not count.

 

At most [x] courses/units with transfer status [Secondary Constraint]

• This constraint checks to see if the type of the course is marked as a transfer status, and then limits the number of units of courses with transfer status.

 

Courses must be chosen from [x] different subject codes [Secondary Constraint]

• When there are multiple subject codes as options to choose from and students are required to take a diverse array of courses, you can specify that students must take courses from [x] number of different subject codes. In the example below, students must take four language electives courses in total, and the course patterns indicate that they can be from the Chinese, French, German, or Spanish departments. The second constraint dictates that the four courses must be chosen from two different subject codes.

 

At most [x] courses/credits from each of the following subject codes: [xxx, xxx] [Secondary Constraint]

• This constraint allows you to restrict the number of courses or credits taken within a particular subject code or codes. A possible use case for this constraint is if your institution or program requires students to take a diverse set of requirements, or if they are limited to the number of credits taken from one particular area. Within the constraint, you are able to provide a subject code, or multiple subject codes, or leave it blank (see example in the next bullet).

• The example below shows a requirement that was built where students have to take 120 credits, but are limited to 51 credits from any one subject code.

---

 

Manually satisfy

May only be satisfied manually by an institution [Primary Constraint]

• This constraint can only be used on its own and cannot be paired with another constraint.
• Use this constraint if you want more control over a certain requirement, and wish to have it manually satisfied by an admin or advisor. This works great for requirements where a student has to petition for a course to count as a credit, or for experimental courses that are not in the course catalog. This requirement will only be filled once an exception has been added.

 

May only be satisfied by a course set manually defined by an institution [Primary Constraint]

• The course set is decided by the advisor and can be different per student. The user must edit the constraint to change the course set. There is the option to set a default course set if desired.