All resources, including articles, video instruction, and a list of FAQs related to Deployment Rules can be found in the Deployment Rules Learning Resources article. 

With the use of Deployment Rules, an admin is able to manage how process elements are deployed to an application in Terra Dotta without the need for process maps. Instead, an admin creates rules based on logical conditions that, when met, dictate when a process element is deployed to an application.  

This article discusses the following topics related to Deployment Rules:

• Important Considerations
• Access & Permissions
• Understanding Deployment Rules
• Creating a Deployment Rule
• Auto-Generating Rules
• Scheduled Task for Updating Applications
• Process Element Modifications
• Making Changes to Deployment Rules
• Refreshing Rules within an Application 
• Using Location-Based Conditions
• Application Organization
• Rules Management
• Video Instruction
• Webinar: Time for a Change: Transforming your Terra Dotta Study Abroad Experience with Deployment Rules

When your office is ready to transition to Deployment Rules, refer to the Transitioning to Deployment Rules article for suggestions to assist during that process.

After your office has started using Deployment Rules, refer to the Managing Deployment Rules article for details on common "I Need to Do X" scenarios.

 

 

Important Considerations

The Deployment Rules feature is part of the Configuration menu of the Admin Console. 

As you explore the use of Deployment Rules with your office, make note of these important considerations:

• The Applicant Experience must be enabled on your site in order to use Deployment Rules.
• In addition to deploying process elements to applications, Deployment Rules are used to manage application (app) cycles in the App Cycle Management feature of the Admin Console. Activating rules-based deployment for an app cycle is the action which officially turns on Deployment Rules on your site. Therefore, if you want to use rules-based deployment for process elements, you must do so in conjunction with the use of rules-based deployment for managing your app cycles. Offices transitioning from process maps to Deployment Rules will likely enable rules one app cycle at a time until they've fully transitioned to this feature.
• The use of Deployment Rules means a move towards transitioning to the end of using process maps on your site. This change must be fully communicated to all staff admins before the transition from process maps to rules-based deployment occurs. It is recommended that you reset site permissions accordingly to prevent staff from making changes to process-map related items in the main "Process" menu once you transition to using Deployment Rules. 
• After you begin using Deployment Rules on your site, it will be difficult to revert back to the use of process maps. If your process maps are not configured correctly, this will create problems for applications that are in these app cycles. Therefore, it will be required that you submit a Support request as only someone with the Maintenance > Unrestricted (Super User) permission (e.g. Support) can disable Deployment Rules. Additionally, the Terra Dotta Support team will need to ensure that your process maps for your app cycles are configured properly before a return to process maps is made.
• For offices using the Starting App Cycle and Ending App Cycle features, be sure to re-order your site's terms accordingly. See the "Creating a Deployment Rule" section of this article for details. 
  

A transition to Deployment Rules also means a shift in how you might have approached certain business processes in Terra Dotta Study Abroad in the past. The following list is of classic features that are not compatible with Deployment Rules:

• The classic progress audit.
  • Use the Application Finder's Progress Audit tool for applications in rules-based app cycles. 
• The classic advising phase functionality.
  • Use the Advising Program, which is its own program type, with rules-based app cycles.
• The classic due dates system based on calendar dates.
  • Use relative due dates as detailed in the Due Dates for Rules-Based Requirements article.
• OneStep and Proxy registration.
  • All application requirements can be viewed on the same page in the Applicant Experience. If your programs have been using OneStep registration, you will want to change any HTML for your "Apply Now" buttons to use the HTML found on the "Settings" tab of your respective program.  Refer to the Using the Program Wizard article for details on the "Create Apply Button" feature.
  • By default, the program types of Travel Registration and Incident Report allow users to create multiple applications for the same program in the same app cycle. View details in the Adjusting Application Limits article.
• The application parameter types of "file", "number", and "date type" are not supported as conditions for rules.

Rules-based app cycles should use Reviewers Management for Terra Dotta Study Abroad.

Rules-based app cycles should use Recommendations for Terra Dotta Study Abroad.

Terminology

The term "rules-based" refers to app cycles which have Deployment Rules enabled and thereby use this system to deploy requirements to applications. "Process map-based" refers to the classic functionality of using process maps to manage how requirements are assigned to applications in app cycles.

Process elements are often referred to as the building blocks of an application and consist of such elements as questionnaires, assessments, and learning content. As these items are assigned to applications to be completed by applicants, they are often referred to as "requirements" or "application requirements".

 

 

Access and Permissions

Deployment Rules can be accessed as follows:

