Submit a ticket My Tickets
Login  Sign up

10. Setting up Approval Workflows

10.1 Overview

Workflows allow requests or proposals to be routed to the right person(s) for approval. As an example, in class schedule planning, workflows are commonly used to route requests for off-grid timeblocks and potential errors or rule exceptions to the Registrar’s Office for approval. 

10.2 Workflow Example

Below, a department scheduler submits an example rule exception request, which will be routed through a workflow: 


A screenshot of a social media post

Description automatically generated

Through a workflow, this request is then routed to the appropriate person, who can see it inside of their requests dashboard. 


And then the workflow approver (Registrar in this case) makes an approval: 


This is just an example. These workflows are configurable without any need for IT support, so you may configure these in different ways based on your institutional needs. If you would like advice on what workflows to set up, speak with your Coursedog customer success team.

10.3 Creating a Workflow

To find the workflow dashboard, first, click 'Settings' on the left-hand side of your scheduling dashboard and then click 'Workflows' from the dropdown options. 

To create a new workflow, click the '+ Approval Workflow' button. 


Next, fill out a name and description for your workflow. If, for example, the purpose of your workflow is to route rule exception requests to the Registrar’s Office, we might want to call it "Rule exception requests” with the description “This workflow routes rule exception requests from department schedulers to the Registrar’s Office for approval.” 

Click the “Add” button to create the new workflow. 


On your workflow dashboard, you will see that the new workflow has been saved. 

To open up the workflow, click on the workflow you just saved. 


You are now inside of editing mode for the workflow. 


Before we discuss how to create this workflow, it is first necessary to define some key terms. 

A workflow contains 'Steps,' which define the rules by which a set of people can make an approval, and what happens when they make or reject the request. 

The 'Author' of a workflow is the initial person(s) that initiate a request which can be routed to the first step in the workflow. 

In this blank workflow, we see that there is an 'Author,' but there are not any other 'Steps' involved with the workflow. To create a step, click '+ Add New Step.'


On the left-hand side of the screen, a sidebar will pop up that will allow you to enter the information required to create a workflow step. 

The first field to fill out is the 'Step Name.'  If the purpose of the workflow is to route a curriculum proposal or scheduling exception request to the Registrar’s Office for approval, an example of a step name might be “Registrar’s Office Approval”. 


The next field to fill out is participants. Participants refer to the person(s) that will be involved in the proposal and how they will be involved in the approval. Click the '+ Participant' button to get started. 


This will then trigger the ability to search through all users available within the system. Select the person(s) you would like to add to this approval. 

Once you add participant(s) into the step, you can decide how those folks will actually be involved with the approval process. There are different options for privileges you can give participants in the approval process. For each participant, you can modify the following privileges:

  • Participant can vote on request: This means that when the participant views the request, they have voting power to decide whether to approve or reject the proposal. They may not be the only person that needs to approve or reject the proposal for it to be moved along to the next step, but this determines whether or not they are allowed a 'vote'

  • Participant can edit requests: This means that the person can directly make an edit to the request and its contents. For example, they might have the ability to catch an error in spelling and change it without asking the initial proposer for permission to make that change

  • Participant can comment on request: This means that the person can add some commentary to the request. For example, they might want more information about something and ask the proposer for more details

  • Participant can suspend: Workflow permissions allow for specifying if a user is allowed to "suspend" a request. Default is set to "on." If set to "off", user will not see the following button while voting on a request: 

  • Participant can edit workflow: This means that the participant can actually edit where the request will be routed to next, as opposed to the standard routing as defined in the workflow

  • Participant can send back (Request Route Back): There is a permission for workflow participants that indicates that they are allowed to "Route back" a proposal to an existing step. The default for this permission is "off". For more information, see '10.8 Request Route Back' in this article

  • Participant can force approve: This most often is used in curriculum committees when there is only one person that is approving as a proxy for the entire group’s offline voting process. A force approve just means that it will entirely approve the request, regardless if there are other participants that are currently expected to add commentary or vote


