Submit a Ticket My Tickets
Login  Sign up

WORKFLOWS: Creating, Editing & Deleting Workflows

Table of Contents

Creating a New Workflow
Setting Up a New Workflow
Editing the Email Template for Each Workflow Step
Logic Jumps
Custom Workflow Decisions
Editing or Deleting Your Workflow
Updating Workflows for In-Flight Proposals

Example Workflows
Related Articles

Creating a New Workflow


  • Workflows are configurable without any need for IT support, so you may configure these in different ways based on your institution’s needs. If you would like advice on what workflows to set up, speak with your Coursedog Customer Success contact.

  • You can get step-by-step guidance in-app when you’re building a workflow in Academic Scheduling or Curriculum Management. To activate a guided walk-through, navigate to Scheduling or Curriculum > Settings > 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.

  • Otherwise, follow the steps outlined below under “How to Do It”.

How To Do It

PATH: Academic Scheduling > Settings > Workflows


Step One: Click the “+ Approval Workflow” button to open the “Add Approval Workflow” modal.


Step Two: 

  • 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, you might want to call it "Rule exception requests” and input the description as: “This workflow routes rule exception requests from department schedulers to the Registrar’s Office for approval.” 


Step Three: Click the “Add” button to create the new workflow. 

Setting Up a New Workflow


Once your workflow has been created as outlined above, you will see it on the workflow dashboard. Now it’s time to set it up.

How To Do It

PATH: Academic Scheduling > Settings > Workflows


Step 1: 

  • Click the workflow you want to set up (this will open the workflow editor).
  • In this blank workflow, we see that there is an Author, but there are not any other Steps involved with the workflow.


Step 2: To create a step, click “+ Add New Step”.


Step 3:

  • Use the sidebar on the left-hand side of the screen to input the “Step Name”.

  • Example: 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”. 

Step 4: Click “+Participant” to search for participants to add to this workflow step.


Step 5: Search through all users available within the system. 


Step 6: Select the person(s) you would like to add to this workflow step.

Step 7: 

  • Set privileges for each participant at this step. 

  • In other words: determine how each participant will be involved with the approval process. Options include: 


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 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 can 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 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". “Request/Proposal Route Back” works the same way in all Coursedog products; you can learn more about it here.


Participant Can Edit Request

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. 

NOTE: The request author can always edit the request regardless of permission settings.

NOTE: Rule Exception Requests and Schedule Validation requests do not support editing after creation, regardless of user permissions. 


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 Force Approve

If a proposal is “force approved”, it will skip all other steps in the workflow and will entirely approve the request, even if there are other participants that are currently expected to add commentary or vote. The “force approve” option is most often used by curriculum committees when there is only one person that is approving as a proxy for the entire group’s offline voting process.


Participant Is Required to Comment

If set to “Is required to comment”, the participant must leave a comment when responding to the request. If set to “Is not required to comment”, they can act on the request without including a comment.

Step 8: Edit the email templates to define what participants will receive when the workflow is at this step. Learn more here


Step 9: 

  • Input the number of votes required to approve the request before it can be moved along to the next step.

  • For example, if there are two participants but only one vote is required for either approval or rejection, only the actions of one participant (whoever votes first) will be taken into account (i.e. Only one participant would have to approve in order for this to be routed to the next step).

  • You should NOT use any negative values in these fields: if you set “Votes Required for Approval” to “-1” (instead of “1”), that will result in votes for approval being counted as votes for rejection instead.

Step 10: 

  • Select the appropriate option from the “If rejected at this step” dropdown.

  • Options include:


Return the Request 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 Request to Its Author

This means that when the proposal is rejected, it will be sent back to the initial Author.


Reject the Request Entirely

This means 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.


Step 11:

  • Determine whether or not you would like to set a deadline for this step. If not, skip to step 15. If so, check the “This step has a deadline” box to see available options.
  • 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; once the deadline is passed, it will automatically take the action chosen in the next field. 

Step 12 (Optional):

  • 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 request/proposal should be either: 
  1. Approved
  2. Moved to the next step
  3. Returned to the previous step
  4. Returned to its author
  5. Rejected outright
  6. No action 

Step 13 (Optional):

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. Learn more about email notifications here.


Step 14:

  • Define any logic jumps for this step. 

  • Learn more about creating logic jumps here.


Step 15:

  • Specify the default next step.

  • The default next step determines whether the workflow should proceed to another step, or should be approved, once the request is approved at the current step.  

  • This step indicates how to proceed if there aren’t any logic jumps (or there are logic jumps, but no conditions are met).


Step 16 (Optional):

  • Add decisions, if needed.

  • Learn more about decisions here.


Step 17: Click “Save” to save this step.


Step 18: Edit the “Author” step to establish the “Default” first step.


Step 19: Repeat steps 1-17 for any additional steps you’d like to add to this workflow.

Editing the Email Template for Each Workflow Step

Workflow notifications function the same way in all products. Learn more about the “edit email templates” option here.

Logic Jumps

Overview | Workflow Operators | Combining Conditions


  • Each step in a workflow can have a series of associated logic jumps.

  • You define each logic jump using a field (dropdown menu), requirement/operator (dropdown menu), and a variable field (you input the value). 

  • 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 creating a logic jump using “Author (Request)”, you will need to input the email address of the requester. 

  • 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”).

  • If you are creating several logic jumps within the same step and a given request satisfies multiple of those conditions, the order of the logic jumps will determine routing. In other words, as soon as the first applicable condition is met, the routing defined there will route the request as needed (and any other logic jump defined in the original step would be ignored).

  • Once you have created a logic jump, you will need to click “save” on the logic jump card to preserve it.