1) From the Admin Console, navigate to the "Configurations" menu.
2) Click on "Deployment Rules". 

This feature is available for use by administrators with the following permissions:

• Process Admin: Application Cycles (View)
  • Users with this permission have read-only access to Deployment Rules.
• Process Admin: Application Cycles (Add) or (Edit)
  • Users with this permission have read-write access to Deployment Rules.

Important Note: Deployment Rules are available for viewing and editing by all staff with the relevant permissions and not only the individual who created them as Deployment Rules are global across the client account.

See the Admin Console for Terra Dotta Study Abroad article for information on DAOs (data access objects).

The Deployment Rules landing page includes a central search field which supports the following types of searches:

• Exact quoted search. Place quotation marks around a phrase, such as "Global Paris Program", to pull in only those rules matching this exact name. 
• Keyword. Type your search text into the available field. The results produced are inclusive of all rules that contain any of the keywords entered. When more keywords are used, the more likely your results will be broad and numerous because the system will return any name that contains one or more of the keywords. A minimum of three characters must be entered in order to trigger the search to run.

Clicking on the triangle "Filter Results" icon opens up a panel from which you can apply filters from the following categories to narrow down your search results:

• Program Type
• Program Group
• Terms
• Phase
• Process Elements
• Auto-Generated Only

 

Checking the "Active Only" filter results in only displaying those rules marked as active on your site.

For sites that have not yet started using Deployment Rules, a "Generate Rules" link will appear in-line with the search field (see the "Auto-Generating Rules" section of this article for details). After a site has manually generated a minimum of ten Deployment Rules, then the "Generate Rules" link will be automatically hidden. 

Information on the main Deployment Rules page is organized into columns (from left to right) as follows:

Rule: This is the name assigned to the rule.

Phase: This is the applicable application phase.

Active: A toggle switch indicates if a rule is in use (active) or not (inactive).

Actions: Click on distinct icons to take the following action: 

• Expand Quick View. See a rule's configuration and details which include:
  • Starting App Cycle: The term and year from which the rule will begin deploying requirements. This is an optional setting which helps admins to further control deployment. 
  • Ending App Cycle: The final term and year through which the rule will deploy requirements. This is an optional setting which helps admins to further control deployment.
  • Conditions: Criteria that must be met in order for the rule to deploy the assigned process elements.
  • Last Modified: When a rule is edited and that change is saved, then the system will record a date/time stamp of that activity along with the name of the user that performed the action. Serves as a reference point for when the "application requirements" task should have picked up the rule change to update applicable applications. 
  • Deploy: A list of process elements assigned for use in applications when all conditions of the rule have been met
  •  
• Edit Rule. Make changes to an existing rule.
• View Applicable Program Applications. See a list of programs affiliated with a specific deployment rule. This list does not take into consideration any applicant parameters or applicant types are these are applicant-specific conditions.
• Delete Rule. Permanently remove a rule from your site. This action should be performed with care. This action is not currently logged in the system. A rule might be deleted when:
  • The rule was for use with a program you no longer offer.
  • You have combined a rule with another, and it is no longer needed.
• Collapse All/Expand All. For a comprehensive view of the settings, conditions, and requirements associated with a specific group of rules, you can apply your search filters, generate your results, and expand all rules. In this way, an admin can easily scroll through the full details of each rule or use the CTRL + F action to locate a specific word or phrase within the listing. Use the "Collapse All" action to close all rule details.

By default, rules are listed from A to Z but can be sorted to display from Z to A.

The columns for "Rule", "Phase", and "Active" can be sorted by hovering your mouse over these column headers and clicking on the arrow icon that appears.

Paginated search results give the admin the ability to increase (250 items maximum) or limit the number of items which appear per page.

 

 

Understanding Deployment Rules

Deployment Rules consist of a set of conditions that the admin defines in step one of the rule configuration process. When the defined conditions are met for a program application, then a series of process elements (defined in step two of the rule) are deployed by the system to that application. This process is known as rules-based deployment of a process element. 

Deployment Rules are used in conjunction with the Content Management section of the Admin Console. After an admin creates process elements in Content Management, an admin has the option to "Add and Create Rule". This action records the new process element in the system and navigates the admin directly to a "Rule Configuration" modal in Deployment Rules. From here, the admin can configure the settings and conditions for the rule, and the new process element will automatically appear as a selected requirement to deploy in step two of "Process Element Deployment".

 

 

Configuration Logic

