--- title: "How do I use Trigger nodes in Orchestrator?" source_url: https://help.chilipiper.com/hc/en-us/articles/53506115976083-How-do-I-use-Trigger-nodes-in-Orchestrator article_id: 53506115976083 updated_at: 2026-07-16T17:30:23Z --- ## Who can use this feature? Available on Orchestrator Available to Admins Workspace Managers [Billing Center](https://fire.chilipiper.com/fire/admin/billing/overview) [Get a Demo](https://www.chilipiper.com/request-demo?utm_source=zendesk&utm_medium=help-center&utm_campaign=chili-hub) In this article, we will learn more about Trigger nodes and how to set them up in Orchestrator, ensuring your Flows start at exactly the right moment, every time. * * * #### Table of Contents * Configuring the Trigger Node * Trigger Types * Running the Flow: Always vs. On Condition Met * Cheat Sheet: Important Fields by Trigger * Finding IDs to Filter On * Example Use Cases * Good to Know * * * ## What is the Trigger node? A Trigger node is the event that starts a Flow. It answers the question of when an automation should run, which is why it is always the first node on a Flow. For now, most Triggers are Chili Piper events that Orchestrator sees natively, since Chili Piper owns the meeting and form data through Concierge. On top of defining when a Flow starts, the Trigger node also defines what data is available throughout the Flow. Each Trigger has its own set of fields that can be used in conditions and later steps. For example, Form Abandoned and Meeting Not Scheduled expose whether the prospect is marked as spam by the Spam Checker, and Meeting Triggers expose meeting-related data such as Primary Guest, Booker, and Host. The Trigger node is always the first node on a Flow, and it does not need to be added manually. To configure it, set **Flow will Start** to the event that should begin the Flow. * * * ## Trigger Types ### Form Triggers Form Triggers are related exclusively to forms tied to Concierge Flows. ![](https://help.chilipiper.com/hc/article_attachments/53506477457811) #### Form Abandoned This Trigger activates when someone fills out a form but does not submit it. > **Note:** If your Concierge Flow includes Spam Checker, add a Condition on Trigger that sets **Is Spam = False** , to make sure the Flow only triggers for relevant prospects. **Enable it:** Unlike other Triggers, Form Abandoned must be turned on. Go to **Command Center > Integrations > Preferences > Pre-submission Logging**. **Good to Know:** * Works exclusively with forms that have the Concierge Snippet embedded. #### Meeting Not Scheduled This Trigger activates when someone submits a form, presents a calendar, but does not schedule a meeting. It can be thought of as the not-scheduled path of Concierge. ![](https://help.chilipiper.com/hc/article_attachments/53506465663891) **Good to Know** * Works exclusively with forms tied to Concierge Flows; * Orchestrator cannot yet differentiate between different non-scheduled paths of a Flow. * * * ### Meeting Triggers Meeting Triggers are related to any meeting that happens in Chili Piper. These Triggers are cross-product, though they can be scoped to a specific Flow or user with Conditions on Trigger. _![](https://help.chilipiper.com/hc/article_attachments/53506465666579)_ #### Meeting Booked This Trigger fires whenever a meeting is booked or scheduled in Chili Piper. #### Meeting Cancelled This Trigger fires when a booked meeting is removed from the calendar before it happens. The meeting existed, and now it does not, which is what starts the Flow. A meeting counts as canceled when: * A prospect clicks the **Cancel URL** in their confirmation email; * A rep or admin cancels the meeting from Chili Piper; * A Chili Piper user deletes or cancels the event in the connected calendar (Google or Outlook). This refers to the rep's calendar, not the prospect's; * A Salesforce **Cancel** button points to the cancel link. **Good to Know** * Orchestrator does not indicate who canceled the meeting or how. When this Trigger fires, the Flow receives the meeting details and the host, but not whether the prospect backed out or the rep cleared their own calendar. Support for this distinction is not yet available. #### Meeting Rescheduled This Trigger fires when a booked meeting moves to a new time. The meeting still exists; it has only shifted, and that change starts the Flow. A meeting counts as rescheduled when: * A prospect clicks the **Reschedule** link in their email and picks a new slot; * A rep reschedules from the dashboard (ChiliCal Home); * The rep moves the event to a new time in the connected calendar (Google or Outlook). #### Meeting Reassigned This Trigger fires the moment a meeting that is already booked changes hosts. The rep originally assigned to run the meeting is replaced by someone else, and that switch is what starts the Flow. This Trigger is about the host of an existing meeting changing, not a new booking. For example, an admin manually moves a meeting from one rep to another. > **Note:** When a meeting is rescheduled and reassigned in the same action, only the Meeting Reassigned Trigger fires. Meeting Rescheduled does not fire in that case, so a Flow that listens only for Meeting Rescheduled will not run. > > This happens because Meeting Reassigned and Meeting Rescheduled are synthetic events. Concierge tells Orchestrator only that a meeting was "updated," and Orchestrator infers what changed and fires the Trigger that best matches. When the host and the time change together, it resolves to Meeting Reassigned. > > **What to do:** If a Flow must react to that combined case, trigger on Meeting Reassigned and read the new time from the meeting data, rather than relying on Meeting Rescheduled. #### Meeting Marked as No-Show This Trigger fires when a meeting that was supposed to happen is flagged because the prospect did not attend. The meeting was not canceled or moved; it happened without the prospect, and that is what starts the Flow. **Good to Know:** * Automatic no-show detection is not yet available. * * * ### Webhooks This Trigger starts a Flow when an outside system sends data to Chili Piper. Instead of waiting for a meeting event, the Flow waits for a signal from another system. This Trigger Type is configured in the Trigger node by setting **Flow will Start** to **On Incoming Webhook**. **What is a webhook?** A webhook is a URL that listens. That URL is given to another tool, and whenever something happens in that tool, it sends a package of data to the URL. The "ring" is an HTTP POST request, and the package is JSON, a structured blob of data. **How to set it up** Setting a webhook Flow in Chili Piper requires an external system that can send HTTP POST requests. 1. Set **Flow will Start** to **On Incoming Webhook**. ![](https://help.chilipiper.com/hc/article_attachments/53506477461779) 2. Copy the provided URL and paste it into the external system. ![](https://help.chilipiper.com/hc/article_attachments/53506477462675) 3. Add an Auth Token and paste it into the external system. This step is optional but recommended; without it, the webhook URL accepts requests from anyone who has the URL. 4. Define the data structure the external system will send to Chili Piper. **Good to Know** * Without an Auth Token, the webhook URL accepts requests from any system that has the URL. * * * ## Running the Flow: Always vs. On Condition Met ![](https://help.chilipiper.com/hc/article_attachments/53506477463955) When setting a Trigger, the Flow can run **Always** or **On Condition Met**. Most Flows are set to run on Condition Met. * **Always:** the Flow runs every time the event fires; * **On Condition Met:** the Flow runs only when the event fires and a condition is true. A condition is a rule built against the data available at the Trigger, such as field values from the meeting. For example: * Meeting Booked, but only if the meeting type is "Demo"; * Form Submitted and meeting not booked, but only from a specific Concierge Flow; * Meeting Booked, but only from a specific meeting type and a specific product. Setting conditions on the Trigger keeps Flows focused. Instead of one Flow firing on every event and branching internally, the Trigger itself screens out events that do not matter, resulting in cleaner Flows with less noise. ### About Logs When an event fires but its condition is not met, the Flow does not run, but it does not disappear from view either. It appears in Logs as **Skipped** , so anyone troubleshooting why a Flow did not act can see that the Flow was evaluated and chose not to run, rather than being left to guess. With Always, every fire runs and shows as Successful or Errored; with On Condition Met, fires that do not pass the condition show as Skipped. * * * ## Cheat Sheet: Important Fields by Trigger Trigger | Field | Why is it relevant? ---|---|--- Form Triggers | Router Id | Scopes the Flow to trigger only when a form is abandoned or submitted-but-not-scheduled in specific Concierge Flows, rather than every Concierge Flow in the workspace. IDs currently must be copied and pasted manually; a picklist is not yet available. Form Triggers | Spam Check | Scopes the Flow to trigger only when a prospect is, or is not, marked as spam by the Spam Checker. This works only when Spam Checker is present in the Concierge Flow. Meeting Triggers | Meeting Type > Id | Filters to specific Meeting Types. IDs currently must be copied and pasted manually; a picklist is not yet available. Meeting Triggers | Meeting Type > Name | Filters to Meeting Types by name — for example, triggering the Flow only when the meeting type contains the word "Demo." Meeting Triggers | Scheduled Info > Product | Filters to meetings happening through a specific product, such as Concierge or Handoff, from a fixed picklist. Meeting Triggers | Scheduled Info > Resource Id | Filters to specific Routers or Flows. IDs currently must be copied and pasted manually; a picklist is not yet available. ![](https://help.chilipiper.com/hc/article_attachments/53506465670675) * * * ## Finding IDs to Filter On A picklist for Flow ID or Meeting Type ID is not currently available; copy these values from the URL instead. The Router Id field on Form Triggers identifies a specific Concierge Flow and is found the same way as the Flow ID below. #### Flow ID ![](https://help.chilipiper.com/hc/article_attachments/53506465671315)![](https://help.chilipiper.com/hc/article_attachments/53506465671955) #### Meeting Type ID ![](https://help.chilipiper.com/hc/article_attachments/53506465672467)![](https://help.chilipiper.com/hc/article_attachments/53506465672851) * * * ## Example Use Cases * **Form Abandoned:** match the abandoned form to a Lead or Contact, and if a match and an owner are found, alert the owner; * **Meeting Not Scheduled:** alert the owner and add the prospect to a cadence in SalesLoft, Outreach, or Gong Engage; * **Meeting Booked:** create a Deal in HubSpot when a meeting is booked from a specific meeting type; * **Meeting Canceled:** re-engage the prospect through a sequencing tool after the cancellation; * **Meeting Reassigned:** trigger on Meeting Reassigned, rather than Meeting Rescheduled, to correctly capture the new meeting time when a meeting is rescheduled and reassigned in the same action. * * * ## Good to Know * **Form Abandoned** works exclusively with forms that have the Concierge Snippet embedded, and must be enabled under Command Center > Integrations > Preferences > Pre-submission Logging; * **Meeting Not Scheduled** works exclusively with forms tied to Concierge Flows, and cannot yet differentiate between different non-scheduled paths of a Flow; * **Meeting Canceled** does not indicate who canceled the meeting or how; support for this distinction is not yet available; * When a meeting is rescheduled and reassigned in the same action, only **Meeting Reassigned** fires; **Meeting Rescheduled** does not fire in that case; * **Meeting Marked as No-Show** does not yet support automatic no-show detection; * **Spam Check on Form Triggers** works only when Spam Checker is present in the Concierge Flow; * **Router Id, Meeting Type Id, and Scheduled Info > Resource Id** must currently be copied and pasted manually; a picklist is not yet available for any of these fields; * A **webhook** URL without an Auth Token accepts requests from any system that has the URL; * * *