> For the complete documentation index, see [llms.txt](https://requiply.gitbook.io/requiply-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://requiply.gitbook.io/requiply-docs/knowledge/settings/workflows.md). # Workflows Automate what happens when a rental changes: send an email or message, notify staff, or update a booking automatically when a trigger and its conditions match. The **Workflows** page is where you set up automated actions that Requiply runs when something happens to a booking. It is used to send the right message to the right person at the right time without anyone on your team having to remember to do it, and connects directly to bookings, booking statuses, payment statuses, email and message templates, organization accounts, your custom fields, and your connected communications provider. You can find this page under **Settings → Workflows**. {% hint style="warning" %} **Admin only.** Non-admin team members cannot view or edit this page. {% endhint %} ![Workflows page](https://572107616-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCrrH3uq16OeTomix4tP8%2Fuploads%2Fgit-blob-8bcb524597d0d2264ab2a8fe631e15e371010cbf%2Fimage.png?alt=media) ## Why this page matters Workflows are how Requiply turns booking events into outgoing communication. Instead of manually emailing a client when a booking is confirmed, alerting your team when payment goes through, or nudging a manager a day before an appointment, you define the rule once and Requiply handles every future booking automatically. Workflows pull together several other parts of Requiply: * **Bookings** — every workflow listens to something that can happen on a booking. * **Booking statuses** — workflows can fire when a booking reaches a specific status (for example, *Confirmed* or *Cancelled*). * **Payment statuses** — workflows can fire when a booking's payment reaches a state such as *Completed* or *Refunded*. * **Email templates** — most workflow actions send an email built from a template you have already designed. * **Clients, internal recipients, and your team** — workflows can email the booking's client, a fixed list of addresses, or your own organization accounts (and even push to their phones), or message the booking's client over SMS, Viber, or Telegram. * **Communications integrations** — the **Send message to client (SMS / Viber / Telegram)** action delivers through the provider connected on the [Communications](/requiply-docs/knowledge/settings/integrations/communications.md) page. * **Message templates** — that action's wording, attachments, and buttons come from a [message template](/requiply-docs/knowledge/settings/booking-settings/message-templates.md), the messenger counterpart to email templates. * **Filters** — every workflow can carry optional conditions that decide whether it actually runs for a given booking. If your email templates, booking statuses, or custom fields change, the workflows that reference them keep using the new values automatically. ## Who can use this page * **Admins only.** The page, the add screen, and the edit screen all require admin access. * Workflows stay administrator-only. A group with **Allow access to settings** reaches the rest of Settings but does not see Workflows in the menu, and the route itself is gated to the [Administrators group](/requiply-docs/knowledge/settings/organization-settings/accounts/groups.md). * The page itself does not have its own plan limit or paid add-on gate; it relies on the email templates and booking status features being available in the organization. ## What you'll see When the page loads, Requiply fetches all of the organization's workflows, all email templates, and the list of booking statuses in parallel. While that data is loading, you see three pulsing skeleton cards. Once the data is ready, you see one of two layouts: * **If you have at least one workflow:** a wrapped grid of workflow cards, each showing the workflow's name, what triggers it, any conditions, and what it does. A round **+** button labelled *Add workflow* sits at the end of the grid as the primary way to create a new one. * **If you have no workflows yet:** an empty-state placeholder with a sitemap icon, a short title, and a single call-to-action button that takes you to the add screen. Each workflow card is clickable and leads to the edit screen for that workflow. The card shows the resolved trigger label (for example, the human-readable status name or payment status) and a summary of the action: * For email actions, it shows the resolved **template name**. If a workflow still references the legacy built-in default email template, the card shows that template under its localized name rather than a raw ID. * For the two **organization-account** actions, it resolves each selected account to its full name (falling back to the account's email) and lists them as the recipients. If none resolve, it shows *"No accounts selected."* * For the **push notification** action, no template name is shown — push notifications don't use a template — and the selected account names are listed instead. ## Empty state The empty state appears the first time you open Workflows in a new organization. It uses a sitemap icon, an "empty" title, and one primary action that opens the **Add workflow** screen. There is no secondary content — the goal is to push you straight into creating your first automation. The first workflow most businesses set up is something like "send a confirmation email when a booking reaches *Confirmed*", because that single rule replaces a manual step that otherwise has to happen for every booking. ## How a workflow is built Every workflow is made of three building blocks, and the add/edit form is laid out in exactly this order: 1. **Trigger — *****when***** it fires.** The booking event that wakes the workflow up (a status change, a payment change, a new booking, or a time relative to the booking). 2. **Filters — *****only when***** it should run** *(optional)*. Conditions that must be met for the workflow to actually fire on a given booking. Leave them empty and the workflow runs every time the trigger matches. 3. **Action — *****what***** it does.** What Requiply sends, and to whom (an email to the client, an email to a typed list, an email to your team's accounts, a push notification to their phones, or a messenger/SMS message to the client). As you fill in the form, a live **Preview** panel shows the workflow as a sentence: the trigger card, then any conditions under an **"Only when"** heading, then the action card. Reading the preview is the fastest way to confirm a workflow does what you intend before you save it. The detailed reference for each block — [Triggers](#triggers), [Filters](#filters-only-run-this-workflow-when), and [Actions](#actions) — follows the add/edit walkthrough below. ## Adding a workflow Clicking **Add workflow** (either the **+** button on the grid or the empty-state button) opens the dedicated **Add workflow** page at `/settings/workflows/manage/add`. The screen is a single form split into the sections described above, plus general info and an enabled toggle. **General info** * **Name** — required, up to 100 characters. This is the label shown on the workflow card. **Trigger, Filters, and Action** These three sections make up the body of the form and are documented in full in [Triggers](#triggers), [Filters](#filters-only-run-this-workflow-when), and [Actions](#actions) below. **Enabled toggle** A switch at the bottom controls whether the workflow is active. New workflows default to enabled. A disabled workflow stays in the list but does not run. **Saving** Pressing **Save** validates the form. If everything is valid, Requiply creates the workflow, shows a success toast with the workflow name, and returns you to the Workflows list. If creation fails, an error toast appears and you stay on the form. While the request is in flight, the entire screen is blocked so you cannot double-submit. **Cancel** returns to the list without saving. ## Triggers You pick one trigger type, and the form then reveals only the fields that apply to it. * **Status reached** — fires when a booking enters a specific status. You pick the status from the list of statuses configured for your organization; each option is shown as a colored tag using the status's own color. Defaults to your **Default status for new bookings** (*New* unless you changed it under [Booking creation](/requiply-docs/knowledge/settings/booking-settings/booking-creation.md#choosing-the-starting-statuses)) the first time this trigger type is selected. * **Payment status reached** — fires when a booking's payment reaches a specific state (for example *Completed*, *Refunded*). The dropdown shows each payment status as a colored tag. Defaults to *Completed*. * **Booking created** — fires once, when a new booking is created. No extra configuration. * **Relative time reached** — fires at a configured offset before or after a booking's start or end time. You choose: * **Relative to** — *Booking start time* or *Booking end time*. * **Direction** — *Before* or *After* (a segmented button, must have a value). * **Offset** — a number with a time unit picker (the number selector remembers the unit so an offset saved in minutes can still be edited as hours or days). Must be greater than zero. These four are the only trigger types. Whichever you pick, the workflow's optional [Filters](#filters-only-run-this-workflow-when) are checked right after the trigger matches and immediately before the action fires. ## Filters: "Only run this workflow when…" Filters are an **optional** conditions block on each workflow. They sit between the **Trigger** and **Action** sections of the form, under a **Filters** heading with the hint *"Only run this workflow when these conditions are met. Leave empty to always run."* In the live **Preview**, the conditions appear under an **"Only when"** heading between the trigger card and the action card. ![Filters builder with two AND-groups: a Booking total cost condition, an "&" divider, and a Client pricing discount condition](https://572107616-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCrrH3uq16OeTomix4tP8%2Fuploads%2Fgit-blob-392f4894780104c296337bfec955cb985105babb%2Ffilters-builder.png?alt=media) ### How the matching works: AND of OR-groups Filters are organized into **groups**: * Conditions **inside the same group** are combined with **OR** — any one of them matching satisfies the group. The builder shows an **OR** connector between rows. * **Separate groups** are combined with **AND** — every group must be satisfied. The builder shows an **`&` / AND** divider between groups. So the overall rule reads as *(A or B) **and** (C or D)*. This is exactly how Requiply evaluates it on the server: each group needs at least one matching condition, and all groups must pass. {% hint style="info" %} **Empty filters = always run.** If you configure no filters (or leave every group empty), the workflow runs whenever its trigger matches. Removing all conditions is how you go back to "fire on every matching booking." {% endhint %} Filters are checked for **every** trigger type — including relative-time workflows that are processed later by a background job — after the trigger matches and just before the action fires. ### What you can filter on Fields are grouped into **Booking** and **Client**, each with built-in (native) fields plus any custom fields you've configured. **Booking (built-in):** | Field | Type | Notes | | -------------- | ------ | --------------------------------------------------------------------------------- | | Booking status | Select | Options are your organization's booking statuses, shown with their status colors. | | Total cost | Number | | | Start date | Date | | | End date | Date | | | Created at | Date | | **Client (built-in):** | Field | Type | Notes | | ------------------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | First name | Text | | | Last name | Text | | | Email | Text | | | Phone | Text | | | Pricing discount | Select | Options are your organization's pricing discounts. | | Telegram connected | Checkbox | Whether the client has connected to your [Telegram bot](/requiply-docs/knowledge/settings/integrations/communications.md#connecting-clients-to-your-telegram-bot). Use it to send Telegram only to clients who can actually receive it. | **Custom fields:** any entity field you've configured at the Booking or Client level also appears, grouped under **Booking custom fields** / **Client custom fields**. Each one's input type (text, number, date, select, multiselect, or checkbox) follows the custom field's own type. ### Operators by field type The operators available depend on the field's kind: | Field kind | Operators | | ----------- | ----------------------------------------------------------------------- | | Text | contains, is, is not, is empty, is not empty | | Number | is, is not, greater than, less than, is between, is empty, is not empty | | Date | is before, is after, is between, is empty, is not empty | | Select | is, is not, is any of, is none of, is empty, is not empty | | Multiselect | contains any of, contains all of, is empty, is not empty | | Checkbox | Yes, No | The value input adapts to the field and operator you choose: * **is empty / is not empty**, and the checkbox operators **Yes / No**, show **no value input** at all. * **is between** (number or date) shows **two inputs** (a min/max pair, or a date range). * **is any of / is none of** (Select) and the Multiselect operators show a **multi-select chip picker**. * Anything else shows a single text, number, date, or select input matched to the field. Changing the field resets the operator to that field kind's default and clears the value; changing the operator on its own clears the value. ### Things worth knowing about how conditions match * **Text** comparisons (*is*, *is not*, *contains*) are **case-insensitive**, and a *contains* with an empty value never matches. * **Number** and **date** values that can't be read are treated as not matching, so a workflow never fires on a value it couldn't parse. * **Select** conditions store the option's underlying value (for example, a status id); the preview resolves it back to the readable label for you. * A condition whose value you leave blank simply doesn't match — it won't accidentally let the workflow run. {% hint style="warning" %} **Filters fail closed.** If Requiply can't load the data a filter needs for a particular booking, the workflow does **not** run for that booking. This avoids sending the wrong message when something is missing. {% endhint %} ### Building and editing filters * With no conditions yet, you see a single **Add filter** button. * Once you've added one, each group is a card of OR rows. Inside the card are an **Add OR condition** button and a **Remove group** button; below the cards is an **Add AND group** button to start a new group, with an **`&`** divider between groups. Each individual row also has an **×** to remove just that condition. Field labels in the dropdown are prefixed with their source, e.g. *Booking · Total cost* or *Client · Pricing discount*. * When you save, empty groups are pruned. If nothing is left, the workflow saves with no filters and goes back to running on every matching trigger. ## Actions The **Action** section decides what the workflow does and who it reaches. There are **five** action types. The first three send an email built from an email template; the fourth sends a mobile push notification and uses no template; the fifth messages the client over SMS, Viber, or Telegram using a [message template](/requiply-docs/knowledge/settings/booking-settings/message-templates.md). ### Send email (to the client) Sends the chosen email template to the **client on the booking** that triggered the workflow. An info note explains the exact behavior: *"Sent to the client on the booking that triggered this workflow. Skipped if the trigger isn't booking-related or the booking has no client."* * **Email template** — required. ### Send email to list Sends the chosen template only to a **custom list of email addresses** you enter as chips (the booking's client is **not** included). Use this for notifications to addresses that aren't Requiply accounts — for example a shared inbox. The list cannot be empty when saving. * **Email template** — required. * **Custom emails** — at least one address, entered as chips. ### Send email to organization accounts Sends the chosen template to one or more of your **organization's accounts** (your own team members), rather than to the client or to free-typed addresses. You pick the recipients from your account list. * **Email template** — required. * **Account recipients** — a chip/multi-select picker of organization accounts. At least one account is required; trying to save with none shows the error toast *"Select at least one organization account."* * An info note reads: *"Sent to the email of each selected organization account."* Use this when the recipients are real Requiply accounts — for example, email the assigned manager when a booking is confirmed. (This is the difference from *Send email to list*, which goes to arbitrary typed addresses that don't have to be accounts.) ### Send push notification to organization accounts Sends a **mobile push notification** to selected organization accounts' registered devices. This is the only action that does **not** use an email template. ![Add-workflow form with the push notification action selected, showing title, body, tap action, and the account picker](https://572107616-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCrrH3uq16OeTomix4tP8%2Fuploads%2Fgit-blob-6ad96b1958530f42ba0cd228a01a726c815170d3%2Fstaff-push-action.png?alt=media) * **Account recipients** — the same account picker as above; at least one required. * **Notification title** — **required**. You can insert booking template variables into it with the **Insert variable** picker (for example `#{{bookingId}}`). * **Notification body** — optional free text, also supports template variables (such as `{{clientName}}` and `{{bookingTotal}}`). Left blank, it's saved as empty. * **Tap action** — where the notification opens when tapped: * **Open booking #ID** — the triggering booking (default). * **Open client #ID** — the booking's client. * **Open booking list** — the bookings list. * An info note reads: *"Users that don't have app installed will be skipped."* There is no email template field for this action. ### Send message to client (SMS / Viber / Telegram) Sends a message to the **client on the booking** that triggered the workflow, over SMS, Viber, or Telegram, through the messaging provider connected on the [Communications](/requiply-docs/knowledge/settings/integrations/communications.md) page. The wording comes from a [message template](/requiply-docs/knowledge/settings/booking-settings/message-templates.md), not from the workflow itself. {% hint style="warning" %} **Requires a Communications integration.** If no provider is connected, this action shows a warning — *"To use this action you have to configure a communication provider."* — with a **Configure provider** link to the [Communications](/requiply-docs/knowledge/settings/integrations/communications.md) page. The remaining inputs stay hidden until a provider exists. {% endhint %} Once at least one provider is connected, you'll see: * **Provider** — **required**. A dropdown listing only the providers your organization has actively connected (each with its logo). Other catalog providers are not selectable. * **Channel** — **required**. Scoped to what the chosen provider supports. TurboSMS offers *SMS*, *Viber*, and *Viber, with SMS fallback*; Kyivstar and Twilio offer only *SMS*; Telegram offers only *Telegram*. The default is *Viber, with SMS fallback* when the provider supports it; otherwise it switches to that provider's first supported channel. * **Message template** — **required**. A dropdown of your [message templates](/requiply-docs/knowledge/settings/booking-settings/message-templates.md), each tagged with its format. Only templates **compatible with the selected channel** are listed: plain **Text** templates work everywhere, **Telegram** templates only on the Telegram channel, and **Viber** templates on the Viber channels. Changing the channel clears a selection that no longer fits. An info note reads: *"Sent to the client via your configured messaging provider. The message content comes from the selected message template."* If no compatible template exists yet, the picker is replaced by a warning — *"No message templates match the selected channel yet."* — with a **Create a template** link that opens the message template editor and returns you here afterwards. Because the action needs a real booking and client, it pairs with the booking-related triggers (*Status reached*, *Payment status reached*, *Booking created*, and *Relative time reached* — ideal for reminders). It is skipped when the booking has no client, when an SMS/Viber recipient has no phone number, or when a Telegram recipient has never connected to your bot. Every attempt — successful or not — is recorded on the client's **Messaging** card with the reason for any failure. {% hint style="info" %} **"Viber, with SMS fallback"** (TurboSMS only) submits the message for both Viber and SMS: the aggregator delivers via Viber when it can, and falls back to SMS when it can't. This needs both a Viber sender name and an SMS sender name configured. {% endhint %} ![Workflow preview for a Telegram client message, next to the message the client receives](https://572107616-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCrrH3uq16OeTomix4tP8%2Fuploads%2Fgit-blob-17474fe502b42261ded636e5787970d418608e3e%2Fclient-message-telegram.png?alt=media) The preview column summarises the rule — trigger, filters, action, template — and the message on the left is what the client actually receives: the rendered template with its link button and the invoice attached. {% hint style="info" %} **Workflows that carried their own SMS text were migrated.** Each one now points at a plain-text message template created from its old body and named after the workflow. Edit the wording under [Message templates](/requiply-docs/knowledge/settings/booking-settings/message-templates.md) — the workflow itself only stores which template to send. {% endhint %} **Template fields across actions:** the three email actions require an **email template**; the client message action requires a **message template**; the push notification action uses neither. Each dropdown lists every template of its kind in the organization and shows a loading state while they are being fetched. When none exist, the email actions disable the field and offer a **Create template** button, and the client message action offers its **Create a template** link — both remember where you came from so you can return. ## Editing a workflow Clicking a workflow card opens the **Edit workflow** page at `/settings/workflows/manage/edit?id=…`. The form looks the same as the add form, with a few differences: ![Edit workflow page](https://572107616-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCrrH3uq16OeTomix4tP8%2Fuploads%2Fgit-blob-ebbaae54260464caaab2d8dff7d58c8ff588f679%2Fedit-page.png?alt=media) * The screen is blocked with a fullscreen overlay until the workflow has been loaded from the server. If the workflow can't be found, you see an error toast and are sent back to the list. * The form is prefilled with the workflow's current name, trigger, filters, action, template or recipients, and enabled state. Time-based triggers also restore the original time unit so the offset displays naturally (for example, an offset stored as 1440 minutes is shown as 1 day). * A **Save** button is disabled until you actually change something — a built-in dirty check compares the current form against the originally loaded workflow. * A **Delete** button (red, outlined, trash icon) sits in the bottom-left. It opens a confirmation dialog showing the workflow's name. Deleting is permanent: the workflow stops firing immediately, and there is no undo. After deletion you are returned to the list with a confirmation toast. * If the workflow was originally created with the legacy "default email template" (no longer offered to new workflows), an extra option called *Default email template* appears at the top of the template dropdown so the existing selection stays valid. Once you switch to a real template, that legacy option goes away. ## Searching, filtering, or sorting the list The Workflows **list** does not have search, filters, sorting, or pagination — all workflows are shown together as cards. This is intentional: most organizations have a small number of workflows, and the visual card layout makes them easy to scan. {% hint style="info" %} Don't confuse this with the per-workflow [Filters](#filters-only-run-this-workflow-when). The *list* has no filtering, but each individual workflow can carry conditions that decide when it runs. {% endhint %} ## Forms and fields | Field | Required | Notes | | ------------------ | -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Name | Yes | 1–100 characters. Used as the card label. | | Trigger type | Yes | One of: *Status reached*, *Payment status reached*, *Booking created*, *Relative time reached*. | | Status | Yes when trigger is *Status reached* | Picked from the organization's booking statuses; shown as a colored tag. | | Payment status | Yes when trigger is *Payment status reached* | Picked from the available payment statuses. | | Relative to | Yes when trigger is *Relative time reached* | *Booking start time* or *Booking end time*. | | Direction | Yes when trigger is *Relative time reached* | *Before* or *After*. | | Offset | Yes when trigger is *Relative time reached* | Number greater than zero, with a unit selector (minutes/hours/days). | | Filters | No | Optional conditions. Empty = always run. See [Filters](#filters-only-run-this-workflow-when). | | Action type | Yes | *Send email*, *Send email to list*, *Send email to organization accounts*, *Send push notification to organization accounts*, or *Send message to client (SMS / Viber / Telegram)*. | | Email template | Yes for the three email actions | Picked from your email templates. Not used by the push or client message actions. Cannot save an email action if no templates exist. | | Custom emails | Yes when action is *Send email to list* | At least one email; entered as chips. | | Account recipients | Yes for the two organization-account actions | At least one organization account; entered as chips. | | Notification title | Yes when action is *Send push notification* | Supports booking template variables. | | Notification body | No | Optional; supports template variables; saved empty if left blank. | | Tap action | Yes when action is *Send push notification* | *Open booking #ID* (default), *Open client #ID*, or *Open booking list*. | | Provider | Yes when action is *Send message to client* | A messaging provider your organization has actively connected on the [Communications](/requiply-docs/knowledge/settings/integrations/communications.md) page. | | Channel | Yes when action is *Send message to client* | *SMS*, *Viber*, *Viber, with SMS fallback*, or *Telegram* — limited to what the chosen provider supports. | | Message template | Yes when action is *Send message to client* | Picked from the [message templates](/requiply-docs/knowledge/settings/booking-settings/message-templates.md) compatible with the selected channel. Cannot save without one. | | Enabled | Yes | Toggle. Defaults to on for new workflows. | Switching the trigger type clears any fields that don't apply to the new type, so you can't accidentally save a status when the trigger is now *Booking created*. ## How this page connects to the rest of Requiply | Feature | How Workflows affects it | | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Bookings** | Every workflow runs against booking events — status changes, payment changes, creation, or time-relative reminders. | | **Booking statuses** | *Status reached* triggers and *Booking status* filters reference the statuses configured in your organization. Renaming a status updates the labels shown. | | **Payment statuses** | *Payment status reached* triggers fire when a booking's payment moves into the chosen state. | | **Email templates** | The three email actions each send a template you've already designed. If templates are missing, you cannot save an email workflow. | | **Clients** | *Send email* delivers to the booking's client automatically, and client fields (name, email, phone, pricing discount, Telegram connected) are available as filters. Client message attempts are logged on the client's [details page](/requiply-docs/knowledge/clients/client-details.md). | | **Organization accounts** | *Send email to organization accounts* and *Send push notification* deliver to your own team members' accounts. | | **Communications integrations** | *Send message to client* delivers through the provider connected on the [Communications](/requiply-docs/knowledge/settings/integrations/communications.md) page. Without a connected provider, the action is unavailable. | | [**Message templates**](/requiply-docs/knowledge/settings/booking-settings/message-templates.md) | Supplies the body, attachments, and buttons of the client message action. A template that a workflow uses cannot be deleted until the workflow is repointed. | | **Mobile app** | Push notifications reach accounts that have the Requiply app installed; others are skipped. | | **Pricing discounts** | A client's pricing discount can be used as a filter (for example, "VIP clients only"). | | **Custom fields** | Any Booking-level or Client-level custom field you've configured becomes available as a filter. | | **External recipients** | *Send email to list* delivers to a fixed list of addresses you maintain on the workflow itself. | | **Email template editor** | The "no templates yet" panel links into the email template add screen and brings you back to the workflow form afterward. | ## Common scenarios ### Confirming new bookings automatically Create a workflow with trigger *Status reached → Confirmed*, action *Send email*, and pick your confirmation template. From now on, every booking that reaches *Confirmed* sends the client a confirmation message. ### Reminding clients before their appointment Use trigger *Relative time reached*, relative to *Booking start time*, direction *Before*, offset *1 day*. Pair it with a friendly reminder template. Requiply will send the reminder for every future booking without further work. ### Messaging a client a reminder over SMS, Viber, or Telegram First connect a provider on the [Communications](/requiply-docs/knowledge/settings/integrations/communications.md) page and write a [message template](/requiply-docs/knowledge/settings/booking-settings/message-templates.md) with the client name and booking time. Then use trigger *Relative time reached*, relative to *Booking start time*, direction *Before*, offset *1 day*, with action *Send message to client*, the channel your provider supports, and that template. Clients are reminded on their phones automatically. (Use *Booking created* instead for an instant confirmation, or *Payment status reached* for a payment follow-up with a payment link.) ### Sending Telegram only to clients who can receive it Add a filter on *Client · Telegram connected — Yes* to a Telegram workflow so it skips clients who never opened your bot. Pair it with a second workflow filtered on *No* that reaches the same clients over SMS, and everyone gets the notification on whatever channel they actually have. ### Notifying the assigned manager, not the client Use action *Send email to organization accounts* (or *Send push notification to organization accounts*) and pick the team members who should be alerted. Because these go to real Requiply accounts, they're better than a typed list when you want the message to reach specific people on your team — for example, ping the manager when a booking is confirmed. ### Only confirming high-value bookings Use trigger *Status reached → Confirmed*, then add a filter *Total cost — greater than — 500*. The confirmation only fires for bookings above that amount. ### Targeting VIP clients or a single location Add a filter on a client's *Pricing discount — is any of — …* to reach only your VIP tier, or filter on a Booking custom field (such as a location) to limit a workflow to one site. ### Combining AND and OR conditions For "weekend bookings **or** anything over $300", put two conditions in the **same group** (OR). For "weekend bookings **and** over $300", put each condition in its **own group** (AND). Always read the **"Only when"** preview before saving to confirm the logic. ### Chasing failed payments Use trigger *Payment status reached → Failed* (or your equivalent), action *Send email* to the client, and a template that explains how to retry payment. ### Pausing a workflow without losing it Open the workflow and turn off the **Enabled** switch. The workflow stays on the list — and keeps its full configuration — but stops firing until you turn it back on. Better than deleting if you only want a temporary pause. ## Tips and cautions {% hint style="success" %} **Tip:** Build your email templates first. The email actions will not let you save without picking a template, and the inline shortcut to create one returns you to the workflow you were building. {% endhint %} {% hint style="info" %} **Tip:** For relative-time reminders, double-check whether the offset should be *before* or *after* — a "1 day before booking start" reminder and a "1 day after booking end" follow-up are very different messages. {% endhint %} {% hint style="warning" %} **Heads up:** AND vs OR is easy to get wrong. Conditions in the **same group** are combined with **OR**; **separate groups** are combined with **AND**. Read the **"Only when"** preview before saving so the workflow runs on exactly the bookings you expect. {% endhint %} {% hint style="warning" %} **Heads up:** Empty filters mean the workflow always runs. Removing all conditions makes it fire on every matching trigger again — handy when you want it, surprising when you don't. {% endhint %} {% hint style="warning" %} **Heads up:** Filters fail closed. If a workflow's filter data can't be loaded for a booking, the workflow does not run for that booking. {% endhint %} {% hint style="warning" %} **Heads up:** Push notifications need the app. Organization accounts without the Requiply mobile app installed are silently skipped. {% endhint %} {% hint style="warning" %} **Heads up:** Deleting a workflow from the edit screen is immediate and permanent. If you only want to stop it temporarily, toggle **Enabled** off instead. {% endhint %} {% hint style="warning" %} **Heads up:** Changing the trigger type on an existing workflow clears the fields that no longer apply (for example, switching away from *Status reached* removes the selected status). Make sure the new trigger is fully filled in before saving. {% endhint %} {% hint style="warning" %} **Heads up:** *Send email* always goes to the booking's client, and is skipped if the booking has no client. To reach someone who isn't on the booking, use *Send email to list* (typed addresses) or *Send email to organization accounts* (your team) instead. {% endhint %} {% hint style="warning" %} **Heads up:** *Send message to client* needs a connected provider on the [Communications](/requiply-docs/knowledge/settings/integrations/communications.md) page, a compatible [message template](/requiply-docs/knowledge/settings/booking-settings/message-templates.md), and a reachable client — a phone number for SMS/Viber, or a connected Telegram chat for Telegram. Bookings without a client are skipped; everything else is attempted and logged on the client's **Messaging** card with the failure reason. {% endhint %} {% hint style="warning" %} **Heads up:** Relative-time workflows do not fire retroactively. If a booking is created (or updated to match the trigger) after the configured offset has already passed — for example, a "1 day before booking start" workflow on a booking that starts in 2 hours — the workflow is skipped for that booking rather than firing immediately. {% endhint %} {% hint style="warning" %} **Heads up:** Workflow runs are not surfaced to clients, and there is no client-facing log or retry view for failed sends. If a workflow email doesn't arrive, the client has no way to see that it was attempted — plan your communication so a missed automated email isn't the only signal a client gets. {% endhint %}