When creating a rule in the Deployment Rules feature, the first step is to specify which conditions must be met before the process elements in step two are deployed to an application. The software uses logic (e.g. truth values like "and", "if", and "or") to manage the presence of multiple conditions in a rule as follows:

• Within a single condition type, "OR" logic is used to match a set of conditions.

Example: "Program Group" is a single condition type. In step one of your rule, you can specify multiple program groups based on this one condition type:

"Program Group - In - Program Group A, Program Group B, Program Group C"

Because these conditions are based on the same condition type, "OR" logic will be used. An application would need to be created for a program in Program Group A OR in Program Group B OR in Program Group C for this condition to be met.

Important Note: For Applicant or Program Parameter conditions, the values must be set before the application is created. If the application is created but the parameters are not populated for the applicant or program, the application would need it's rules refreshed for the deployment rule to deploy it's content to the application. See Refreshing Rules within an Application for instructions on refreshing rules. 

• When multiple condition types are used, "AND" logic is used between condition types. 

Example: "Program Group" is a condition type. "Term" is different condition type". In step one of your rule, you can specify multiple conditions based on multiple condition types:

"Program Group - In - Program Group A, Program Group B"

"Term - In - Spring, Fall"

Because two different condition types are being used, "AND" logic will be used between each condition type. An application would need to be created for a program [in Program Group A OR in Program Group B] AND [in Term Spring OR in Term Fall] for the conditions of this rule to be met.

After all conditions have been met for a rule based on the logic outlined above, then the specified process elements for that rule will be deployed to the applicable program application. 

Configuration Considerations

When assigning conditions to a deployment rule, it's important to keep the logic described above in mind. If multiple condition types, especially those for both program types and programs, are applied to a single rule, the result could be such that an applicant would never meet all of the conditions of that one rule. If that were to occur, the requirements of that rule would not be deployed.

Example: An admin creates a deployment rule with the following conditions:

• Program Groups: Exchange, Faculty Led, Go Abroad Consortium, Global Leader Programs
• Program Type: Outgoing
• Program: Terra Dotta University 

This condition reads:

When the condition of program groups in Exchange or Faculty Led or Go Abroad Consortium or Global Leader Programs AND the program type of Outgoing AND the program of Terra Dotta University is true, then deploy X requirements.  

Based on the conditions used in the rule and knowing that "And" logic is used between condition types, the admin has created a scenario where it might be unlikely that an applicant would meet all of these conditions. Why? Because the program of Terra Dotta University would need to also be in one of the four assigned program groups as well be of the same program type that's been assigned. All conditions of a rule must be met in order for that rule to deploy the assigned application requirements.

A recommended approach would be to remove the condition of "program" from this rule and create a separate deployment rule for the condition of "program".

Rules and App Cycles

An app cycle must be configured to use Deployment Rules so that it properly deploys application requirements when the conditions of active rules are met. If you have Deployment Rules created on your site but have not configured an app cycle to use Deployment Rules, then the rules won't do anything. 

App cycles are configured to use Deployment Rules in App Cycle Management. Deployment Rules can be enabled for app cycles containing existing applications.

In addition, it is possible to move existing applications from a process-map based app cycle to a rules-based app cycle. Before taking this action, note:

• Any application requirements that were completed in the process map-based app cycle will transfer to the application in the rules-based app cycle.
• If an application requirement was saved but not completed - and it is not a requirement being deployed by a rule, then it will not transfer from the process map-based app cycle to the rules-based app cycle.
• Applications will be updated immediately upon being moved from the process map-based app cycle to the rules-based app cycle.

 

 

Creating a Deployment Rule

To create a new Deployment Rule:

1) Navigate to Admin Console > Deployment Rules.

2) Click on the "+" sign in the lower right corner of the page. This will open a new "Rules Configuration" display.

Important Note: If you have entered information into a new configuration window and decide to cancel your work, you can exit from the window by clicking the "X" icon or the "ESC" button on your keyboard. Any data entered will not be saved. 

3) In the field for "Title", assign your rule a name. The suggested best practice is to use descriptors which reference the conditions which comprise your rule.

The system does not prevent you from creating a rule with the same name as an existing rule. Therefore, offices should keep this in mind when creating and managing rules. 

4) Select the applicable application phase. A drop-down menu is provided. The phase "Pre-Decision" is populated in this field by default.

5) Select the starting app cycle for which you want the rule to begin being used. This action is optional. If a starting app cycle is not selected, then the rule will deploy requirements upon being set to "active" status to applications which meet the condition of the rule.

