For offices ready to make the transition from using process maps to Deployment Rules, this article provides suggestions on how you might approach that change. Each path forward will vary from office to office due to variables, such as the number of process elements on your site, the number of programs you support, and the conditions which determine when a process element should apply to a program.

Before you get started, read the Admin Console: Deployment Rules article. It discusses the mechanics of the Deployment Rules feature along with important considerations, including classic features not compatible with rules, and requirements (such as the use of the Applicant Experience) which you need to review and understand in order to be successful with using Deployment Rules. 

In addition, reviewing your content and creating rules will be a time-intensive process, and offices should schedule their transition to using Deployment Rules with this in mind.  

This article contains the following steps on transitioning to Deployment Rules:

• Review and Update Process Elements in Content Management
• Create Your Deployment Rules
• Example Template
• Update Your App Cycles

Throughout this article, process elements are used synonymously with the following terms: application requirements, requirements, and content. 

Review and Update Process Elements in Content Management

All process elements on your site will appear in their respective section of Content Management in the Admin Console by default. There is no need to rebuild or import existing process elements into Content Management. You will want to review the content to keep, the content that needs to be updated, and the content that you will no longer need and can retire.

Why would I not need content any more?

In the past with process maps, it was not possible to deploy the same process element across program types. Therefore, offices had to create multiple versions of the same process element. You might have four different "Passport Information" questionnaires, for example, for four different program types for this reason. With Deployment Rules, you can now take one process element and assign as many conditions as needed to deploy it to the desired applications. This includes the ability to assign one process element to multiple program types. It may also be the case that you no longer need to create configurations. For example, if a rule is applicable to all terms, then you won't need to set any configurations for the condition of "Terms".

When you make edits in Content Management to a process element, such as a learning content, you will be presented with the option to cascade, or push out, those changes to desired rules-based app cycles. 

Will these updates impact process-map based app cycles?

Not unless you take action. You would have to navigate to the classic Process > App Cycles menu, locate your desired term/year to edit, click into the desired process element, and click the green "update" arrow next to that process element where it appears under the desired program type and phase to apply the update that was made in Content Management.

Create Your Deployment Rules

If a process element needs to appear on a program application in a rules-based app cycle, then that process element must be assigned for use in an active Deployment Rule. The conditions of that rule must be met in order for the process element to be deployed to appear on the program application. 

Will I need to assign all content in Content Management to a rule?

You will only create rules to deploy questionnaires, learning content, signature documents, materials, assessments, and recommendation forms that need to appear on an application. Note the following: 

• Recommendations are configured by recommendation type as a requirement for a program in Program Wizard. When a recommendation form is added to a rule, that form will appear to the recommender in their Recommender Console for them to complete. The recommendation form will never appear on an application for an applicant to complete. 
• A reviewer form is configured for use with Reviewers Management and is not an item that would ever be assigned in Deployment Rules.

To create Deployment Rules, take each process element and ask what is the most general (and biggest) category into which it fits (i.e. what applies to most or all program applications - these are the process elements that require no or minimal conditions). Then move towards the most specific category (i.e. what are specific to a program group, a program, certain applicants, etc. - these are the process elements that will require more conditions).

Categories from general to more specific might be something such as phase, program type, program group, etc. Categories will serve as the conditions for your rule.

Example:

• General: My "Passport" questionnaire applies to the pre-decision phase, four different program groups, and all program types except for "Advising".
• More Specific: An "Assumption of Risk" signature document might only apply to internal applicants going on programs located outside of the U.S.

When you create a new process element, think through this process as well: what is the biggest category this item might fit into, and what would be any exceptions. Using the "not in" operator is helpful in this case when creating conditions for your rule.

Example:

• You want to deploy a requirement only when the program is outside of Australia. Use the condition of Country is "not in" Australia.
• You want to deploy a requirement to all programs in the Global Programs Group except for one, Study in Canada. Use two conditions:
  • 1 - Program group is Global Programs Group. (and)
  • 2 - Program "not in" Study in Canada. 