Workflow Operators

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

  • IS

  • IS_NOT











Combining Conditions

You can determine how many conditions must be met to fulfill the logic jump by selecting “condition”, “any of”, or “all of”.

Custom Workflow Decisions

Overview | Use Case | Adding Decisions | Managing Decisions
Defining Decisions in the Workflow Step | Using Decisions in Logic Jumps
 | User Decision Configuration


The custom workflow decision allows the user to create workflow step decisions with custom verbiage, icons, and workflow routing.


Use Case

This is useful in cases where an institution 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.


Adding Decisions

PATH: Academic Scheduling > Settings > Workflows > (Select Workflow) > Edit Workflow Step


Step One: Select “+ Add Decision” to open a modal where you can select from existing decisions or create new ones.


Step Two: 

  • Select the decision you would like to add.

  • In the below example, options are either “recommend approval" or "recommend rejection".



Managing Decisions

Creating a New Decision | Editing Decisions | Deleting Decisions

Within "manage decisions", you can create, edit, and delete decisions.



Creating a New Decision

  • When creating a new decision, users can configure the label, icon, icon color, and votes required for [decision].

  • 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".


Editing Decisions

  • To edit the decision, click the pencil icon.
  • To save changes, click "edit".


Deleting Decisions

  • To delete the decision, click the trash can (delete) icon.

  • 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. For example: If you create Decision A and apply it to workflow step 1 but then later delete Decision A, Decision A still exists in workflow step 1.


Defining Decisions in the Workflow Step

After creating 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.


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

Using Decisions in Logic Jumps

  • Users can use decisions in logic jumps by selecting when a decision is.

  • This option allows users to select "approved" or any decisions that have been configured within the step.

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

  • Users are automatically granted decisions permissions.

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

Editing or Deleting Your Workflow

PATH: Academic Scheduling > Settings > Workflows > (Select Workflow) > Edit 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”.

  • “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.

  • If changes are made to the workflow settings, these changes will not retroactively impact any in-progress requests unless you select “Update Workflows for In-Flight Proposals” (details below). By default, every time a request is made, a copy of the workflow at that moment in time 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 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.

  • Workflow-specific emails can also be modified under “Edit Workflow”. Learn more here.


Updating Workflows for In-Flight Proposals

Overview | Enabling the Permission | How To Do It | Example Scenarios


After a workflow is edited, and if permissions allow, you have the ability to push changes in the workflow out to in-flight proposals. This is useful in cases where approvers in a workflow change, and you need to be sure the right approvers are evaluating proposals. 



Enabling the Permission

You won’t see this option unless your “Update Workflows for Inflight Proposals” permission has been set to “ALLOW” by an Admin at the following path: Academic Scheduling > Settings > Roles > (Select Role) > Institution Settings. Learn more about role configuration here


How To Do It

If you are able to see the option in your workflow, follow these steps to update workflows for in-flight proposals. 


Step OneSelect “Update Workflows for In-Flight Proposals” (shown above).


Step Two: Select “Yes” in the modal. 



Additional Notes

  • Once you select “Yes”, all in-flight proposals using that workflow will be updated with the new definition (some exceptions apply; see “Expected Behavior” below). 
  • It can take several minutes for in-flight proposals to be updated.
  • An email will be sent after the process is completed.
  • If there are errors and certain proposals are not reset, those will be flagged in the notification email.

Example Scenarios

Updating workflows for in-flight proposals works in different ways depending on the scenario. Consider an example where a proposal has been submitted, and the workflow is (Author) → (Pre-Step) → (Primary Step) → (Post-Step) → (Approved). In the below example, the proposal is in the Primary Step (shown below as “Step”). 

Workflow Step




Pre-Step is deleted

Workflow changes do not persist to the pre-step, existing voting decisions are not impacted, but changes made to the primary step (besides destructive primary step changes, such as deletion) or after occur.


Logic jump is edited so that it doesn’t route to the primary step but rather an alternative step

Workflow changes do not persist to the pre-step, existing voting decisions are not impacted, but changes made to the primary step (besides destructive primary step changes, such as deletion) or after occur.


User removes users, committees, permissions

Workflow changes do not persist to the pre-step, existing voting decisions are not impacted, but changes made to the primary step (besides destructive primary step changes, such as deletion) or after occur.

Primary Step

Changing custom decisions in the step

Workflow changes persist

Primary Step

Modifying users

Workflow changes persist

Primary Step

Modifying voting requirements

Workflow changes persist

If a user modifies a workflow such that votes required is met (e.g. votes required set to 2, 1 user voted to approved, then votes required adjusted to 1), then a user will need to re-submit their vote in order to have the proposal progress. This prevents changes to the workflow automatically progressing a proposal from the current step.

Primary Step

Primary step is deleted

Workflow changes do NOT persist, workflow will NOT be updated. Error email notification will be sent flagging each proposal that was not updated (see example email below).


Post-step is deleted

Workflow changes persist


A new step is added prior to post-step

Workflow changes persist 

Example Workflows


You can configure your workflow(s) to meet your institution’s needs, but here are a couple ideas for how they could be used in Academic Scheduling. To zoom in for a better view, you can download the PDF(s) attached at the bottom of this article. 


Section Change Request


Rule Exception Request

Related Articles

Did you find it helpful? Yes No

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