Submit a Ticket My Tickets
Login  Sign up

WORKFLOWS: Creating, Editing, Duplicating & Deleting Workflows

Table of Contents

Creating a New Workflow from Scratch
Setting Up a New Workflow
Editing the Email Template for Each Workflow Step
Logic Jumps
Custom Workflow Decisions
Adding a Post-Approval Workflow Step
Duplicating Workflows
Editing or Deleting Your Workflow
Updating Workflows for In-Flight Proposals
Example Workflows
Related Articles


  • Generally speaking, the process for creating, editing, duplicating, and deleting workflows is the same in all Coursedog products. 

  • There are some product-specific nuances regarding department steps and logic jumps that are covered in different articles, but this article outlines all of the foundational steps. 

  • Once you understand how to build a workflow, you can then reference the following product-specific articles for additional guidance: CurriculumEvents, and Catalog.

Creating a New Workflow from Scratch


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

  • To duplicate an existing workflow, see the “Duplicating Workflows” section. 

  • You can get step-by-step guidance in-app when you’re building a new workflow from scratch 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

Overview | How To Do It | Dynamic Steps


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 add a standard step, click “+ Add New Step”. 

  • To add a “Dynamic Step”, click “+Add Dynamic Step” and then see “Dynamic Steps” below to learn more. 

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 (shown below).

  • You can learn more about what happens when a request is suspended – and potential use cases – here.

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.

  • If you set this to “Can Send Back” for a participant, you will also need to give them the “Can Comment” permission. 

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.

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

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


Participant Can Edit Workflow

  • If someone with this permission edits a request/proposal, they will have the option to select whether to have the proposal: 

    • Continue on its current workflow path or

    • Restart from the beginning of the workflow.

  • If set to “Cannot Edit Workflow”, and a user edits the request/proposal, the proposal will automatically be routed back to the start of 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.


  • In Academic Scheduling and Event Scheduling, the same logic as outlined above still applies. 

  • However, there is an additional “Force Approve” Role-Based Access Control (RBAC) permission that has an impact.  

  • See the below table for a breakdown of how the RBAC and the workflow step-level permissions interact but, in short, if the “Force Approve” permission is set to “Allow” in either location, the user will be able to force approve. 


Workflow Step




Can force approve



Can force approve



Cannot force approve



Can force approve



Can force approve



Cannot force approve


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.

Dynamic Steps

Overview | Sequential vs. Parallel | Academic Scheduling | Curriculum Management
Event Scheduling | Online Catalogs


  • Most Coursedog products include the ability to add dynamic steps. 

  • Dynamic steps allow you to dynamically route a proposal past those who are directly impacted by that specific proposal without needing to create a complicated series of logic jumps. 

  • The exact use case varies by product, but before adding a dynamic step to a workflow, you will need to make sure you have configured relevant workflow settings. In Academic Scheduling, for example, that means configuring the workflow settings for all departments

Sequential vs. Parallel

  • Dynamic Steps can operate either sequentially or in parallel if a proposal has multiple departments (e.g. Department A and Department B).

  • 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 at Admin > Product Settings.

  • The behavior can be changed at the workflow step level as well.

Academic Scheduling

  • Used for Department Approvals.

  • When a workflow includes a dynamic “Department Approvals” step and the request reaches that step, the workflow will reference all of the Workflow Settings from the department the section belongs to. In other words, if the section falls under the Math department, the “Department Approvals” dynamic step will route the proposal past the workflow participants configured at Scheduling > Settings > Departments > (Open Department) > Workflow Step. 

  • Learn more here.

Curriculum Management

Event Scheduling

Online Catalogs

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
User Decision Configuration | Using Decisions in Logic Jumps


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: Workflows > (Select Workflow) > Edit Workflow Step

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

Step 2

  • Select the decision(s) you would like to add by checking the adjacent box.

  • In the below example, options are either “recommend approval" or "recommend rejection". However, the decisions that appear in your UI will vary depending on what your institution has created.

