Coursedog

Submit a Ticket My Tickets
Welcome
Login  Sign up

Building Curriculum Approval Workflows

When a user submits a curriculum proposal, it goes through the designated approval workflow. This article will teach you how to construct approval workflows in the Coursedog curriculum platform. 

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 now ensure it is sent to the correct users (use cases here include changes of department scheduler be reassigned etc). Now, the change would impact the proposal's workflow as the workflow would be dynamically re-evaluated.

Note, if a user utilizes logic jumps and if those logic jumps depend on a condition that has not yet been met to be true (ex if proposal = approved at specific workflow step), then the workflows tab will not display the "correct" route until that condition has been met. 

Accessing Workflows

To access your workflows, select 'Workflows' from the left navigation. From here, you can select an existing workflow to edit, or create a new workflow by selecting '+ Approval Workflow'

Building a Standard Workflow

To learn how to build a standard workflow, see this article.

Department Dynamic Step

If you have configured the departments in your curriculum platform, you can include dynamic steps that automatically send your proposals to the appropriate department for approval. 

 

To use dynamic steps, you must first ensure all of your departments are properly configured.

 

When you have configured the workflow step for each of your departments, head to the desired workflow and select ‘+ Dynamic Step’. Select ‘Department Approvals’ and you will see a new workflow step appear in the dashboard. This new step now acts just as any other workflow step, except you do not need to configure anything within the actual workflow. When a proposal reaches that step in the workflow, it will reference the Workflow Settings from the department the proposal belongs to.

 

Please note that, if your workflow includes a Department Approvals dynamic step and a proposal has various departments (Department A, Department B) listed in the Department Select field, then the proposal will be routed in a sequential (not parallel) manner: Department A must approve the proposal in order for it to progress to Department B for approval and so on.



Impacted Department Step

An `impacted courses and programs` dynamic workflow step  can be added to workflows. Impacted stakeholders defined by departments associated with courses and programs that are impacted. Note that the impacted departments dynamic step can only be used for course and program proposals, and not campus proposals. 

Impacted courses and programs are determined by using:

- **Dependencies data structure** (from the requisite builder) used to determine impacted programs and courses. Note, this only works with the simple and advanced requisites builder, and does not work with free-form requisites

- **Cross Listed Courses -** all other courses in the cross listed course group

The user is able to multi-select if they would like to include the dependency impacted courses/programs and/or the cross listed courses in the workflow step.

In the workflow step, all users associated with the workflow step within the impacted departments are pulled into the step with the same permissions that are defined within the department workflow step tool.

The user setting up the workflow step is able to define if the step is notification only or if departments are required to vote. 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. 

The administrator is able to define email notifications sent within the workflow step.

Any proposals that create an impact and that the user does not currently need to vote on are located in "assigned to me" in the requests dashboard with a `Creates Impact` tag, alerting the user that the proposal impacts a course or program that they are associated with. 


Logic Jumps in Workflows

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. 

 

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. 


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 show below ('is' null / 'is not' null) to achieve the same end result.



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. 


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. 

Deadlines

A deadline by which a proposal decision must be made in the workflow can be enforced by selecting "this step has a deadline." 

 

Selecting this will result in the display of several "Deadline" fields. 

Day, month, and years allow configuration of how long a proposal has in a certain step before a deadline is reached. For example, if the deadline on the step was 25 days, you would input 25 days. 

 

A reminder email can be configured to be sent a certain # of days before the deadline, just input the number of days the reminder should be sent in advance of the deadline.



Users can configure what occurs when the deadline is reached through the "at deadline" select field. 



User Permissions 

Users can be added to the workflow by clicking "type to search for users," then inputting the users that should be added. The following permissions can be controlled using the buttons to the right of the user name:

  • Can Vote

  • Can Comment

  • Can Suspend

  • Can Route Back

  • Can Edit Request

  • Can Edit Workflow 

  • Can Force Approve 

  • Must comment (will require this user to make a workflow comment when submitting a decision) 

Based on the enabled permissions, workflow users will see different action buttons available in the decision toolbox. 



 