The next field allows you to make a decision about whether or not to make your step required. 

The participants stated above will receive an email when our workflow arrives at this step. Edit the email template to add more details for the receiver. For example, a best practice is to include the deadline to make this decision in the email template to make sure an action is taken promptly. 

When creating a custom email template for a workflow step, you can specify both an Approver and a Viewer email

  • The Approver email will be sent to all workflow participants where Can Vote = true
  • The Viewer email will be sent to all workflow participants where Can Vote = false
  • If no Viewer email template is set, then the system will default to sending out the Approver email to all participants.

Note that you may also modify the email template that is associated with the 'Author' and 'Approved' steps (the first and last steps of any workflow, respectively). Both of these emails are always sent to the author of the request. The author email is intended for when a workflow is sent back to the author (this is NOT the request created email), and the approval email is when the request is approved. To learn more about settings defaults for email templates at various steps, see section '10.6 Request Email Defaults' at the bottom of this article.

The next field determines the number of votes needed to approve the request in order for it to be sent along to the next step. For example, if there are two participants but only 1 vote is required for either approval or rejection, only the actions of one participant (whoever votes first) will be taken into account (e.g. only one participant would have to approve in order for this to be routed to the next step). 

The next field is to determine what happens if a proposal is rejected at a step. There are three options here:

  • 'Return the proposal to the previous step:' This would send the proposal back to the participants that were associated with the step before the current one, when the proposal is rejected
  • 'Return the proposal to its author' means that when the proposal is rejected it will be sent back to the initial Author (the first person that actually made the request)
  • 'Return the proposal entirely' would mean that the proposal would be rejected and that rejection would be final

At this point, many folks would send out an email notification to the correct people to inform them that the proposal was rejected. To read about how to set up email notifications, go to the workflow email help docs. 

The next field allows you to select whether the step has a deadline. This is often used to determine what should happen to a request or a proposal when someone has not taken action upon it after an extended period of time. For example, someone in the Registrar’s office may need to make an approval of a scheduling request prior to registration. If they are out sick for a few months, it might be worthwhile to set a deadline here so that there is a backup plan in case someone does not do what they are supposed to. This feature is not for reminder emails and once the deadline is passed it will automatically take the action chosen in the next field. 

Click the 'This step has a deadline' field to open up the available options. 

You will see options to determine how long the deadline should be. You can select the number of days or months or years after which the proposal should be either: 

  • Accepted

  • Moved to the next step

  • Returned to the last step

  • Returned to its author

  • Rejected outright

If you've identified a deadline for a step, best practice is to edit the Email Template for this step letting the Voter know they have a deadline of X days/months/years. 


The last field that you can configure is 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.


The following fields can be used to define the logic jumps:

  • Department (Course)
    • Department ID
  • Author (Request)
    • Email address of requester
  • Course Code (Course)
    • Course Code field on the course
  • Section Type (Section)
    • Section Type field
  • Campus (Course)
    • Campus field on the course
  • Program Name (Program)
    • Program Name field

When creating a logic jump using the Department, the department ID must be used rather than the department name. The Department ID can be found by going to Reports > Export > and downloading the Departments List report.

When you add a workflow step, specify the default next step. This step indicates how to proceed if none of the conditions are met. To add a condition, click the 'Add Logic Jump' button.


Here, you can build conditions by specifying specific fields that are part of the request. In this example, if the course code contains "BIO," then the request will go straight to Step 2, and otherwise it will continue on to Step 1.

The full list of workflow operators, which can support number/date/text fields, is as follows: 

  • IS
  • IS_NOT

Note: YES/NO fields are stored as 'true' or 'false'. In order to filter by this field, structure the condition as follows ('Field' + Is + 'true'/'false')


You may also logically combine conditions by selecting 'Any Of' or 'All Of' from the first dropdown. In this example, if both the course code contains "BIO" and the course is on the main campus, then the request will proceed to Step 2.