A drop-down menu is provided which lists your site's terms. The rule will not start until the selected starting app cycle has been reached, and this is based on a combination of the term order on your site and year.

First, the system looks at the order in which your terms appear under Settings > Terms, so it is very important that your terms are ordered chronologically as desired. Next, the system looks at the year assigned to the term.

For example, imagine that the terms on your site are listed as follows:

• Winter
• Spring
• Summer
• Fall

When the starting app cycle for a rule is set to "Spring 2021", then this means that the rule will be deployed to app cycles for Spring 2021, Summer 2021, Fall 2021, and everything into the future. It will not be deployed to any of the terms prior to Spring 2021, such as Winter 2021, Fall 2020, Summer 2020, and so forth.

If your site currently has your terms listed in alphabetical order, it is recommended to re-order them to your desired chronological order. Otherwise, the following scenario may occur where you find yourself not seeing a rule being applied to an application as expected:

Imagine your terms are ordered as follows:

• Fall
• Spring
• Summer
• Winter

You set a starting app cycle for a rule for "Spring 2021". In this example, the rule would apply to Spring 2021, Summer 2021, Winter 2021, Fall 2022, Spring 2022, and so forth into the future. It would not apply to Fall 2021, Winter 2020, Summer 2020, etc.

6) Select the Ending App Cycle. This action is optional. Setting an "Ending App Cycle" allows the admin to specify the final app cycle through which they want a rule to deploy requirements. After the ending app cycle, the rule will no longer deploy requirements. If an ending app cycle is not selected, then an active rule will continue to deploy requirements to applications which meet the condition of the rule.

In the example image below, the admin has set the "Starting App Cycle" and "Ending App Cycle" for the same app cycle of Advising 2021. This means that the rule will only deploy requirements to applications (when its conditions are met) from the beginning through the end of the Advising 2021 app cycle.

Example 2: If a rule is configured with a starting app cycle of Spring 2022 and an ending app cycle of Spring 2023, then the rule will deploy requirements beginning with Spring 2022 through the end of Spring 2023. This order is based on how terms are listed on your site along with the year.

7) Use the available toggle switch to set the desired status of your rule noting that "Active" means that the rule is in use.

Important Note: When creating a new rule, the default status will be set to "Active".

8) For step "1: Conditions", a drop-down menu appears from which you can select a "condition type" to configure for your rule. It is required that a rule contain at least one condition.

Condition Types

The "Condition Type" drop-down menu contains the following options:

• Applicant Parameter
  
  • Data Lookup, Single or Multiple Selection, Yes or No, and Text Field are supported at this time. File, number, and date type are not. 
• Applicant Type
  • Internal or External
• Country
  • The drop-down menu that appears is based on a lookup table and will not pull in locations added under the "Other" label under Settings > Locations.  
  • Important Note: This condition type is based on itinerary dates. If these dates are not yet present, then the program location will be used instead.
• Location
  • A location means a specific city within a country.
  • Important Note: This condition type is based on itinerary dates. If these dates are not yet present, then the program location will be used instead.
• Program
• Program Group
• Program Parameter
  • Single or Multiple Selection Type are supported parameter types. 
• Program Type
• Region
  • Important Note: This condition type is based on itinerary dates. If these dates are not yet present, then the program location will be used instead.
• Term
  • Based on term names as they have been created on your site.

See the "Using Location-Based Conditions" section below for more information on using "Country", "Region", and "Location" as condition types.

After an admin selects a condition type, they will be prompted to select more specific criteria from a series of drop-down menus to define their condition on a more granular level. Most condition types will prompt the admin to select an "Operator" and/or "Value".

• The "Operator" serves to specify if the value should be defined as "in" or "not in" the condition.
• The "Value" is reflective of the options you have available on your site for that condition type.  Multiple values can be selected for a condition.

Here are examples of how an admin may configure each condition type with the use of an operator and values:

Applicant Parameter: Applicant Parameter > Major > Not In > Civil Engineering OR Software Engineering

Applicant Type: Applicant Type > Internal

Country: Country > Not In > United States 

Location: Location > In > Florianopolis, Brazil AND Sao Paulo, Brazil AND Manaus, Brazil

Program: Program > In > Study in Brazil OR TDU in  Brazil

Program Group: Program Group > In > Program Group 1 OR Program Group 2

Program Parameter: Program Parameter > Housing Options > Dormitory OR Homestay

Program Type: Program Type > In > Outgoing OR Incoming 

Region: Region > In > South America

Term: Term > Not In > Spring Break OR Winter

Important Note:

• It is possible to use one rule to deploy process elements across multiple program types.
• The order in which conditions are added to a rule do not matter.

9) After one condition type has been configured, click the "+" icon again to add a second row from which to configure another condition type. Click on the trash icon to permanently remove a condition. When ready, click "Next" to proceed to step "2: Process Element Deployment".

Process Elements

This second step of the rules configuration process is focused on selecting the specific process elements that you want deployed out to an application when the conditions from step one are met. It is required that a rule contain at least one process element. This process element search is case insensitive, meaning that uppercase and lowercase letters are treated the same.

10) Click the "+" icon to view a list of process element types. These items are arranged alphabetically by default:

• Assessment
• Learning Content
• Material 
• Questionnaire
• Recommendation Form
• Signature Document

Important Note: Before deploying a recommendation form with a rule, it's important to understand how this unique feature is managed by the system.

• "Questionnaires" and "Recommendation Forms" are treated as separate process elements. Questionnaires are viewed by applicants. Recommendation forms (referred to as "recommendation questionnaires" at times in the software) are only viewed by recommenders.
• Recommendation forms are deployed by a rule. Recommendations are not. Recommendations are based on the program-level settings configured on the "Application Lifecycle" page in Program Wizard. When this setting is enabled, every application for the program will display a recommendation based on the type(s) selected as a requirement.
• The recommendation type configured for use by a program must match the recommendation type configured for a recommendation form when using Deployment Rules. For example, I have a rule configured to deploy a recommendation form for the recommendation type of "general" to outgoing programs in Mexico City. However, my outgoing programs in Mexico City are only configured to require a recommendation for the recommendation type of "language". Therefore, I cannot deploy the "general" type recommendation form to an application for this program. 
• When a recommendation type has been enabled for a program, then a deployment rule must also be configured so that the desired recommendation form is deployed to a recommender when an applicant for the program submits a recommendation request. Otherwise, a recommender will see a message of "No recommendation questionnaire exists" when they attempt to access the recommendation.

• When an applicant parameter is used as the condition for a rule which deploys a recommendation form, the system logic is saying: when the applicant parameter of X is true for the applicant, then X recommendation form should be deployed to that applicant's recommender. When the recommender views the recommendation request, then they will see X recommendation form. Admins should be sure to create a rule to accommodate for conditions where the applicant parameter is not X to ensure that these applicants' recommenders are assigned a recommendation form. Otherwise, they will see the "No recommendation questionnaires exist" message.
• A deployment rule can be used to support recommendations that may require the use (and deployment of) more than one recommendation form depending on the type of recommendation and your specific recommendation settings. For example, the program "Study in Japan" requires one advisor recommendation. In Content Management, I've created two recommendation forms that are both configured for the recommendation type "advisor". When I create my deployment rule and assign process elements, I need to make sure that I assign both of my advising recommendation forms to ensure that they are both deployed as part of the required recommendation type. 

11) Select a process element type. This will prompt a drop-down menu to appear from which you can select all applicable requirements that you wish to include in this rule.

Example: An admin selects "Learning Content". This prompts a drop-down menu to appear from which the admin selects three specific "Learning Content" requirements: Travel Safety LC, Health Insurance LC, and Department of State LC. When the conditions of this rule are met, then all three of these Learning Content requirements will be deployed to the application.

12) Click the "+" icon again to select a different process element type. This action will prompt a drop-down menu to appear from which you can once again select all applicable requirements that you wish to include in this rule. Continue this step until you've configured all of your desired process elements. Click on the trash icon if needed to permanently remove a deployment action. 

Important Note: An admin can add as many process elements to a rule as needed.

13) When ready, click "Save & Close" to preserve your changes. 

The new rule will automatically appear in the main Deployment Rules listing which is organized alphabetically by default.

An admin is able to expand a rule to view the configuration of conditions and the process elements which have been assigned to deploy when these conditions are met.

From the main Deployment Rules landing page, you can view programs that have been affected by each specific rule. 

 

 

Auto-Generating Deployment Rules

The "Generate Rules" feature is a utility within the Deployment Rules interface that automatically converts process elements that exist on your site into rules that are based on your current process maps.

Important Note: The "Generate Rules" link will be hidden on a site after ten rules have been manually created.

The auto-rule generator will select all of the process maps on your site where the process map year for app cycles is in the previous year through all current and future years. For admins generating rules in 2020, this means that the auto-generator is going to select process maps for 2019 going forward.

Important Note: A process element needs to be active in at least one process map and not be retired to be included in rules that are auto-generated.

