Documentation

Workflows - Triggers

Table of Contents

Workflows - Triggers

Triggers, also called Event Hooks, run workflow tasks automatically in response to activity in QReserve. Use them to respond to new bookings, send reminders before reservations begin, follow up after maintenance, or take action when a resource changes status.

Triggers Overview

A trigger defines what activity to watch for, when to run, and which resources it applies to. Its workflow tasks define what happens when the trigger runs.

The available trigger categories are:

  • Approvals: Creation and status changes of individual approval records.
  • Maintenance: Creation, modification, cancellation, and timing of maintenance bookings.
  • Requests: Creation, modification, cancellation, or deletion of requests.
  • Resource: Changes to a resource's status.
  • Reservations: Creation, modification, cancellation, and timing of reservations.
  • Status Events: Initial status and subsequent status changes of reservations and requests.
  • Templates: Creation, use, modification, and cancellation events involving reservation templates.

A workflow can have multiple trigger conditions. Each condition provides a separate way to run the workflow; the conditions do not all need to occur together.

Creating Triggers

Create triggers from Administration > Workflows. Site moderators and administrators can configure and activate them.

For each trigger condition:

  1. Choose the category of activity to watch.
  2. Select an Event Type.
  3. Select a sub-event or status filter, where available.
  4. Set the event time and offset.
  5. Select a resource or resource tag, or leave these filters empty to include all matching activity at the site.
  6. Configure the workflow tasks and activate the trigger.

Both the workflow and the individual trigger condition must be active for the condition to run. Workflows must also be enabled for the site.

Trigger Types

Approvals

Approval triggers watch individual approval records associated with a booking or request.

  • Approval Creation: Runs when an approval record is created. New approval records begin in the Pending state.
  • Modifications (including auto-approve): Runs when an approval changes state. This includes manual decisions, automatic approvals, and self-approvals by the person making the booking.

Use the Approval Status filter to select Approved, Denied, or Pending, or choose All Events to include any approval status. For modifications, the filter matches the status the approval changes to. An Approval Creation condition filtered to Approved or Denied will not match the initial Pending record; use Modifications to respond to those decisions.

Approval triggers operate on individual approvals. A booking requiring multiple approvals can therefore produce multiple approval events. To respond to the booking's overall status, use Status Events.

Example: Notify a coordinator when an approver denies a request.

Maintenance

Maintenance triggers watch maintenance bookings.

  • Maintenance: Runs relative to the booking's creation, start, or end time. Choose All Events or the Record Maintenance sub-event.
  • Modified Maintenance Only: Runs in response to an existing maintenance booking being changed.
  • Cancellation: Runs when maintenance is cancelled. Choose All Events or the Cancel sub-event.

For a reminder before maintenance begins or a follow-up after it ends, select Maintenance and choose the appropriate start or end time. Start and end triggers use the latest version of the maintenance booking.

Example: Notify staff 30 minutes before scheduled maintenance begins.

Requests

Request triggers watch requests submitted through QReserve.

  • Request: Runs when a request is created. Choose All Events or the Request sub-event.
  • Modified Request Only: Runs when an existing request is changed.
  • Cancellation or Deletion: Runs when a request is cancelled or deleted. Choose All Events or the Cancel sub-event.

Request triggers are based on the time the selected action occurs. Use Approvals for individual approval decisions or Status Events for changes to a request's overall status.

Example: Send an acknowledgement when a new service request is submitted.

Resource

Resource triggers watch changes to the resource itself.

Select Modified with the Status sub-event to run when a resource's status value changes, such as from operational to broken or under maintenance.

Changing only the status description does not trigger the workflow. Neither does saving the same status again, changing another resource field, or assigning the resource's initial status when it is created.

This condition responds to status changes generally. Use a script task if subsequent actions should depend on the new status.

Example: Notify the facilities team when equipment changes to a broken status.

Reservations

Reservation triggers watch bookings, including loans.

  • Reservation: Runs relative to a reservation's creation, start, or end time. Choose All Events or the Reserve sub-event.
  • Modified Reservation Only: Runs in response to an existing reservation being changed.
  • Cancellation: Runs when a reservation is cancelled. Choose All Events or the Cancel sub-event.

To run before or after a reservation starts or ends, select Reservation and choose the appropriate start or end time. These triggers use the latest version of the reservation, so changes to its scheduled times are taken into account.

A reservation does not need to be modified for a start or end trigger to run. Use Modified Reservation Only when the change itself is what should trigger the workflow.

