Configure a Workflow

Although the workflow will be initially set up for you as part of the initial implementation, Admin users can make changes to the workflow as needed. 

• Workflow
• Approval
• Acknowledge
• Notification
• Branch
• Denial

Workflow

• Add Steps
• Remove steps
• Reorder Steps
• Undo/Redo Changes

Workflow contains several different types of steps that you can use to drive the workflow:

Approval

Request for users to provide an approval or denial decision on a proposal. Pauses the workflow at the step until the approval or denial decision is received.

Acknowledge

A request for a user to acknowledge a proposal in progress. An acknowledgement step will not pause the workflow, and if it is the last step in the workflow, the workflow will complete without waiting for a user to provide an acknowledgement. 

Notification

A customized email that may be sent to a user. Notifications are separate from system emails sent on an approval or notification step. 

Branch

Allows for proposals to split into different paths based on conditions within the form. 

Denial

If an an approval step is denied, additional steps may be configured to drive the proposal forward.

To view or make changes to the workflow:

• Navigate to the System Settings from the navigation, as an Admin.
• Under the Workflow Settings menu, select the workflow for the item type you would like to modify. For example, if you'd like to adjust the workflow for the course form, select Course Workflow. 

Add Steps

• From within a workflow, select the type of step you would like to add, and then drag and drop it in the desired location.
• Once placed, a flyout will appear to the right providing additional settings for you to configure the step, based on on the type of step you are adding. 
  • Approval
  • Acknowledge
  • Notification
  • Branch
  • Denial
• Once all settings are in place, click Save. 

Remove Steps

• From within a workflow, select the step you would like to remove.
• Once selected, a flyout will appear to the right. 
• Within the flyout, click on Delete Step.

Reorder Steps

• From within a workflow, select the step you would like to move.
• Drag and drop a workflow step to the desired location.
• Once you release the step, the flyout will appear to the right. You do not need to make any further changes or click Save in order for the reorder to take effect.

In addition to using the drag and drop to reorder steps, you can also copy and paste steps if you have steps you would like to repeat! 

• Select the step you would like to copy, and press Ctrl+C on your keyboard. 
• Click into the workflow, and then press CTRL+V to paste it. 
• Use the flyout to update the copied step and then click Save.

Undo/Redo Actions

• After an action has been taken, you can use the Undo option below the list of steps to undo it.
• If you have used the Undo option by mistake, you can also use the Redo option repeat the undone action.

Approval

Within an Approval step, you will need to define which users will be involved on the step, whether they can edit it, what their options are, and what happens if it is denied.

Click on the approval step in the workflow you with to edit, and the flyout will appear to the right allowing you to  modify the settings for the step. Be sure to click Save after making any changes.

Who will approve at this step?

When a user is needed for a step, there will be a series of options to choose who to bring in. This can be by selecting a specific user, or you can determine based on their role, or a field within the form.

• Person(s) in a role of a group, or the group's hierarchy, on the form
  
  • When selected, a field will need to be identified from your from that indicates which group is being selected. For example, if you want to select a user who is a chair within a department - you would need to indicate the field that is used to select the group, such as 'Department'. 
  • Once the field is selected, the role within that group must be selected. For example, 'Department Chair'.
• Person(s) in a role of any specific group
  
  • This option allows you to select a specific role in a specific group. Rather than choosing the department chair based on the department selected - you can indicate that the step must always to go the 'Art & Art History - Chair'.
• Proposer
  • This option will select the user that submitted the proposal into workflow. The selections on the form will have no impact on who the proposer is.
• A user specified on the form
  • If a User Typeahead gadget is used on the form, it may be used to bring in the specified user. 
• Any specific user
  • This option is used to indicate a specific person, selected from your user list. The form will have no impact on who the user is.

Below the user selection will be two additional options:

• Proposal editable by approver(s) at this step
  • When selected, the users who are selected to be the approvers on this step will have edit access to the proposal. Uncheck this if you want to ensure the users at this step can not edit the proposal.
• Skip this step if role is empty
  • When selected, if either of the options that involve a role are used, and the role is empty within the group - then the step will be skipped. It will reflect as 'Skipped' in the workflow, and continue in the process. If this is not enabled, the proposal will stop at the step and show an Error as no users are found.

Response Options

These options determine what is required in order for the proposal to move on in the workflow.

• A response from one person is sufficient (The first person to respond determines whether the process continues or not)
  • When this is selected, only one person on the step will be required to provide their approval in order for it to move to the next step, regardless of how many users are actually included in the step.
• A percentage of users must approve
  • When selected, a percentage can be required of the users on the step to approve. For example, if you set the total to 50%, and you have three users on the step - two of the three will be required to approve in order for it to be considered approved.
  • An additional option can be used, to require a percentage of responses. This does not require users to all approve, but it ensures all users participate on the step. 

