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.

As an example, in event schedule planning, workflows are commonly used to route proposals for events to event approvers.

Creating a Workflow

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 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 now 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 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 5 different options for privileges you can give participants in the approval process. 

Step Participants - 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 proposer 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 if there are other participants that are currently expected to add commentary or vote at this step.


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



The next field determines what percentage of participants need to approve the request in order for it to be sent along to the next step. 100% would mean that all of the participants must approve the request in order for it to be approved. 

If there are two participants in the request, and the Percent required for approval is 50%, then 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: the first is to “Return the proposal to the previous step”. 

  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 resubmit for approval.
  3. “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. 

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


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.


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.


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.  


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.


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.

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

Additionally, there is something called Workflow History, which shows all requests that have occurred in the past for this workflow. 

Dynamic Steps

Dynamic steps are dynamically generated based on the specifics of the request. To add a dynamic step click the blue "+ ADD DYNAMIC STEP" button at the top of the workflow editor.

There are two types of dynamics steps: room approvals and resource approvals. 

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:

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.