Example: Send preparation instructions 10 minutes before a reservation starts, or a follow-up one hour after it ends.

Status Events

Status Events track the status of reservations and requests, including their initial status and later transitions.

  • Initial Status: Runs when the reservation or request is first created. Select Any Status, Approved, or Pending.
  • Modifications: Runs when the status changes. Select All Status Changes, Approved, Cancelled, Denied, or Set to Pending.

The status filter matches the resulting status. For example, Modifications > Approved responds when a pending booking becomes approved. To also handle bookings that are approved from the outset, add an Initial Status > Approved condition.

For bookings or requests containing multiple resources, status changes to individual component bookings and changes to the overall booking are handled separately. One user action can therefore produce multiple matching status events. For cancellations of these bookings, only the overall booking's cancellation is handled by this trigger category.

Example: Start a preparation workflow when a reservation becomes approved.

Templates

Template triggers watch reservation templates and activity associated with their use.

  • Reservation: Runs for template creation or use events. Select Template is Used to specifically respond when a reservation is created using a template. All Events also includes other creation events in this category, such as creation of the template itself.
  • Modified Reservation Only: Runs when a reservation template is modified or a reservation created from a template is modified.
  • Cancellation: Runs for cancellation events involving templates. Select Cancel for template cancellations. All Events is broader and can also include a template being consumed by a reservation.

Template triggers also offer the reservation's start or end time as the reference point for an offset.

Example: Notify a coordinator when someone books a reservation using a template.

Trigger Offsets

An offset controls when the workflow runs relative to the selected event time.

  • Zero offset: Run when the selected time is reached.
  • After: Delay execution by the specified duration.
  • Before: Run ahead of a scheduled start or end time.

For Reservations, Maintenance, and Templates, the Object Event Time For Offset setting lets you choose:

  • Time of Event: The time the selected action occurred, such as creation, modification, or cancellation.
  • Start Time: The associated booking's start time.
  • End Time: The associated booking's end time.

Other trigger categories use the time the selected action occurs. An action such as creating a request or changing a resource's status can trigger work at that time or afterward.

For example:

  • Run one hour after a reservation is created.
  • Run 10 minutes before a reservation starts.
  • Run 30 minutes after maintenance ends.
  • Run 15 minutes after an approval changes to Approved.

For ordinary reservation and maintenance start/end workflows, use the Reservation or Maintenance event type. These follow the booking's latest scheduled times and do not run for bookings that have been cancelled before the trigger is due.

Recurring Bookings

Changes to a recurring series, such as extending or shortening it, are treated as modifications. Use Modified Reservation Only or Modified Maintenance Only to respond to those changes, rather than relying on creation or cancellation conditions.

Specifying Resources for a Trigger

A trigger condition can apply to:

  • A specific resource.
  • Resources sharing a selected tag.
  • All matching activity at the site, if no resource or tag filter is selected.

For example, assign a Meeting Rooms tag to your rooms, then use that tag on a reservation start trigger to apply the same reminder workflow across those rooms.

Resource and tag filters are available for all seven trigger categories.

Trigger Tasks

Tasks define the actions performed when a trigger runs. A task can produce output for later tasks, allowing several steps to work together.

For example, a Run a Script task can check a form response, prepare email content, or decide whether later tasks should continue. An Emit a Webhook task can send information to an external system.

Refer to the individual Workflow Tasks documentation pages for task configuration details.

Trigger Notifications

Configure one or more notification email addresses and choose whether to include successful runs, failed runs, or both.

Notifications are collected into a daily summary covering subscriptions and triggers. Use this summary to identify failed workflows and investigate any tasks that need attention.

You can also configure a trigger to pause automatically after a selected number of failed runs.

Review Trigger Runs

Open a trigger from Administration > Workflows and scroll to its logs to check what happened when it ran.

  1. The initial view shows the five most recent entries. Click Show More Logs when available to browse older entries.
  2. Set Start Date and End Date, choose successful and/or failed logs, then click Apply Filters. Dates use your local timezone; blank dates include all dates. To investigate errors, leave Include failed logs on and turn off successful logs.
  3. Use the page controls to browse results. Click Show Details on a run to inspect task results, errors, and generated records. Detailed results require permission to edit the workflow.

Use Clear Filters to reset the search or Show Recent Logs to return to the short view. Before repeating a failed run, check whether earlier tasks already created records.

If the trigger has no matching run, check that the workflow and trigger condition are active and that the event type, resource filters, and timing match the activity you expected. See Subscriptions for more log troubleshooting guidance.