Can Edit Request

 

If the user permission is enabled, the participant associated with a workflow will be able to edit the proposal within that workflow step. Note that this only grants the user the ability to edit proposals within the specified workflow step. They will not be able to edit the proposal outside of that workflow step unless they have the "edit requests" role permission.

Route Back Permission 

 

If set to "on", participants associated with a workflow will be able to send a request back to a prior step in the workflow via the following inputs:

  1. User selects "route back action"

  2. User selects step to route back to

  3. User selects action upon return

Editing Workflows


Note that, if you edit a workflow, that will NOT impact in-flight Proposals. When a Proposal is created, the Workflow path is generated at that time based on the Form <> Workflow association. Any edits thereafter to the workflow would not retroactively affect the in-flight Proposal.


Custom Workflow Decisions

Use Case

The custom workflow decision proposal allows the user to create workflow step decisions with custom verbiage, icons, and workflow routing. This is useful in cases where school wants to create options beyond approve or reject, and implement voting options such as "recommend approval", "return to faculty", "recommend rejection", "recommend to committee", etc...

Workflow Step Configuration

Adding Decisions

In the configuration of workflow steps, there is now a section labeled decisions.

Users can add decisions as voting options in the workflow step by clicking "add decision"

Clicking "add decisions" opens a modal where users can select from existing decisions in the decision collection or can create new / manage decisions in "manage decisions." In the below example, we are able to select between "recommend approval" or "recommend rejection."

Managing Decisions

Within "manage decisions," I can modify existing decisions or create new decisions.


When creating a new decision, users can configure label, icon, icon color, and votes required for. As a note, users can configure votes required for [decision] within the workflow step itself, the configuration here in the modal acts only as a default.

To save the new decision, hit "create"

To edit or delete the decision, a user can click the pencil or trash can icon. As a note, if a user deletes a decision, deletion only prevents users from adding the decision to new workflow steps. It does NOT remove decisions already added to workflow steps. Ex) I create decision A and apply it to workflow step 1. I later delete decision A. Decision A still exists in workflow step 1.


Editing Decisions

When clicking the pencil icon, users can then edit the decision. To save changes, click "edit".


Defining Decisions in the Workflow Step

After selecting decisions and hitting "save", the decisions appear as configurable options within the workflow step.

Users can configure votes required for [decision] and if users vote for [decision] at this step.

In if users vote for [decision], users can pick any existing workflow step in the workflow. They can also select pre-defined workflow routing options.

Logic Jumps

Users can use decisions in logic jumps by selecting when decision is. This option allows users to select "approved" or any decisions that have been configured within the step.

NOTE: logic jumps supersede if users vote for [decision]

User Decision Configuration

When a decision is added to the workflow step (by selecting the decision), an icon appears next to each user, which can be used to control whether the user has access to vote on that decision.

In the example below, we can see that the user has access to the "recommend approval", "recommend rejection", and "recommend to committee" permissions. This can be toggled by clicking the icons.

NOTE: Users are automatically granted decisions permissions.

Dynamic Step Custom Decisions 

Custom decisions can be added to dynamic workflow steps (department approvals, impacted).


Note that for dynamic steps, users are prompted to specify a % of votes required for the decision.

Users are able to define a default % of votes required for a decision within the decision editor modal.

In `departments` and `committees` users can be granted a "wildcard" permission that grant all decision permissions (defined in the dynamic workflow step). This is granted by clicking the "@" icon in the committee or department. 


Note that if a user does not have this wildcard permission, they cannot vote using the custom decision in the dynamic workflow step. There must be both a custom decision selected within a workflow step and the user must have the wildcard permission to vote for that custom decision


Proposals

Voting

If a user has a decision permission, when the proposal is in their workflow step, they will be able to vote for those decisions.

Display

The user's decision will display throughout the application, with the decisions icon, icon color, and decision name.

The proposal dashboard will also display the icon and name of decisions, if users voted for the decision at that step

Activity Log

The activity log reflects user votes, and displays the name of the decision the user voted for.



Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.