A reservation task sets up a template reservation to be created each time your subscription runs. When first added, a reservation window will pop-up to pre-fill in the desired reservation parameters such as resources, rates, and any forms. The reservation template can be edited by clicking on the Edit button anytime after the task is initially setup.
The start and end of a reservation is setup on the task card itself where you select the start and end times relative to the subscription date. For example, you if a subscription is scheduled to run on the first of each month to create a month long reservation then you can set the Start to be Same day and the End to be End at the end of the month (Same Month). This option will handle the variable number of days in each month automatically.
When run, a reservation will be attempted but could fail if there is a conflict or some other rule prevents the reservation being created.
A credential record task will create a credential record for the subscriber at the time the subscription is run and will have that credential expire at the default expiry time set in the credential's definition. If the credential definition defaults to suppressed notifications then the user will not be notified.
Optionally, this task can also generate an invoice line item to be fed into a subsequent invoice generation task! For example, a monthly fitness membership can generate a fitness membership credential required to book time in your gym and then invoice and (if enabled) charge a customer automatically.
An invoice generation task is used to generate an invoiced based on previous tasks. The invoice task on its own can not create line items at this time however both reservation tasks and credential tasks can create invoice line items to be fed into the invoice generation task.
If your site has a payment processor with card-on-file capability you can optionally attempt to pay the invoice automatically at the time of creation. This allows for recurrign membership or subscription fees to automatically be charged to users! If a payment attempt fails then the subscription itself will be marked as failed and included in the failed notification email; however, previously succeeded tasks will still exist. For example, if a reservation for a parking spot was created but the payment for that parking spot failed, the user will receive an unpaid invoice and the reservation will still exist.
- Invoices will not be generated if their total sum is zero.
- If a default tax rate is setup on your Tax Rates window in Invoices, it will be applied to each line item automatically.
- If paid automatically, the invoice will not be emailed to the user; however, a payment receipt will be emailed and the invoice is available in the User's history.
This task is used to generate one of your custom reports and then email a temporary link, last 7 days, to one or more people. Recipients include the user the subscription is assigned to, a list of specific email addresses, or an entire user group.
This task is used to send an email to a specified email address. More flexibility can be unlocked by combining with a script that can return an object specifying specific recipients and content for the email based on context and rules.
This task is used to send a Slack message to a specified channel or user. More flexibility can be unlocked by combining with a script that can return an object specifying specific recipients and content for the message based on context and rules.
You can use a Script task to extract a summary of a reservation to be used as a variable in a subsequent email task. Below is an example of this and make note of the script's Task ID and the email task's Input Script Task ID. We assign the
reservation['summary'] value to the
SUMMARY variable that we can use in our reservation body by writing
This example will work for any Requests or Reservations based triggers. If you are using an Approval trigger then the reservation information is, instead, inside of the
approval variable and you would write
Webhooks are a convenient way to integrate your QReserve workflows with external systems by sending HTTP requests to an endpoint in response to events in QReserve. You can send a GET request without a body or a POST or PUT request with a body.
Prior to creating a webhook task you must request the domain of your webhook to be added to your site's list of approved domains. Please contact us to have your domain added to your site's approved list.
Support for Basic Auth is built in if you have a username or password to provide. You are also able to set a list of HTTP headers to include your task such as
Authorization to provide alternative means of authenticating with your server. Password fields and Authorization headers are typically redacted from logs; however, you should be cautious with the use of credentials as they could show in some workflow logs or error reports.
For dynamic webhooks, a Script task can be used to inject content that is a function of your workflow such as a reservation or user. Please refer to the help text provided in the Input Script Task ID field for information about the fields you can set via a script. If a script includes a dictionary as the POST contents then your request will automatically be sent as JSON.
Each webhook request also contains a
QReserve-Signature header that can be used by the receiving party to verify the authenticity of the webhook by calculating an HMAC signature as a function of a secret key, a timestamp, url and HTTP body contents.
Scripts are an incredibly powerful task that can take the input of previous tasks or trigger objects as context to generate content for emails or decide whether or not to continue on to additional tasks. For more information, please refer to the sneq developers documentation.