Submit a ticket My Tickets
Login  Sign up

Workflows for Events

Workflows allow requests or proposals to be routed to the right person(s) for approval. In event schedule planning, workflows are commonly used to route requests/proposals for events (based on the Event Forms) to designated event approvers. Each Event Type (and it’s Form) will be associated with a Workflow (note that you may associate the same Workflow with various Event Types, if desired).

Adding Workflows

To find the workflow dashboard, first click ‘Settings’ on the left hand side of your scheduling dashboard and then click the ‘Workflows’ tab. 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 requests for Athletics events to approvers for this Event Type, we might want to call it “Athletics Workflow” with the description “This workflow routes event requests for the Athletics event type from requesters to the Athletics office for approval”. 

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

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 defines the stages a request must go through in order to be approved
  • The “Author” of a workflow is the initial person(s) that initiates a request (Typically this is submitting the Event Request Form. This is the first step in the workflow)

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

On the left-hand side of the screen, a sidebar will pop up that will allow you to enter 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 an Athletics Event Request to the Athletics Office for approval, an example of a step name might be “Athletics Office Approval.”

The next field to fill out is participants. Participants refer to the person(s) that will be involved with reviewing the request, and their level of permissions within the workflow. 

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

    • 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 author for more details
    • 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: 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 automatically send the proposal to the next step, regardless of whether there are other participants that are currently expected to add commentary or vote at this step

You may also customize the Email Template sent to Participants when the workflow reaches their step. To edit the template, click the blue ‘Edit Email Template’ button and amend as needed. 

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.

The next field determines the number of votes required for approval and rejection. For example, if only 1 vote is required for approval, then only one participant would have to approve in order for this to be routed to the next step. 

You may additionally determine what happens if a proposal is rejected at a step. There are three options here:

  1. “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
  2. “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). At this point, the original author can choose whether to abandon the event or make changes and re-submit for approval
  3. “Reject the request entirely” would mean that the proposal would be rejected and that rejection would be final 

You may also determine 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. 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: 

  • Approved
  • Moved to the next step
  • Returned to the last step
  • Returned to its author
  • Rejected outright


Logic Jumps

The last field that you can configure in a workflow step is logic jumps. These are conditions that can be used to dynamically change the path of a request. Each step in a workflow can have a series of associated logic jumps. 

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 Athletics Event Form contains ‘Public’ under the answers to the ‘Event Open To’ question, then the request will go straight to a new step (to be defined under ‘Then jump to’). Otherwise, it will by default move onto the ‘Approved’ step.

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 option at the top of the Logic Jumps section. In this example, if the ‘Event Open To’ question either contains "Public" or “CUNY,” then the request will proceed to a step to be determined under ‘Then jump to’.

Finally, remember to scroll down to the bottom and click the ’Save’ button to lock in the step. 

Using Conditions

Conditions allow us to create logic jumps where exemptions should be made. 

  • Field Groups: This is a list of the Forms created in your platform. Forms are assigned to each Event Type. 
  • Field: This gives you a list of all questions within the form (Field Group) chosen.
  • Requirement: Used to identify how you would like the logic jump to be filtered.
    • Is - Strictly equals
    • Is not - Strictly different 
    • Contains - Includes value
    • Does Not Contain - Does not include value 

Example: If Event name (Field Group/Field) contains (Requirement) Tutoring (Value) then jump to Supplemental Instruction Director Approval (Step).

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.  


Finally, 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.


Dynamic Steps

Coursedog provides the ability to add dynamic steps into Workflows for both Resource Approvals and Room Approvals. Dynamic steps are ones in which the specifics of the request (i.e. the specific room or the specific resource(s) requested for the event in the event form) are dynamically generated and added to the workflow based on the the request submission (that a specific room or resource was requested in the Event Form submission). For example, if you add Room Approvals as a dynamic step in your Workflow then when Event Types associated with the workflow are submitted and specific rooms are requested that specific room’s workflow (owner/contact person/approver) will be triggered as part of the approval process. This action is detailed in the settings of the relevant room or resource. If you are utilizing Dynamic Steps, ensure that Room Settings and Resource Settings have workflows properly defined (see Review Room Settings and Review Resources for further details).

To add a dynamic step click the blue "+ Add Dynamic Step" button at the top of the workflow editor. Select one of the two types of dynamics steps: room approvals and resource approvals. Ensure the step is in the appropriate order (relatively to other steps in your workflow) to reflect the approval process you desire. 

When the request reaches a dynamic step, the action it takes depends on the room or resource that it is requested. This action is detailed in the settings of the relevant room or resource:

Viewing Workflows

The ‘History’ button in the top navigation shows all requests that have flowed through this workflow in the past. If you would like to go back to the default visual depiction of your workflow, you can click the ‘Graph’ button in the top navigation. This will allow you to visualize the full path, from request to approval, for 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.

Editing Workflows


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 the "Edit Workflow" button in the top navigation.


Justin is the author of this solution article.

Did you find it helpful? Yes No

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