Important Note: This feature is explicitly for use with process elements that have been deployed to a program application with the use of Deployment Rules. If your office is using process map-based app cycles, then the classic due dates system should be used. If your office has enabled the Applicant Experience and is using rules-based app cycles, then Due Dates should be used.
Note: The reference to application requirements means those process elements that have been deployed to an application.
Due Dates for rules-based requirements gives admins the ability to create due dates for process elements that have been deployed to a program application with the use of Deployment Rules. This simplified system is based solely on relative process dates which means less date management and more time to focus on other priorities.
This article covers the following topics related to Due Dates:
- Understanding Due Dates
- Creating a Global Due Date
- Creating a Program-Level Due Date
- Applicant View of a Due Date
- Frequently Asked Questions
Understanding Due Dates
The Due Dates system gives offices using Deployment Rules a modern way to help applicants manage their actions during their program application's life cycle. Instead of landing on an application page with a list of requirements to tackle, applicants can use the additional support of a due date to assist them in prioritizing tasks.
Due Dates are uniquely calculated based on relative process dates. Instead of entering a specific day, month, and year, an admin will select the number and days or weeks that occur before or after one of five critical processes: application started, application deadline, start of post-decision, itinerary start date, and itinerary end date. This process makes it such that once a due date is created, the need to return each app cycle to update dates is eliminated.
Important Note:
- Due dates for process elements only serve as a visual indicator on the application page and will not prevent an applicant from accessing the process element after the due date has been reached. It's the application deadline that, when reached, prevents an applicant from accessing their application requirements.
- Updates made to due dates are not automatically cascaded to applications. See the section "Modifying Due Dates in Existing Applications" below for details.
Permissions & Access
The following permissions are needed for use with Due Dates:
- To set global due dates: System Settings: Application Layout
- This permission grants the user the ability to access and make edits with the Application Organization feature.
- To set program-level due dates: Program Admin: Program Wizard
Global versus Program-Level
Due Dates can be set for an application requirement on both a global and program level.
A global due date means that anywhere a specific requirement is used, regardless of the program type, it will be assigned this due date. For example, if my global due date for "Passport Questionnaire" is "2 weeks after Application Started", then this due date will be applied to this questionnaire anytime it is deployed as a pre-decision requirement.
A program-level due date means that the due date created is specific to when a requirement is used for a program. For example, if I assign a due date of "1 week after Application Started" for "Passport Questionnaire" for my Global Leaders program, then this program-level due date will always take precedence over any global due date assigned to this requirement.
Due Date Logic
Due dates are based on one of the following critical processes that occur as part of an application's life cycle:
Application Created
- Due dates are calculated from the date on which an application was created.
Application Deadline
- Due dates are calculated from the application's deadline.
- Admins should note deadlines as they appear on the application, in the program date record, and in the app cycle.
Itinerary Start Date
- Due dates are calculated from the itinerary's start date.
- If a start date has not been assigned, no due date is added.
Itinerary End Date
- Due dates are calculated from the itinerary's end date.
- If an end date has not been assigned, no due date is added.
Start of Post-Decision
- If an application is not "Accepted" and not "Committed", then the due date will not appear. An application would need to be moved back to a pre-decision status to have any start of post-decision due dates reset.
- If the application status is "Accepted" or "Committed" and the decision date is in the future, then the due date is calculated based on this future decision date.
- If the application status is "Accepted" or "Committed" and the decision date is current or in the past, then note:
- If a due date has already been assigned to this requirement, then that due date remains. A due date is not recalculated when an application is moved between "Accepted" and "Committed" statuses as the application is already in post-decision, not starting post-decision.
- If a due date has not already been assigned to this requirement, then the due date will be calculated from the current date.
Modifying Due Dates in Existing Applications
When a due date is modified, this update will not automatically cascade to existing applications. Instead, after making your change, the existing applications must be refreshed before the update will appear, which can happen in one of the following ways:
- Trigger a Change to a Rule: A change to a due date alone is not an action that will be picked up by the background task which updates applications in rules-based app cycles. Therefore, after you modify your due date, you would need to modify the rule(s) associated with the program applications which need to be refreshed. The next time the rules task runs, it will cycle through your applications and make updates to the due dates accordingly. This is the recommended practice.
- Refresh an Individual Application: This can be done from the Application Admin Manager's "More Application Actions" triple-dot menu.
- Refresh Multiple Applications in Batch: This can be done from the Application Finder's batch action menu by selecting the "Refresh Requirements" option. Applications are flagged as needing to be refreshed so that they're updated the next time they are viewed. This option should be reserved for critical cases. Otherwise, we recommend trigger a change to a rule(s) and allowing the background task to run.
Important Note: Once a due date has been assigned to a requirement deployed to an application, then the due date will continue to appear on this application even if the due date is deleted at the global or program level. If you delete the due date, then future applications would not contain the due date for the requirement.
Creating a Global Due Date
Important Note: Global due dates are configured in the Application Organization section of the Admin Console. Here admins can only see whether or not a requirement has a global-level due date. No information regarding program-level due dates will be displayed.
To get started using Due Dates, follow these steps to configure a global due date:
1) From the Admin Console, navigate to Application Organization located in the "Configuration" card.
2) Within Application Organization, admins have access to a requirement layout tool that supports Deployment Rules. Use the drop-down menu of "Deployment Method" to select "Rules", followed by your desired program type, life cycle phase, program group, and/or program term.
This will result in a list of applicable requirements populating in your Application Organization display.
3) From the list of requirements that appear, a calendar icon will populate at the end of each requirement's respective row. When the icon appears as a blank calendar, this is an indication that no due date has been assigned for the requirement.
Click on the calendar icon for the requirement to which you'd like to assign a due date. This action will trigger a configuration window to appear.
4) From the "New Due Date" window, four main configuration fields appear to assist you in constructing the desired due date based on a relative process date:
Number: A minimum value of "1" must be selected.
Time: Choose between "Days" and "Weeks".
When: Choose between "After" and "Before".
Date: The options that appear here are based on critical processes that occur as part of an application's life cycle.
- Application Started
- Application Deadline
- Start of Post-Decision
- Itinerary Start Date
- Itinerary End Date
5) After all configurations are set, click "Save" to preserve your changes.
A success message indicating that your due date has been assigned will appear along with a check mark in your requirement's calendar icon. This check mark is a visual indicator to the admin that a due date exists.
You have now created a due date for this requirement on a global level.
6) To edit or delete a due date, click the calendar icon. This will open an "Edit Due Date" window from which you can take action.
Creating a Program-Level Due Date
Important Note: Program-level due dates are configured in step 5 of "Application Lifecycle" in Program Wizard. Here admins can see whether or not a requirement has a global-level due date in addition to a program-level due date.
Follow these steps to configure a program-level due date:
1) Navigate to the Admin Console > Program Finder and locate your desired program. Click on the edit pencil and navigate to step 5 of "Application Lifecycle" in Program Wizard.
2) Select "Rule Deployments" from the "Deployment Type" drop-down menu along with your desired phase. All applicable application requirements based on deployment rules for this program are displayed under one of the three requirement sections.
3) From the list of requirements that appear, a calendar icon will populate at the end of each requirement's respective row. When the icon appears as a blank calendar, this is an indication that no due date has been assigned for the requirement.
Click on the calendar icon for the requirement to which you'd like to assign a due date. This action will trigger a configuration window to appear.
4) From the "New Due Date" window, four main configuration fields appear to assist you in constructing the desired due date based on a relative process date:
Number: A minimum value of "1" must be selected.
Time: Choose between "Days" and "Weeks".
When: Choose between "After" and "Before".
Date: The options that appear here are based on critical processes that occur as part of an application's life cycle.
- Application Started
- Application Deadline
- Start of Post-Decision
- Itinerary Start Date
- Itinerary End Date
5) After all configurations are set, click "Save" to preserve your changes.
A success message indicating that your due date has been assigned will appear along with a check mark in your requirement's calendar icon. This check mark is a visual indicator to the admin that a due date exists.
You have now created a program-level due date for this requirement.
6) To edit or delete a due date, click the calendar icon. This will open an "Edit Due Date" window from which you can take action.
If a global due date has been assigned, a warning label will appear alerting the admin and noting the global due date. A program-level due date can be added which will take priority over any global due date.
Applicant View of a Due Date
When a due date has been assigned to a requirement that has been deployed to a program application, the due date will appear as follows on the application page:
This due date will appear until the applicant has completed the requirement.
Frequently Asked Questions
1) What will happen to post-decision due dates if an application is moved back to a pre-decision status?
If an application is moved back to a pre-decision status, then any start of post-decision due dates will be reset.
2) What happens if a requirement is assigned both a global due date and a program-level due date?
The program-level due date (configured in the Application Lifecycle tab of Program Wizard for a program) will always override a global due date.
3) What happens if no itinerary dates have been assigned?
If no itinerary start date exists, then a due date will not be added for Itinerary Start Date.
If no itinerary end date exists, then a due date will not be added for Itinerary End Date.
If previous itinerary dates are deleted, then the due dates will no longer display on the application page after the refresh rules activity action has occurred.
4) How do Due Dates affect reminders?
Reminders are not affected. Reminders are set for applications for upcoming due dates, so they would be based on the due dates assigned at the requirement level for rules-based app cycles.
5) Does "start of post-decision" mean the decision date or when that application entered into the post-decision phase?
The "start of post decision" refers to when an application enters into post decision phase. If you use rolling admissions and the moment an application is set to accepted is the start of post decision, then the due date would be calculated from that date.
6) Is "application deadline" calculated based on the individual application, or is it calculated at the global level?
The individual application. When someone creates an application that has deadlines associated with it, we check what the deadline is for this specific application and calculate back from that.
7) If I start an application on October 25, and the requirement due date is set to 2 weeks after application started - but my actual application deadline is November 1, how does the system calculate the due date?
With the Due Dates system, all requirement due dates are based on relative process dates. In this case, the November 1 application deadline does not pertain to the requirements. Their due date would still be 2 weeks after the start of the application.
8) I updated my due date, but I don't see the change reflected on my existing applications. Why?
When you make an update to a due date, the change is not automatically cascaded to existing applications. Those applications must first be refreshed. See the "Modifying Due Dates in Existing Applications" section of this article for details.