Auto-generated rules offer a snapshot of how your current process elements are being deployed on your site and are not expected to define what your optimized rule structure must be. It is not necessary that your office use the auto-generate feature. Admins have the ability to view these auto-generated rules, find patterns, and discover how multiple, similar rules could be combined into fewer rules that contain more conditions and deploy multiple process elements. For example, you would not need separate rules to deploy the same questionnaire to separate program types. A rule allows for process elements to be deployed across multiple program types, so one rule can be used to manage a questionnaire - instead of needing separate versions of a rule for Outgoing, Incoming, Risk Management, and other program types.

To auto-generate rules on your site:

1)  Navigate to Admin Console > Deployment Rules. Click on the "Generate Rules" link located on the top right of the page.

This will prompt the display of the following message: This will generate deployment rules based on the configuration of your currently used process elements.

2) Click "Generate". A success message will pop-up before your rules will appear.

Each auto-generated rule will include an "Auto" label in their title to easily distinguish them from rules that you create independently.

Example: AUTO 001: Scholarship Application Process 

After rules are auto-generated, they will appear in a randomized order on your main Deployment Rules listing.

 

Important Note: It is possible to delete auto-generated rules by clicking the link "Delete Generated Rules". This action will only delete any unedited auto-generated rules from your site. If an auto-generated rule has been edited in any way, then it will no longer be considered "auto-generated". 

 

 

Scheduled Task for Updating Applications

A background process runs, on average, every five minutes in Terra Dotta that uses the scheduled "Application Requirements" task to determine if a change has occurred that necessitates that a pre-existing program application be updated against the changes that have been made to a rule, a program, or applicant parameter values. This action specifically triggers the system to update applications in the active app cycles for those programs impacted by changes based on the following criteria: 

• Change in a Rule
  • Any modification to a rule, such as the addition of a process element, the removal of a process element, re-saving a rule, or adjusting the rule's toggle setting to change to/from "active" status.
• Change in an Applicant's Applicant Parameter Values
  • Any modification to applicant information, such as SIS data.
  • The use of the "Refresh Rule Requirements" feature to make an individual, real-time update to an application in Application Admin Manager.  
• Change in Program
  • Any modification to a program, such as a change in program group, program type, or program parameter values.

When the task detects a change to a rule, program, or applicant parameter, then it will need to cycle through all the applicable applications to make updates. Depending on the number of applications impacted, this might take a few minutes or longer to perform. If the task attempts to run again while applications are still being updated, then it will wait until this update process has been completed before running again. Therefore, due to the nature of how Deployment Rules operates, updates will not be immediate.

Important Note: When the scheduled task runs, it is only looking at program applications in app cycles that have a closing date assigned in the future in App Cycle Management. The system only wants to update applications that are in relevant app cycles, and the presence of a closing date in the future is used for this purpose. If an app cycle's closing date field is blank or populated with a date that is in the past, then the scheduled task will not update applications in that app cycle when it runs.

After this task runs, the system updates the relevant applications which will remove any process elements (e.g. application requirements) that are no longer required if these process elements have not been completed. If the process elements have been started or completed, then they will remain in the application. 

 

 

Process Element Modifications

Process elements are created and edited in their respective builder tabs of Content Management.

Cascade Wizard

After a process element is updated in Content Management, the cascade wizard appears allowing the admin to select the desired app cycles eligible for updating with this new version of the process element.

Important Note: Cascaded changes in the Admin Console only affect rules-based app cycles. 

If the cascade wizard does not appear, check your app cycles in App Cycle Management. You have to have at least one app cycle that is both using deployment rules and set to "active" status in order for the cascade wizard to appear. When these two conditions are met, then the next time you make a change to a process element in Content Management, click "Update". This will trigger a window that says "App Cycles Eligible for Cascade" to appear where you will be able to select or de-select from any rules-based app cycles in "active" status.

 

After a new, second version of a process element is created, the system will  update applications as follows:

For Pre-existing Applications:

• The changes will be immediately applied to active applications in app cycles to which the changes were cascaded if the process element has not yet been started (i.e. assessments and questionnaires) or completed. This means that if a questionnaire has not been completed but contains saved question item responses, then the questionnaire version will not be updated.
• If the process element was already started or completed, then the changes will not be applied. For example, if an applicant had already submitted a questionnaire, then the questionnaire would need to be erased and the application would need to be refreshed in order for the application to display the updated version of the questionnaire. 

For Future Applications:

• Applications created in those app cycles to which the changes were cascaded will contain the most current version of the process element.

 

 