Another important question to ask when creating your rules is this: is a process element truly program specific, or can the process element be used somewhere else? Sometimes you might be able to modify a process element in order to alleviate having to create multiple rules with slightly different versions of that process element. For example, you might be able to use program parameters (example: minimum GPA) and mail merge fields (example: program name) in a signature document instead of creating multiples of the same signature document.

Naming Conventions

Finally, consider using a naming convention that works for your office to keep your list of rules organized. Some offices like to include the applicable phase in the rule name while other offices do not. You can currently filter on "phase" and will be able to sort the "Phase" column in an upcoming release, so again, this is a preference that varies among offices.

If categorizing by program type, program group, and/or program, these might be helpful for you to include in the rule name as well. There might be important key words that you can easily search on that you'd want to include. Again, this decision will be unique to each office. 

Clicking into the "Filter Results" icon on the main Deployment Rules landing page will display filters that can be applied, allowing you to easily locate a rule. For example, you can filter on a specific questionnaire and then locate all rules to which that questionnaire has been assigned.

Auto-Generate Option 

Is it required that we use the Auto-Generate Rules feature?

No. This optional tool can be used for auditing your content by viewing a snapshot of how you are currently using process elements on your site. You might auto-generate your rules and then filter by phase, such as "Pre-Decision", to see how many rules appear. For sites that auto-generate a large number of rules, it might be easier to then delete these auto-generated rules and get started building out rules on your own. Questions to ask as you go through this process might be:

• Which program applications need to receive X process element?
• Which process elements do you no longer need and can be retired?

Example Template

To assist in organizing your information as you create Deployment Rules, a recommended best practice is to use a spreadsheet. An example template created and successfully used by a client has been provided (see the attachment at the end of this article).

Note the following suggestions when using the template:

Sheet A: Create a listing of all the possible conditions that could be assigned to a rule (meaning this criteria must be true in order for the assigned process elements to be deployed to a rule). These conditions, as listed in step one of creating a rule under the Admin Console > Deployment Rules, would be:

• Application Phase
• Applicant Parameter
• Applicant Type
• Country
• Location
• Program
• Program Group
• Program Parameter
• Program Type
• Region 
• Term

Sheet B: Use this space to conduct an audit of all of your process elements as they are currently being used in process maps on your site. 

Sheet C: Use this space to track rules as you create them. 

Items that you might want to note along the way are redundancies, items that need follow up, content that can be retired, rules that can be combined, and when you'd want your rule to start.

Update Your App Cycles

Finalize your app cycle configurations in App Cycle Management by entering dates for each date field and enabling Deployment Rules for the app cycle. Remember that if you are using the "Starting App Cycle" field, then you must ensure that your terms are ordered correctly on your site. When beginning the transition to using rules, you might want all rules created to deploy to your current app cycle which will be using Deployment Rules. Thus, you might not use the "Starting App Cycle" option right away.

Once you activate the app cycle, you will officially be using Deployment Rules for that app cycle.

Transition app cycle by app cycle until you have Deployment Rules enabled for all app cycles.

Can I use both process maps and Deployment Rules for the same app cycle?

No, it is not possible for a single app cycle to be configured to use both systems (process maps and rules) at the same time. An app cycle will either use process maps or rules. Once an app cycle has been transitioned to using rules, you will not want to revert that app cycle back to using process maps. The goal is to transition an app cycle to using rules onward.

Can I use process maps for some app cycles on my site and Deployment Rules for others?

Yes, it will often be the case, as you transition from using process maps to rules, that you find yourself with some app cycles on your site using process maps and others using rules. This is okay. You will want to move app cycle by app cycle to fully using Deployment Rules and eliminating the use of process maps on your site. 

A suggested best practice to get to that point is to start using Deployment Rules with future app cycles to ensure that your requirements deploy as expected based on the conditions you have configured within your Deployment Rules.