> For the complete documentation index, see [llms.txt](https://docs.rubica.au/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rubica.au/workflow-automation/workflow-triggers-creating-a-trigger.md). # Workflow Triggers — Creating a Trigger Creating a new Job automatically from an Account event, before you add any conditions. A **Workflow Trigger** watches every Account in the org for a particular event, and creates a brand-new Job (from this template) when the timing hits — e.g. "14 days before OFA Reference Date, start the Review Workflow". This is different from a Stage Action, which automates things *inside* a Job that already exists. A Workflow Trigger can also react to something happening **outside Salesforce entirely** — a Calendly booking today, with Payment and Form Submission also available as Triggering Object types. See [External Event Triggers (Calendly, Payment, Form Submission)](#external-event-triggers-calendly-payment-form-submission) below. This page covers the base fields. To also restrict *which* Accounts it applies to, see Setting Conditions on a Workflow Trigger. ## Where to find it **Home → Settings → Workflow Templates →** pick a template **→ Workflow Triggers** tab **→ + Add Trigger**. ## Fields | Field | Notes | | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | **Triggering Object** *(required)* | The record type to watch — Account, Household Account, Person Account, Entity (Business) Account, Opportunity, Lead, and a few others. | | **Trigger Event** *(required)* | What date/event on that record to measure from — e.g. Next Review Date, OFA Reference Date, Record Created, Closed Won. | | **Delay Days** | How many days before/after the event to actually create the Job. `0` = create it right when the event happens. | | **Delay Type** | Days Before / Days After. | Save, and the trigger runs automatically — the engine sweeps for due triggers **every hour**, so a newly-due trigger is picked up within the hour, not the next day (assuming your org's admin has confirmed the underlying automation is switched on, see Admin & Troubleshooting). ## What happens when it fires A new Job is created from this template, starting at its first stage, linked to the Account that matched. Everything after that follows the normal Stages / Stage Actions behaviour — the trigger's only job is deciding *whether and when* to create the Job in the first place. ## External Event Triggers (Calendly, Payment, Form Submission) Instead of an Account/date-based object, **Triggering Object** can also be set to an external event type — **Calendly**, **Payment**, or **Form Submission**. These react in real time to something happening outside Salesforce, rather than being swept hourly like a date-based trigger. For a **Calendly** trigger, the modal replaces the date fields above with: | Field | Notes | | ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Meeting Title** *(required unless "Any Event")* | Matches against the Calendly event type's name. Operator is **Contains** (case-insensitive), **Exact**, or **Any Event** (matches every Calendly booking, regardless of title, and hides the text box). | | **Start this workflow if the client has no open job** | Checkbox. If the booker already matches a client who has no currently-open Job from this template, ticking this creates a new Job anyway. Left unticked, a client with no open Job is simply skipped. | | **If No Client Match Found** | What to do when the booking's invitee doesn't match any existing client: **Do Nothing** (booking is recorded but ignored), **Create Lead** (creates a Lead only — someone converts it manually later), or **Create Household & Launch Workflow** (creates a new Household/Person Account directly and starts this Job against it). | | **Assign New Clients To** *(Create Lead / Create Household only)* | Who owns the new client: **The Calendly host** (the person they booked with) or **A specific person**. See [Who owns a new client from Calendly](#who-owns-a-new-client-from-calendly). | | **Assign to** / **If the host isn't a Salesforce user, assign to** *(required)* | The specific person, or — for the Calendly host option — the person a new client goes to when the host can't be matched to a Salesforce user. | | **Pod** *(specific person + Create Household only)* | The pod the new household joins. Leave it on **Their own pod** to use the chosen person's pod. | The same settings appear when you edit a Calendly trigger from the **Automation** tab. ### Who owns a new client from Calendly When a booking doesn't match an existing client and the trigger creates one, the new **Lead**, **Household**, the client's own **account** and the **first Job** all go to one person: * **The Calendly host** — rubica looks up who the client booked with in Calendly and matches them to a Salesforce user by email. If several people host the event, the first one who is a Salesforce user owns it. If none of them is, the client goes to the backup person you chose. * **A specific person** — always that person, whoever ran the meeting. There's no option to leave a new client unassigned, so they never end up owned by the integration user (e.g. Rubica Support). With **Create Household & Launch Workflow**, the new household also **joins a pod, and the pod's team is added to it**: * With the Calendly host, it's the host's own pod — the pod they lead, or failing that one they're a member of. * With a specific person, it's the pod you choose, or their own pod if you leave it on **Their own pod**. The pod is set on the household by its division (Financial Planning, Accounting or Lending), and each pod member is added to the household team in their default role. If the owner isn't in any pod, the household is created without a pod and team — add them from the household as usual. To check what happened to a booking, open its **Calendly Booking Event**: the **Outcome** says who the new client was assigned to (and whether the host matched or the backup person was used) and which pod the household joined. {% hint style="info" %} Triggers set up before this option existed keep their old behaviour (the new client stays with the integration user) until someone opens the trigger and saves it — the builder then asks for a person. {% endhint %} {% hint style="warning" %} A Calendly trigger only fires on a **real Calendly booking webhook reaching Salesforce** — it does nothing retroactively for bookings that already happened before the trigger (or the org's Calendly integration) was turned on. If a firm's Calendly bookings aren't creating Jobs/Leads/Households as expected, check with an admin that the org's Calendly integration itself is switched on (a separate, org-wide setting) before assuming the trigger is misconfigured — see Admin & Troubleshooting. {% endhint %} ## See also * Setting Conditions on a Workflow Trigger — narrow down which Accounts this actually applies to * Building Job Stages