Making Changes to Deployment Rules

Modifying Deployment Rules should be done with care. While this feature eliminates the need for complex process maps, it does require that an admin have a thorough understanding of how a rule modification will impact application data before moving forward with a change.

It is much easier to modify what a rule deploys as part of step 2: "Process Element Deployment" than to modify the conditions (as part of step "1: Conditions") of a rule.

Adding a Process Element to an Existing Rule

Example: An admin adds a new signature document to a rule. When the scheduled task runs, the system will determine that a change to a rule has occurred. The system will then find all applications in the active app cycles for programs meeting the conditions in step one of this rule and update these applications with the new signature document.

Changing a Condition of an Existing Rule

Important Note: It is best practice to not change (e.g. remove or add) the condition of an existing rule because doing so may lead to an application having a process element assigned to it that was not intended.

Example: A rule is created on August 1 with a condition type of "Program" that includes Program A and Program B. When the conditions of this rule are met, it deploys one "Confirmation of Understanding" signature document. Fifty applicants apply to programs in both Program A and Program B. All fifty applications include the "Confirmation of Understanding" signature document.

As the admin, you decided on August 30 to edit this rule's condition type of "Program" to remove Program B. When the scheduled task is run, the system detects that this rule has changed and checks all programs that this rule now impacts and updates the relevant applications.

With this scenario, only program applications for Program A are updated when the task for a change in rule is run. The applications for programs in Program B that were created prior to the August 30th edit to the rule were not detected by the system as being programs to which the rule (with its new changes) now impacts. Therefore, those applications will still contain the "Confirmation of Understanding" signature document until an action occurs that triggers an update to these applications when the next scheduled task occurs.

 

 

Refreshing Rules within an Application: 

If an admin wants to ensure that all active applications for programs in Program B do not contain this signature document, then the following options exist to refresh the application's rules

1. If timing is critical, then the admin can navigate to Application Finder, select the desired applications, and use the "Refresh Requirements" batch action. This option flags the selected applications as needing to be updated. The action does not immediately refresh all of the applications. The refresh action will occur when one of the following actions subsequently takes place (whichever happens first): an admin views the application in full from Application Admin Manager, the applicant views the application from their application page, or the Application Requirements task runs: 
   
2. The admin can use the "Refresh Rules Requirements" feature to make an individual update to an application. This feature is located under the "More Application Actions" menu, also known as the Kebab menu in the Application Admin Manager:
3. The admin can manually trigger a "Change in a Program" which impacts programs in Program B by toggling the status setting of the respective program from and back to "Active". The scheduled task, which runs every five minutes, will update all program applications impacted by this change to remove the signature document. If the signature document has already been completed by the applicant, then it will remain on the application. 

Important Note: The system does not store version information for a rule. This means that it is not possible to track what has been removed from a rule. Admins should keep this in mind when establishing office policies on managing rules.

 

 

Using Location-Based Conditions

Location-based conditions refer to the use of "Country", "Region", or "Location" as a condition type in a rule. When a location-based condition is assigned to a rule and an application is created, the system looks at the application itinerary records first. If those are not present, then the system looks at program locations. This allows you to use location-based conditions with program types, such as Travel Registration and Risk Management, that do not have program itineraries to deploy requirements when applications are created.

If you must make updates to a rule using location-based conditions mid-app cycle, note that the task will run and look at all of the programs impacted by the change to a rule. If the program itself does not fit all of the conditions of the rule, then the update will not include that program's existing applications. Because Travel Registration and Risk Management programs don't have program itineraries, making updates with these program types will require that you follow these step to ensure that existing applications are updated:

• Make the desired updates to your rule and save your changes.
• Navigate to Application Finder and select the applications which need to be updated. Then perform the "Refresh Requirements" batch action.

 

 

Application Organization

From the Application Organization section of the Admin Console, an admin can access a layout tool that allows admins to re-order requirements for rules-based app cycles. This functionality assists administrators in providing the most optimal application experience possible for applicants. 

In order to access the Application Organization feature and make edits, an admin must have the following permission enabled:

• System Settings: Application Layout

Filters

A series of five drop-down menus appear which uniquely filter how application requirements are displayed. These filters are Deployment Method, Program Type, Lifecycle Phase, Program Group, and Program Term.

To get started, you will need to select options for the first three filters moving from left to right with "deployment method" followed by "program type" and then "lifecycle phase":

