Skip to main content
General Requirements
Updated over a week ago

General Requirements

A General Requirement is a standalone program that automatically attaches to students and/or programs based on defined criteria. Unlike programs generated from SIS data, General Requirements are created within Stellic and require explicit configurations to determine their application.

General Requirements offer three categories of criteria that define how they attach to students:

  1. Program audit criteria: References program data coming from the SIS

  2. Student profile criteria: References student profile data

  3. Manual apply: Applies to a specified list of students

Program Audit Criteria

Program audit criteria analyze specific program data to directly connect General Requirements to students enrolled in a program. . When published, General Requirements scoped with program audit criteria appear on the relevant program pages under the Programs tab in Stellic and attach to individual students who have those relevant programs.

Note: General Requirements can only attach to programs coming from the SIS, not to other General Requirements.

Available Program Audit Criteria

Criteria

Description

Program Enrollment level

Matches the defined enrollment level of a program.

Program Timeframe

Matches programs within specified timeframes (entry year or entry term).

Program school

Examines school affiliations following defined hierarchies as supported in the institution’s data structure.

Program department

Matches the department of the program, as support in the institution’s data structure.

Program campus

Matches the campus of the program, as supported in the institution’s data structure.

Program degree

Matches the degree of the program, as support in the institution’s data structure.

Program type

Matches the type of program (major, minor, certificate, etc.) as defined in the institution’s data configuration.

Program Timeframe Behavior

When a program has a ranged timeframe, Stellic verifies if the start term of the program's range overlaps with the General Requirement's range.

Example:

  • General Requirement X has criteria of Program A timeframe from Fall 2020 to Spring 2024

  • Program A’s audit has scope of Entry Year 2021-2025

  • Result: General Requirement X attaches because there is overlap between the ranged timeframe with Program A

Program School Assignment Hierarchy

General Requirements use the following hierarchy when determining program school:

  1. Review the school of the department that offers the student’s program

  2. If absent, look at the student's program's school

  3. If absent, look at the student's school

Configuration Options

To accommodate transitions from Universal Requirements, several program school matching options are available:

  • Default setting (emulates Universal Requirement behavior): Prefer program.department.school; if missing, fall back to program.school

  • Only use program.school

  • Only use program.department.school

  • Prefer program.school; if missing, fall back to program.department.school

Note: If a program has both program.school and program.department.school populated, the General Requirement can match with either of those schools.

Student Profile Criteria

Student profile criteria examine specific student data to attach General Requirements directly to a student's progress. When published, General Requirements scoped with student criteria appear on the relevant student progress pages.

Available Student Criteria

Criteria

Description

All students

Applies to all students in the system, current and future.

Student enrollment level

Matches the enrollment level of students, as defined in the institution’s data.

Student catalog term

Matches the ge_catalog_term value in student data, as defined in the institution’s data.

Student entry term

Matches students entry terms, as defined in the institution’s data.

Student school

Examines school affiliations following defined hierarchies, as defined in the institution’s data.

Student department

Matches student departments, as defined in the institution’s data.

Student campus

Matches student campuses , as defined in the institution’s data.

Student tag

Matches tags assigned to student, as defined in the institution’s data.

Student School Assignment Hierarchy

General Requirements use the following hierarchy when determining student school:

  1. Look at the student's program's department's school

  2. If absent, look at the student's program's school

  3. If absent, look at the student's school

Configuration Options

Several student school matching options are available:

  • Default setting (emulates current behavior): If a student has both student.school and student.department.school populated per the data flowing into Stellic from the institution, the General Requirement will match with either of those schools

  • Only use student.school

  • Only use student.department.school

  • Prefer student.school; if missing, fall back to student.department.school

  • Prefer student.department.school; if missing, fall back to student.school

Manual Apply

Manual Apply allows administrators to specify a list of students that should receive the General Requirement. This option can be used:

  • As the sole criterion, without any auto-apply scope

  • In conjunction with auto-apply scope criteria

When used with auto-apply criteria, the General Requirement will automatically attach to students and/or programs matching the Auto Apply Eligibility criteria, as well as to the manually specified students.

Combining Auto Apply Eligibility Criteria

Program and student criteria can be combined when defining auto-attach eligibility. When using both types of criteria:

  • The General Requirement will look for students who match ALL listed criteria

  • The General Requirement will appear only on matching students' progress pages, not on program pages on the Programs tab

Best Practices

It is recommended to use including criteria rather than excluding criteria when configuring General Requirements. Excluding criteria starts with the assumption of all possibilities and removes only the listed items, which may result in unintended inclusions if the exclusion list is not comprehensive.

Did this answer your question?