Step 3: 

  • Once you’ve added a custom decision, you will need to click into it in order to configure its settings. 

  • You will not be able to save the workflow step until the decision has been configured. 

  • For all step types (standard and dynamic), you will need to indicate what will happen next if users vote for this decision at this step. 

  • You will need to configure one additional setting, which varies between standard and dynamic steps. 

    • For standard steps, you will need to indicate the number of votes required for this custom decision. 

    • For dynamic steps, you will instead need to indicate the % of votes required for this decision.

If Users Vote

You can pick any existing workflow step or predefined workflow routing option.

Standard Step

Dynamic Step


Managing Decisions

Overview | Creating a New Decision | Editing Decisions | Deleting Decisions


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

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


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.

User Decision Configuration

Within the Workflow

  • 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 or not the user has access to that custom 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" custom decisions.

  • You can give or remove those permissions from the participant by clicking the icons.

In Committee and Department Workflow Step Settings

  • When adding members to a Committee or Department, you will see the usual workflow participant settings along with an @ symbol that indicates whether the user “Can Make Custom Decisions” or “Cannot Make Custom Decisions”. 

  • If set to “Can”, this user will be able to vote using custom decisions.

  • If set to “Cannot”, this user will not see any custom decisions when voting. 

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


Adding a Post-Approval Workflow Step


  • You have the option to “+ Add Post-Approval Workflow Step” at the end of each workflow.

  • This step is automatically triggered after the request has been approved.

  • Post-approval workflow steps are notification steps that help facilitate otherwise manual processes. 

How It Works

  • Post-approval workflow steps activate immediately after approval. 

  • You can use multiple post-approval workflow steps. 

  • Post-approval steps will never initiate a merge/POST back

  • When routing back to prior steps, post-approval workflow steps cannot route back to pre-approval. 

  • If a workflow is updated to add or edit post-approval workflow steps, and “workflow is updated for inflight proposals” is selected, previously approved proposals will not be re-added to workflow. The update will apply only to net-new proposals, or to proposals which have not yet been approved. 

  • Reporting is available on post-approval workflow steps. 

  • Logic jumps are available within and between post-approval workflow steps; the default next step is “none,” which ends the workflow. 

How To Do It

Step 1

  • For Scheduling and Events, navigate to Product > Settings > Workflows > (Select Workflow You Wish to Edit).

  • For Curriculum and Catalog, navigate to Product > Workflows > (Select Workflow You Wish to Edit).

Step 2: Locate the “Approved” Step; the “+ Add Post-Approval Step” button will be nearby.

Step 3: Click “+ Add Post-Approval Step”. 

Step 4: Define the post-approval workflow step. 

Use Cases

Uses for Post-Approval Workflow are many and varied:

SIS Updates 

  • Once a new course is approved, create two rows in the SIS (e.g. Peoplesoft). The first row is created by the POST/approval; the second row is manually created. 

  • Colleague Ethos: Course edit POSTs create a new course instead of a revision. Once a course edit is approved, you need to manually update equivalencies on the “2” courses. 

  • Not all fields are supported on POSTs. Once a request is approved, this step gives you the ability to track when items are added manually to the record.

Notifying Other Teams on Campus 

  • Post-programmatic change, notify marketing and admissions departments automatically.

  • Once an event is created, someone needs to manually create an IT help desk ticket. 

  • Once a resource is booked, someone needs to manually send requestors additional forms depending on which resource is booked. 

Duplicating Workflows


If you need a new workflow that has a similar configuration to an existing one, you don’t have to create that new workflow from scratch. Rather, you can save yourself time by duplicating that existing workflow and then making any necessary changes. 

How to Do It

Step 1: Navigate to the Workflows page. 

Step 2: Click “Duplicate” next to the workflow you wish to copy. 

Step 3: 

  • Give your new workflow a name and description that clearly distinguishes it from the existing one. 

  • The default will be the name of the existing workflow with a number after it, but best practice is to change that during initial setup.

Step 4: Click “Duplicate Workflow”. 

Step 5: Click into the workflow you just created to open it. 

Step 6: Edit as needed.

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.