Key Idea
A “policy” can refer to a university policy or a Workday policy, the latter of which is a rule set configured in the system. Policies in Workday are “passed down” from superior academic units and “inherited” by their subordinate academic units.
Policies
During the Student Sunrise project, “policy” is used in two different contexts: university policies and Workday policies. In both cases, a policy defines which rules apply to which students.
In Workday, policies are effective-dated rule sets configured to an academic unit and level or program of study that drive how students progress through their academic careers. These policies are then applied automatically by the system during the relevant processes.
- For example, WUCRSL doesn’t have a way to limit course registration based on a student’s program of study (e.g., business major) or academic unit and level (e.g., Olin undergrad), so administrators often put students on a waitlist so they can manually check each student’s eligibility before enrolling them in a course.
- In Workday, we can configure a policy, or rule set, that would allow only eligible students to register, therefore reducing the need for waitlists.
Through the Student Sunrise project, we have the opportunity to configure university policies and school-specific policies into Workday so the system automatically enforces them. In this way, Workday should help to reduce manual work and ensure that policies are applied consistently across students. As with most Workday functionality, overrides will be possible. We will determine who can perform overrides on which policies as we configure security access in the system.
Examples of configurable policies in Workday Student include:
- Which students are allowed to enroll in which courses
- During which academic periods a course section can be offered
- Grading basis, e.g., quality graded credit (known today as credit/letter grades), pass/no pass
- How many times a student may repeat a course, and how to handle those grades
- What tuition to charge a student
- How course load status is determined for financial aid purposes
- Which academic calendar should be followed to disburse a student’s financial aid
Effective dating
Policies in Workday can be effective dated to handle the appropriate application of policies when there are changes. The effective date or versioning of policies may be based on different factors, depending on the topic of the policy and where the policy is housed within the academic unit structure. Factors may include a student’s matriculation date, the academic period start date, course section start date or the current date. This is not an exhaustive list of factors.
Inheritance
By default, any policies configured to an academic unit and level apply to the subordinate academic units, unless a separate policy is set up. This top-down cascade is referred to as inheritance.
For example, any policy configured at the McKelvey School of Engineering AU will be inherited by its subordinate units, e.g., Division of Computational & Data Science, Imaging Services, etc. So, if you configure an instructor’s eligibility at the McKelvey School of Engineering AU, that means the instructor could teach any engineering course.
However, if you only want the instructor to teach electrical and systems engineering, you could “break” the inheritance and configure their eligibility directly at the Electrical & Systems Engineering AU.
Academic load and class standing are the same for most schools (divisions) and therefore are configured at the top level (WashU) and inherit down to all schools and their subordinate AUs.
If necessary, some inheritances can be broken. For instance, Online Law and the MD program have unique calendars that differ from the calendar that would sit at the WashU level.