Coursedog

Submit a ticket My Tickets
Welcome
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 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. 

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.

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 author email is intended for when a workflow is sent back to the author (this is NOT the request created email), and the approval 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

  1. Request Edited
  2. 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:

  1. Request Created: This is sent to the author when the request is created
  2. Request Edited: This is sent to all request participants when a request is edited
  3. Request Rejected: This is sent to the request author when the request is rejected
  4. 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:

  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

 

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.


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.


/var/folders/24/b5lxrtdj5zb3tj1f6z2svclr0000gn/T/com.microsoft.Word/WebArchiveCopyPasteTempFiles/4blRLGmDaY4xf8nuDZKQFEMay6hz_NAymb8eSR2jqE-yyuupgprlf0Mvew3txkZgdYs-_0lrLTMkN2xaHOG_JTInAwuIS1KOajbKWSxlPHtmb0hS5MNrHcywJQ7lai4dFqqlwEI1

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
  • CONTAINS
  • DOES_NOT_CONTAIN
  • IS_GREATER_THAN
  • IS_LESS_THAN
  • IS_GREATER_OR_EQUAL, IS_LESS_OR_EQUAL
  • IS_BEFORE
  • IS_AFTER
  • IS_WEEKDAY
  • IS_WEEKEND


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')


/var/folders/24/b5lxrtdj5zb3tj1f6z2svclr0000gn/T/com.microsoft.Word/WebArchiveCopyPasteTempFiles/rffU2pvxGd_E6hx1bCGKuCq68SlBy2ZXwld3J9bOSvo3yR-jbBwIsWuiG6dSenMZOhjJDjGd4OmgJpVp1-5HiDeq08JhgV33CRO-030cUZB8XyyFta3QM7KKt1NwKAsjFaruY1We

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.  


/var/folders/24/b5lxrtdj5zb3tj1f6z2svclr0000gn/T/com.microsoft.Word/WebArchiveCopyPasteTempFiles/kNg8jUz-kEzca0xlE3mAOY9_3eG-HdeKlzZTOjnWmE43ZdUq3J_mzo9ECeC1Cc0-f8USBfhDNXCsQ4OPF_kPBNi46BBVrCAiE7YuD4_DbKlm4h_q_1cf0dU_9nGGjppca__zxMGq


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.

/var/folders/24/b5lxrtdj5zb3tj1f6z2svclr0000gn/T/com.microsoft.Word/WebArchiveCopyPasteTempFiles/-p9lsKBMNdPVgDli2Wu4_IIR9HZN_VDLpEtF_8stmx-qVxcjn8ZgoGqOJyeeFnNVCdBHYggnTurxhFKPF5eqN4izpu-QpiaIF-VPfmCxApToanQjIgHTfh2Rx2yzlmZEd6VMecFp



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.

 


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


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". If set to "on", participants associated with a workflow will be able to send a request back to a prior step in the workflow via the following inputs:

  1. User selects "route back action"
  2. User selects step to route back to
  3. User selects action upon return

Once a request is sent back, this will be reflected in the Request's decisions list, and in the status  of the steps.

In the example below, the request was sent back from Step 1 to the Author step, and as a result, there is an additional Author step in the list of total steps, indicating the the author must now approve again for the workflow to move forward.

In the request email templates, users can specify a custom email template for approvers & viewers if the request is routed back to that step:


Separately, each workflow step has a "Rejected" email template for when a request is rejected at a future step, and that rejection causes the workflow to route back to a prior step (i.e. not "reject entirely") , that can be customized on a step by step basis.



Additionally, the comments that users made on the request while adding their approvals/rejections can be injected as a dynamic variable.

How Proposals Use Workflows

At each workflow step, the workflow graph is re-evaluated using Just In Time functionality. 

This has several impacts on the proposal workflow:

- Each time a field is being modified using the downstream editing functionality, the predicted workflow is updated to reflect the upcoming next steps, assuming users vote "approve" on all the upcoming steps.

- If the user changed a field value that would impact any upcoming logic jumps, the workflow will be recalculated from the current workflow step onwards, the proposal would change its path and progress through a different set of workflow steps.

For example, when the department scheduler has been changed in the department step after the proposal has been initially submitted we now ensure it is sent to the correct users (use cases here include changes of department scheduler be reassigned etc). Now, the change would impact the proposal's workflow as the workflow would be dynamically re-evaluated.


10.11 Custom Workflow Decisions

Use Case

The custom workflow decision proposal allows the user to create workflow step decisions with custom verbiage, icons, and workflow routing. This is useful in cases where school 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...

Workflow Step Configuration

Adding Decisions

In the configuration of workflow steps, there is now a section labeled decisions.

Users can add decisions as voting options in the workflow step by clicking "add decision"

Clicking "add decisions" opens a modal where users can select from existing decisions in the decision collection or can create new / manage decisions in "manage decisions." In the below example, we are able to select between "recommend approval" or "recommend rejection."

Managing Decisions

Within "manage decisions," I can modify existing decisions or create new decisions.


When creating a new decision, users can configure label, icon, icon color, and votes required for. As a note, 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"

To edit or delete the decision, a user can click the pencil or trash can icon. As a note, 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. Ex) I create decision A and apply it to workflow step 1. I later delete decision A. Decision A still exists in workflow step 1.


Editing Decisions

When clicking the pencil icon, users can then edit the decision. To save changes, click "edit".


Defining Decisions in the Workflow Step

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

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

Logic Jumps

Users can use decisions in logic jumps by selecting when decision is. This option allows users to select "approved" or any decisions that have been configured within the step.

NOTE: 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.

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.

NOTE: Users are automatically granted decisions permissions.


Proposals

Voting

If a user has a decision permission, when the proposal is in their workflow step, they will be able to vote for those decisions.

Display

The user's decision will display throughout the application, with the decisions icon, icon color, and decision name.

The proposal dashboard will also display the icon and name of decisions, if users voted for the decision at that step

Activity Log

The activity log reflects user votes, and displays the name of the decision the user voted for.


Use Case

The custom workflow decision proposal allows the user to create workflow step decisions with custom verbiage, icons, and workflow routing. This is useful in cases where school 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...

Workflow Step Configuration

Adding Decisions

In the configuration of workflow steps, there is now a section labeled decisions.

Users can add decisions as voting options in the workflow step by clicking "add decision"

Clicking "add decisions" opens a modal where users can select from existing decisions in the decision collection or can create new / manage decisions in "manage decisions." In the below example, we are able to select between "recommend approval" or "recommend rejection."

Managing Decisions

Within "manage decisions," I can modify existing decisions or create new decisions.


When creating a new decision, users can configure label, icon, icon color, and votes required for. As a note, 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"

To edit or delete the decision, a user can click the pencil or trash can icon. As a note, 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. Ex) I create decision A and apply it to workflow step 1. I later delete decision A. Decision A still exists in workflow step 1.


Editing Decisions

When clicking the pencil icon, users can then edit the decision. To save changes, click "edit".


Defining Decisions in the Workflow Step

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

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

Logic Jumps

Users can use decisions in logic jumps by selecting when decision is. This option allows users to select "approved" or any decisions that have been configured within the step.

NOTE: 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.

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.

NOTE: Users are automatically granted decisions permissions.


Proposals

Voting

If a user has a decision permission, when the proposal is in their workflow step, they will be able to vote for those decisions.

Display

The user's decision will display throughout the application, with the decisions icon, icon color, and decision name.

The proposal dashboard will also display the icon and name of decisions, if users voted for the decision at that step

Activity Log

The activity log reflects user votes, and displays the name of the decision the user voted for.



Did you find it helpful? Yes No

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