What happens if the proposal is denied?

When a proposal is denied, a proposal can take one of two options:

• Custom Steps
  • When selected, a series of additional steps can be added to the workflow that will only occur if the proposal receives a denial at this step.
• Do Nothing
  • No action occurs

Once these two conditions are evaluated, the proposal can either continue or stop, based on your preferences. 

• Stop Workflow 
  • Most workflows will stop if a proposal is denied. When this occurs, the proposal stops the workflow and is marked as 'denied'. No further action can occur on the proposal, but the user may submit a new one.
• Continue workflow
  • Depending upon your practices, it is possible for a proposal to continue even after receiving a denial. 

Custom Workflow Step Label

Each step in the workflow can have a custom label applied do it. These labels help to identify the steps, both in the workflow and when reviewing them on the proposal. 

For example, the default step name for an approval step is 'Approval' - but if every step were titled as 'Approval' it may be difficult to troubleshoot or identify where in the process it is. 

Adjusting the name is done by simply clicking into the field, adding the new label, and then clicking Save.

Acknowledge

Who will acknowledge this step?

When a user is needed for a step, there will be a series of options to choose who to bring in. This can be by selecting a specific user, or you can determine based on their role, or a field within the form.

• Person(s) in a role of a group, or the group's hierarchy, on the form
  
  • When selected, a field will need to be identified from your from that indicates which group is being selected. For example, if you want to select a user who is a chair within a department - you would need to indicate the field that is used to select the group, such as 'Department'. 
  • Once the field is selected, the role within that group must be selected. For example, 'Department Chair'.
• Person(s) in a role of any specific group
  
  • This option allows you to select a specific role in a specific group. Rather than choosing the department chair based on the department selected - you can indicate that the step must always to go the 'Art & Art History - Chair'.
• Proposer
  • This option will select the user that submitted the proposal into workflow. The selections on the form will have no impact on who the proposer is.
• A user specified on the form
  • If a User Typeahead gadget is used on the form, it may be used to bring in the specified user. 
• Any specific user
  • This option is used to indicate a specific person, selected from your user list. The form will have no impact on who the user is.

Below the user selection will be an additional option:

• Skip this step if role is empty
  • When selected, if either of the options that involve a role are used, and the role is empty within the group - then the step will be skipped. It will reflect as 'Skipped' in the workflow, and continue in the process. If this is not enabled, the proposal will stop at the step and show an Error as no users are found.

Custom Workflow Step Label

Each step in the workflow can have a custom label applied do it. These labels help to identify the steps, both in the workflow and when reviewing them on the proposal. 

For example, the default step name for an approval step is 'Approval' - but if every step were titled as 'Approval' it may be difficult to troubleshoot or identify where in the process it is. 

Adjusting the name is done by simply clicking into the field, adding the new label, and then clicking Save.

Note: An acknowledge step will NOT pause the workflow.

If your workflow is set up so that an acknowledge step is followed by an approval step, the the users on the acknowledge step can continue to provide the acknowledgement until the proposal is approved. 

However, if the acknowledge is at the end of the workflow, then as soon as the preceding approval is completed, the workflow will complete without providing an opportunity for the users on the acknowledge step to provide any feedback.

Notification

Who will receive this notification?

When a user is needed for a step, there will be a series of options to choose who to bring in. This can be by selecting a specific user, or you can determine based on their role, or a field within the form.

• Person(s) in a role of a group, or the group's hierarchy, on the form
  
  • When selected, a field will need to be identified from your from that indicates which group is being selected. For example, if you want to select a user who is a chair within a department - you would need to indicate the field that is used to select the group, such as 'Department'. 
  • Once the field is selected, the role within that group must be selected. For example, 'Department Chair'.
• Person(s) in a role of any specific group
  
  • This option allows you to select a specific role in a specific group. Rather than choosing the department chair based on the department selected - you can indicate that the step must always to go the 'Art & Art History - Chair'.
• Proposer
  • This option will select the user that submitted the proposal into workflow. The selections on the form will have no impact on who the proposer is.
• A user specified on the form
  • If a User Typeahead gadget is used on the form, it may be used to bring in the specified user. 
• Any specific user
  • This option is used to indicate a specific person, selected from your user list. The form will have no impact on who the user is.

Email Contents

You can customize the subject line and body text of the notification. Basic formatting options are available for the body text, including:

• Heading styles
• Bold
• Italics
• Font color

Additionally, data from the form associated with the workflow can be dynamically entered into the body to further customize the notification in the form of a variable. 

The gadgets below can be used from your form to populate the notification, including:

• Groups Multiselect (e.g., department, college)
• Groups Typeahead (e.g., department, college)
• Options Typeahead (e.g., subject code)
• Rich Text (e.g., description)
• Terms Picker (e.g., start or end term)
• Text (e.g., title, description)
• Text Area (e.g., description, proposal rationale)

Custom Workflow Step Label

Each step in the workflow can have a custom label applied do it. These labels help to identify the steps, both in the workflow and when reviewing them on the proposal. 

For example, the default step name for an approval step is 'Approval' - but if every step were titled as 'Approval' it may be difficult to troubleshoot or identify where in the process it is. 

Adjusting the name is done by simply clicking into the field, adding the new label, and then clicking Save.

Branch

A branch allows system administrators to indicate conditions that require a modified or additional route(s) for a proposal to follow to be approved. A branch includes two or more routes that include the steps (e.g., approval, acknowledgment) specific to the affected proposal. Proposals can be routed based on data gathered from form gadgets, for example, such as whether a proposal is requesting that a new program be created or an existing program be modified.

Branches are used to enable a single workflow to accommodate the different governance processes required for a wide variety proposals. Managing these disparate processes in one workflow instead of through multiple workflows reduces the configuration and maintenance overhead for system administrators all while maintaining a high degree of flexibility.

Some common scenarios that could benefit from branching include:

• General education curriculum - additional or adjusted requirements for designating courses as general education applicable
• Level - undergraduate versus graduate-level curriculum
• Modality - online, in person, or blended
• Nontraditional curriculum - study abroad, work study, and internships
• Proposed changes - substantive versus non-substantive changes to existing curriculum
• Specific group processes - specific departments, colleges that have unique processes that diverge greatly from the typical governance process
• Type of proposal - a new versus a modified course or program

Workflow can support as many branches as needed. Best practice, however, is to limit the number of branches so as not to overcomplicate the workflow configuration. Often, one to two branches can more than accommodate an institution's governance process.

After creating a branch, a sub-branch may be added to accommodate scenarios where additional routes are required beyond the initial branching. There is no limit on the number of sub-branches a workflow can include. Best practice, however, is to limit the number of sub-branches so as not to overcomplicate the workflow configuration.

Route Configuration

A route may include a Default Route, as well as specified routes to branch the proposal. As an admin, you can configure the default route a proposal will take when the additional routes do not apply. For example, proposals for courses that are offered online may need to follow a specific route while all other course proposals for on-campus courses can follow the default route.

The following options are available for configuring a default branch:

• This route will run if no match is found below 
  • If the conditions for the provided routes are not met (For example, if this is a route for Graduate courses, and the proposal moving through workflow is for an Undergraduate course), then the steps listed under the default route will apply.
• This route will never run
  • Removes the default route from the branch entirely and will assume that all scenarios fit into the other configured routes. If no condition is met, the steps within the branch will not occur.

When configuring a route, the following gadgets can be  used: 

Activities Checkbox Checkboxes Course Typeahead Dropdown Groups Multiselect

Groups Typeahead Options Multiselect Options Typeahead Proposal Owner Radios User Typeahead

To configure the route:

• Specify the Gadget used on the form
• Select an operator
• Select the value of the field
• If additional conditions are need, click the + icon to add an additional option. 
• If your route contains more than one condition, indicate if the route requires ALL statements to be true, or ANY of the statements.

A route will occur when all conditions within the route have been met. Once the routes have been specified, you can drag steps into the routes to outline their workflows.

Custom Workflow Step Label

Each step in the workflow can have a custom label applied do it. These labels help to identify the steps, both in the workflow and when reviewing them on the proposal. 

For example, the default step name for an approval step is 'Approval' - but if every step were titled as 'Approval' it may be difficult to troubleshoot or identify where in the process it is. 

Adjusting the name is done by simply clicking into the field, adding the new label, and then clicking Save.

Denial

Sometimes a proposal cannot be approved or sent back for changes and needs to be denied from moving further in the workflow. Denying a proposal enables an approver to stop a proposal from moving through the workflow entirely or enable a review process to begin to validate whether the denial should be permanent or if changes are appropriate or possible.

Depending on your institution's configuration, the following may happen when a proposal is denied:

• A notification is sent to the proposer and the proposal is permanently denied and unable to be edited and resubmitted for approval.
• A denial branch is triggered that may involve additional review steps, which may result in the proposal being sent back for changes or permanently denied and unable to be edited or resubmitted for approval.

A denial branch is first configured within an approval step. When creating the approval step, the system administrator determines what should happen once a proposal is denied. If custom steps are to follow a proposal's denial (e.g., a notification or approval step), they are then added separately to the denial branch. See Add Steps for more information.