Finally, you must determine the 'Default Next Step.' The default next step determines whether the step should be sent to another step, or should be approved, once the request is approved at the current step.  


Scroll down to the bottom and click the save button to lock in the step. 

Last, to make a working workflow, we need to determine where the authors 'Default Step' should be sent. Click the 'Edit Step' button on the Author.


10.4 Visualizing your Workflow

If you would like to visualize your workflow, you can click the 'Graph' button. This will allow you to visualize the full path, from request to approval, through the workflow. 


For workflows with specified logic jumps, the graph provides a text-based overview of all implemented logic jumps. It additionally will alert the user of any circular logic jumps that will result in the request never being approved.

Additionally, 'Workflow History' shows all requests that have occurred in the past for this workflow.

10.5 Editing or Deleting your Workflow

If you ever want to edit the name, description, or exempt roles of the workflow, or delete the workflow, you can do so by clicking 'Edit Workflow' next to “+ Add New Step”. If there is a need to replicate a similar workflow, first try adding a logic jump to see if this step will handle the situation in the existing workflow.

Exempt Role(s) determines which roles will bypass this workflow. For example, If you add Super Admin to this list, if a Super Admin submits a request with this workflow assigned, it will automatically be approved.

Note that every time a request is made, a copy of the workflow is generated for the request. You may view this by going to the request itself and clicking on the steps under the 'Request Toolbox' in the right hand side. If changes are made to the workflow settings later on, these changes will not retroactively impact any in-progress requests.

10.6 Request Email Defaults 

To customize the default email templates for all workflows, navigate to Settings > Notifications in the left navigation.

When a user creates a custom default template for certain notifications, then all new workflows will be automatically populated with defaults.

When a user is editing an email in the Workflow editing, they are able to store each email template to its default value by clicking on 'Restore Defaults.'

10.7 Reset Request Email Templates

When a user edits a request, two potential emails are sent out:

  1. Request Edited
  2. Removed From Workflow

Both of these email templates are available in Notification Settings, where their defaults can be edited:

In the workflow itself, these templates can be edited to be workflow specific. Clicking "Edit Workflow" on the top of the workflow opens a modal with multiple email template options:

In this modal, you can edit the following templates to be workflow specific

  1. Request Created: This is sent to the author when the request is created
  2. Request Edited: This is sent to all request participants when a request is edited
  3. Request Rejected: This is sent to the request author when the request is rejected
  4. Removed From Workflow: This is sent to all participants who are removed from a workflow when a request is edited

Note: The email template on the "Author" step is intended for when a workflow is sent back to the author. This is NOT the request created email:

Note that you may also insert variables into these email notifications - including workflow decision comments. Also see sections 10.8 and 10.9 for guidance on email templates set up in workflow steps.

10.8 Request Route Back

There is a permission for workflow participants that indicates that they are allowed to "Route back" a proposal to an existing step. The default for this permission is "off". 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

Once a request is sent back, this will be reflected in the Request's decisions list, and in the status  of the steps.

In the example below, the request was sent back from Step 1 to the Author step, and as a result, there is an additional Author step in the list of total steps, indicating the the author must now approve again for the workflow to move forward.

In the request email templates, users can specify a custom email template for approvers & viewers if the request is routed back to that step:

10.9 Rejection Step Email Settings

Each workflow step has a "Rejected" email template for when a request is rejected at a future step, and that rejection causes the workflow to route back to a prior step (i.e. not "reject entirely") , that can be customized on a step by step basis.

Additionally, the comments that users made on the request while adding their approvals/rejections can be injected as a dynamic variable.

10.10 Request Email Defaults 

To customize the default email templates for all workflows, navigate to Settings > Notifications in the left navigation.

When a user creates a custom default template for certain notifications, then all new workflows will be automatically populated with defaults.

10.10 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.

Did you find it helpful? Yes No

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