Table of Contents
Overview
How Proposals Use Workflows
Building a Standard Workflow
Workflow Notifications
Assigning Committees
Dynamic Steps
Logic Jumps in Curriculum Workflows
Dynamic Step Custom Decisions
Integration Sync Settings for GET-Only Integrations
Assigning Workflows to Forms
Example Workflows
Related Articles
Overview
When a user submits a curriculum proposal, it goes through the designated approval workflow.
Workflows function the same way in all products, with a couple exceptions. In Curriculum, those exceptions include the ability to add a committee to a workflow step as well as the ability to add dynamic steps for “department approvals” and “impacted departments”.
You can get step-by-step guidance in-app to help you create a new workflow. To activate a guided walk-through, navigate to Curriculum > Workflows > + Approval Workflow. If the flow doesn’t automatically begin when you click “+ Approval Workflow”, look for it in the “In-App Guides” widget on the right-hand side of your screen.
How Proposals Use Workflows
At each workflow step, the workflow graph is re-evaluated using “Just In Time” functionality. This has several impacts on the proposal workflow:
Each time a field is being modified using the downstream editing functionality, the predicted workflow is updated to reflect the upcoming next steps, assuming users vote "approve" on all the upcoming steps.
If the user changed a field value that would impact any upcoming logic jumps, the workflow will be recalculated from the current workflow step onwards, the proposal would change its path and progress through a different set of workflow steps. For example, when the department scheduler has been changed in the department step after the proposal has been initially submitted, we ensure it is sent to the correct users (use cases here include changes of department scheduler being reassigned etc.). Now, the change would impact the proposal's workflow as the workflow would be dynamically re-evaluated.
If a user utilizes logic jumps and those logic jumps depend on a condition that has not yet been met to be true (e.g. If proposal = approved at specific workflow step), then the workflows tab will not display the "correct" route until that condition has been met.
Building a Standard Workflow
Learn about workflow basics here.
To learn how to build a standard workflow, see this article.
Workflow Notifications
All workflows give you the ability to define default email templates as well as the ability to further customize emails at both the workflow as well as the step level.
Learn more about workflow notifications here.
Assigning Committees
In addition to assigning users to workflow steps, committees can be added as voters in workflow steps. In the edit workflow step screen, click “+ committee” and search to add any committees that have been added in the "Committees" tab. Learn more about setting up committees here.
Dynamic Steps
Overview | Department Approvals vs. Impacted Departments | Sequential vs. Parallel
Using the “Department Approvals” Dynamic Step | Using the “Impacted Departments” Dynamic Step
Overview
There are two types of dynamic steps in Curriculum: Department Approvals and Impacted Departments.
These can be used to notify department stakeholders of changes related to courses and programs that are associated with their department. They cannot be used for campus proposals.
You should only include one of the two dynamic step types rather than both in order to avoid routing to the same users more than once.
In order to add either dynamic step to a workflow, you will need to first configure the “Workflow Step” in the department’s profile. If a department does not have a workflow step configured, the proposal will skip the dynamic step.
The associated department is determined by what is listed for the course or program on its record and not necessarily the department the proposal author is assigned to.
Department Approvals vs. Impacted Departments
Add the “Department Approvals” dynamic step to route proposals past the department(s) directly associated with the proposal. In other words, a proposal for a math class would route to the math department at this step.
Add the “Impacted Departments” dynamic step to route the proposal past the department(s) directly associated with the proposal AND any departments who own classes in a cross-listing and/or dependency. In other words, a proposal for a math class that is also a dependency for a biology class would route past the math department AND the biology department at this step.
Both dynamic steps leverage the participants/committees defined in the “Workflow Step” settings to determine who needs to be notified (or vote on) the proposal.
The “Department Approvals” step will also leverage “Workflow Step” settings to determine votes required for approval/rejection; what happens if the proposal is rejected at this step; and whether or not the step has a deadline.
For the “Impacted Departments” dynamic step, the following options are all defined within the workflow itself (rather than via Department Workflow Settings): Votes required; what happens if the proposal is rejected at this step; and whether or not the step has a deadline.
Sequential vs. Parallel
If a proposal has multiple departments (Department A, Department B) listed in the Department Select field or multiple departments impacted via cross-listing or dependencies, the proposal can route either sequentially or in parallel order.
If sequential, Department A must approve the proposal in order for it to progress to Department B for approval and so on. The order in which they are listed determines the sequential order.
If parallel, the proposal will be sent to all departments for approval at the same time and will not move on to the next step until all departments have taken action.
An admin can define the default behavior for both dynamic step types at Admin > Product Settings.
The behavior can be changed at the workflow step level as well (though for Impacted Departments, the option will only appear if “this step requires voting” is checked).
Using the “Department Approvals” Dynamic Step
Step 1:
Configure the “Workflow Settings” for all departments at Curriculum > Settings > (Select Department) > Workflow step.
Learn how to do that here.
Step 2: Open the workflow you’d like to add the “Department Approvals” step to.
Step 3: Click “+ Add Dynamic Step”.
Step 4: Click “Department Approvals”.
Step 5:
When a proposal reaches that step in the workflow, it will reference all of the Workflow Settings from the department the proposal belongs to.
However, you still have the option to:
Define a Step Name.
Determine whether this step operates sequentially or in parallel.
Add any decisions or logic jumps.
You will need to define the default next step.
You can learn more about basic step configuration here.
Step 6: Click “Save” once you have finished configuring the step.
Using the “Impacted Departments” Dynamic Step
Overview | Impact Types | Example Scenarios | How to Configure This Step | Additional Note
Overview
This dynamic step will still pull participants and committees defined on the Workflow Settings for the department associated with the proposal; however, it will also look at participants for related dependencies and/or cross-listings.
If you would like for any departments impacted by a proposal – whether because of a dependency or a cross-listing – to be notified of a proposal, you should add the “Impacted Departments” dynamic step to the workflow.
If a dependency is referenced on the course or program record, and you use this step and select “impacted dependencies" as the “impact type”, the department who owns that dependency will be involved with voting and taking action.
If a course is cross listed, and a different department owns that cross-listed course, they’ll be involved in reviewing the proposal at this step if you select “Cross Listed Courses” as the impact type.
If your workflow uses the “Impacted Departments” step but there aren’t any departments impacted by the specified impact type(s), the proposal will skip this step entirely. In this scenario, even the department associated with the course proposal will not be notified.
Impact Types
Cross Listed Courses – Defined as all other courses in the cross-listed course group.
Impacted Dependencies – Dependencies are defined in the requirements builder. Note this option only works with the simple requirements builder and does not work with free-form requirements.
Example Scenarios
If ANT105 is a prerequisite for ACC199 and an edit request is submitted for ACC199, the Anthropology department will not be impacted.
If ANT105 is a prerequisite for ACC199 and an edit request is submitted for ANT105, the Accounting department will be impacted.
If a Program is associated with the History department and has several courses listed within its requirements that are associated with the Art department, an “Edit Program” request for this program will NOT impact the Art department.
How to Configure This Step
Step 1:
Configure the “Workflow Settings” for all departments at Curriculum > Settings > (Select Department) > Workflow step.
Learn how to do that here.
Step 2: Open the workflow you’d like to add the “Impacted Departments” step to.
Step 3: Click “+ Add Dynamic Step”.
Step 4:
Click “Impacted Departments”.
When a proposal reaches that step in the workflow, it will determine workflow participants – and their permissions – based on the Workflow Settings for the department that is listed in the course or program record for the proposal as well as all Workflow Settings for the impacted department(s).
Step 5:
You will be required to select the “Impact Type” from the drop down.
This is a multi-select field, so if you wish to include both impact types, you may do so.
Step 6:
Check the “This step requires voting” box if you want this step to require a vote (rather than serve as a notification only).
If checked, you will see several additional options appear: “Dynamic Steps Operate Sequentially or in Parallel”; “% of Departments Required for Approval” (Required); and “% of Departments Required for Rejection” (Required).
Each department represents a "vote" within the step, and the user can define the “% of departments required for approval” and “% of departments required for rejection”. For instance, if the user sets 51% of departments required for approval and there are 3 departments with 5 users each, 2/3 departments would need to vote for the proposal for it to be approved.
Step 7:
Fill out the rest of the step information just as you would any other workflow step.
You will have the option to:
Define a Step Name.
Edit the associated emails.
Determine what happens if the proposal is rejected at this step.
Determine whether or not this step has a deadline.
Add any decisions or logic jumps.
You can learn more about basic step configuration here.
You will need to define the default next step.
Step 8: Click “Save” once you have finished configuring the step.
Additional Note
If a proposal creates an impact for a department the user is associated with but the user does not need to vote on it, they will see the proposal listed under “assigned to me" in the requests dashboard with a “Creates Impact” tag.
Logic Jumps in Curriculum Workflows
Overview | Using Field Groups | Conditions | Using Custom Fields in Logic Jumps
Overview
Within workflows, you can create logic jumps. Each step in a workflow can have a series of associated logic jumps. These are conditions that can be used to dynamically change the path of a request.
Using Field Groups
When creating a dynamic step, you can select from different "field groups" to base the form logic on. Field groups allow you to select specific fields from the course or program template, or specific forms. In general, we advise that you use the course or program field group wherever possible, as this will allow your workflow to function across all of your forms. If you select a field group from a specific form, that logic jump will only be evaluated for that form. Values are stored as a "description" for all fields besides "Department Select" and "Program Select," in which "ID" values are stored.
Conditions
The “Has At Least” condition is used for creating workflow conditions based on file inputs. This allows users to say "if user has inputted at least one file in this field, go to a different workflow step".
Curriculum workflow logic jumps don't have an “Is Empty”/”Is Not Empty” operator for certain fields like the pre-built Cross-Listed Courses field. However, you can instead configure this logic jump using the "is" and "is not" operators (i.e. Cross-Listed Courses...Is...null OR Cross-Listed Courses...Is Not...null). Set it up as shown below (“is” null / “is not” null) to achieve the same end result.
Using Custom Fields in Logic Jumps
Overview
Custom fields are not part of the static list of options for a logic jump when choosing from template field groups (such as Course or Program), but they are still accessible in logic jumps via other field groups.
How to Do It
If you would like to use a custom field for a logic jump:
Under “Field Group”, select the specific name of the form that is both associated with this workflow and is the form that uses the custom field.
When you have selected the specific form under Field Group, the custom fields will be available as options under “Field”, and you can use them for logic jumps.
Additional Note
If you are associating multiple forms with a single workflow and the custom field is used on each of those separate forms, you will need to create a separate logic jump for each form. For example, if you want to create a logic jump based on “Custom Field 1” and that field is on two forms, “Form A” and “Form B”, that are both associated with the workflow, you will need to create two logic jumps. You will create one logic jump where Field Group is “Form A” and then Field is “Custom Field 1” and another logic jump where Field Group is “Form B” and then Field is “Custom Field 1”.
Dynamic Step Custom Decisions
You can learn more about custom decisions here.
Integration Sync Settings for GET-Only Integrations
Overview
If your Curriculum integration is GET-only – in other words, if you aren’t posting anything back to your SIS – you can use “Integration Sync Settings” to ensure data is in sync between Coursedog and the SIS before a proposal is approved.
This feature displays the discrepancies between the SIS and Coursedog data, allowing users to identify which fields are out of sync before approving a proposal.
It can prevent a proposal from advancing through the workflow until the data in the SIS and Coursedog match, thereby preventing data inconsistency issues.
This setting is configured within individual workflow steps.
How It Works
When Building a Workflow
Overview
When constructing a workflow step in Curriculum, users at GET-only schools will encounter two settings: Show Integration Sync Status and Require Integration Sync for Approval.
Show Integration Sync Status
If checked, approvers at this workflow step will be able to identify fields in the proposal that don't match current SIS data
It helps admins discern synchronized and unsynchronized data, with customization available for each workflow step.
Not all workflow participants will need this information, like a faculty member who doesn't require SIS data.
The option stands alone; in other words, you don’t need to also check “Require Integration Sync For Approval” for it to work.
Require Integration Sync For Approval
If checked, this setting will necessitate field synchronization between the SIS and Coursedog before approval.
Selecting this setting automatically activates and locks the "Show Integration Sync Status".
When Viewing a Proposal
If the “Show Integration Sync Status” and “Require Integration Sync For Approval” settings are on, the user’s view of a proposal will be different in the following ways:
Each out-of-sync integrated field in the proposal will have an “inline” SIS sync status yellow radio circle next to it.
On the Curriculum Proposal page, there will be a fourth tab called “SIS Data Comparison”. This tab will show all the out of sync fields from the proposal, and display a side-by-side of their values in Coursedog and in the SIS.
When a user attempts to make a decision on the proposal (i.e. approve), they will not be able to and will see the following warning message if the SIS data and Coursedog proposal data are NOT in sync.
Assigning Workflows to Forms
To make sure your workflow is linked to the proper form. Head to the form editor and select your workflow in the top right.
Example Workflows
You can configure your workflow(s) to meet your institution’s needs, but here are two possible paths a Curriculum proposal could take. To zoom in for a better view, you can download the PDF(s) attached at the bottom of this article.
