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).
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 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 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 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 the 'Request Route Back' section in this article
- 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 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 means that it will entirely approve the request, regardless if there are other participants that are currently expected to add commentary or vote.
- Role vs Workflow Permissions: when there is a conflict between Role permissions vs Workflow step permissions, the default is the user will be able to edit the request (as long as one permission allows).
- Example: if a user has Settings > Roles > Requests > Edit Requests set to DENY (as well as 'Edit Requests Without Updating Workflow' and 'Edit Requests And Maintain Approvals' permissions) and Workflow > Can Edit Request step permission set to ALLOW, they will be able to edit the request
- Example: if user has Settings > Roles > Requests > Edit Requests set to ALLOW and Workflow > Can Edit Request step permission set to DENY, they will be able to edit the request
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.
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 email is intended for when a workflow is sent back to the author (this is NOT the request created email), and the email is when the request is approved. To learn more about settings defaults for email templates at various steps, see 'Request Email Defaults' at the bottom of this article.
When a user edits a request, two potential emails are sent out
- Request Edited
- 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" opens a modal with multiple email template options:
In this modal, you can edit the following templates to be workflow specific, and also insert variables into these email notifications - including workflow decision comments:
- Request Created: This is sent to the author when the request is created
- Request Edited: This is sent to all request participants when a request is edited
- Request Rejected: This is sent to the request author when the request is rejected
- 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:
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:
- “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). At this point, the original author can choose whether to abandon the event or make changes and re-submit for approval
- “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:
- Moved to the next step
- Returned to the last step
- Returned to its author
- Rejected outright
Workflow Step Deadline Reminder
Users can now configure the number of days a deadline reminder email will be sent to users.
Deadlines Step reminders also have their own email template.
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.
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.
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.
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:
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.
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.
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.'