• Deployment Method: By default, this will be set to "Rules" and should be the method used when ordering requirements for rules-based app cycles.
• Program Type: When a program type of "X" is selected from this menu, the system is looking at two criteria when deciding what requirement(s) to display:
  • Requirements assigned to active deployment rules where a condition of "program type is X" has been configured. 
  • All requirements that are being deployed by active deployment rules in which no condition of "program type" has been specified as these requirements could pertain to this list.
• Lifecycle Phase: When a lifecycle phase of "X" is selected from this menu, the system is looking at requirements assigned to active deployment rules where the field of "Applicable Application Phase" has been populated with "X" phase. 

After options have been selected for these three filters, the system will search for and return results. From the list of requirements displayed, you can continue to add filters as desired using the following options:

• Program Group: When a program group of "X" is selected from this menu, the system is looking at requirements assigned to active deployment rules where a condition of "program group is X" has been configured. 
  • Requirements that are program group-specific will be marked as such.
  • When the "program group" filter is applied, requirements that don't meet this criteria will be removed from the list displayed. 

• Term: When a term of "X" is selected from this menu, the system is looking at requirements assigned to active deployment rules where a condition of "term is X" has been configured.
  • Requirements that are term-specific will be marked as such.
  • When the "term" filter is applied, requirements that don't meet this criteria will be removed from the list displayed. 

Layout

The layout interface is organized first by "Online Requirements" with "Offline Requirements" appearing afterwards. Within each section, three options appear for requirement ordering:

• Priority Requirements: Application requirements that you drag and drop here can be placed in any custom order and will appear to students first.
• Standard Ordering: Application requirements that you drag and drop here will auto organize alphanumerically. 
• Non-Priority Requirements: Application requirements that you drag and drop here can be placed in any custom order and will always appear at the bottom of the page.

These three naming options enable you to customize application requirement ordering without the need for naming schemes. They do not star or label one application requirement as better/more important than another.

A single column of three dots appears next to the left of each application requirement. Click on this icon to open a navigation window for the ability to move this one item to a different ordering option.

A checkbox feature allows for the selection of multiple application requirements at a time to quickly move them in batch from one ordering option to another.

Important Note: When arranging requirements via the Application Organization feature, recommendation types will appear if they have been enabled for use. It's this recommendation type that an applicant will see listed as a requirement on their application page. Recommendation forms will not appear in Application Organization as these items are deployed by a rule and only appear to recommenders after the recommendation request has been sent.

See the "Administrator Features" section of the Application Page KB article for more details on Application Organization.

Due dates can also be assigned on a global level from this interface. For more details, refer to the Dues Dates for Rules-Based Requirements KB article. 

 

 

Rules Management

To assist offices in managing their Deployment Rules, the option to view rules that deploy a specific requirement has been added in various interfaces throughout the Admin Console. These include:

• Application Admin Manager

To see the details of the rules which deploy requirements to a specific application, click on the triple dot "More Application Actions" icon to access the "View Rules" link.

This action opens a listing of all the rules which deploy requirements to the application. From this window, an admin can edit the rule in a new tab or view the full details of a rule.

The full details of a specific rule display all of the information that the admin would normally see from the "Expand" view in Deployment Rules.

• Program Wizard: Application Lifecycle Tab

From "Step 5: Application Lifecycle" in Program Wizard, a "View Rules" icon appears from which an admin can see the details of all the rules that apply to the specific program.

This action opens a listing of all the rules which deploy requirements to the program. From this window, an admin can edit the rule in a new tab or view the full details of a rule.

• Content Management

For any process element in Content Management, a "View Rules" icon appears from which an admin can see the details of all the rules that deploy a specific process element. Note that Reviewer Forms are not deployed by rules and therefore do not display any rules-related icons.

Clicking on the "View Rules" icon opens a listing of all the rules which deploy the process element. From this window, an admin can edit the rule in a new tab or view the full details of a rule.

 

 

Video Instruction

Deployment Rules: Navigating Your Rules Listing

This 10-minute video provides instruction on how to use the various search, action, and filter options available in the Deployment Rules listing.

 

Deployment Rules: Creating a Rule

This 17-minute video provides instruction on how to create a rule using the Deployment Rules feature of the Admin Console.

Deployment Rules: Creating a Rule - Best Practices & Considerations

This 12-minute video provides instruction on some of the best practices and considerations to keep in mind when creating a rule. Topics covered include the configuration logic used with condition types, examples of how you might apply certain condition types, and answer to some frequently asked questions.

 

 

Webinar: Time for a Change: Transforming your Terra Dotta Study Abroad Experience with Deployment Rules