Automations — Help

Some things should happen like clockwork. A month before the wedding, invite the couple to book their final planning call. A week out, send the arrival and parking details. The day after, drop a thank-you and a feedback link. When a quote goes out, follow it up a few days later if you have not heard back. And in the background, spin up the checklist of jobs your team works through for every booking. These are the notes and tasks you always mean to handle and sometimes forget in the rush. An automation handles them for you, on a schedule or the moment something happens. You set it up once, and it quietly does the rest.

Automations have grown well beyond a single "email the client before the event" rule. This article covers the two halves of the Automations page (the system emails 1pm sends for you, and the automations you build yourself), the shape of a custom automation (a trigger and its actions), the triggers and actions on offer, the review queue that lets you check client emails before they go, and where replies land. New triggers and actions are added over time, so this focuses on how the pieces fit rather than listing every one exhaustively.

The two halves of the Automations page

Open Automations in the sidebar and you will see two groups:

System emails. The transactional emails 1pm already sends on your behalf: the crew invite, the quote and invoice and confirmation emails, the "booking confirmed" note, the crew request emails, and so on. These are always on. You do not switch them off, but you can rewrite the wording to sound like you, and reset any of them back to the original if you change your mind.
Your automations. The rules you build yourself. Each one is a trigger and the actions it runs. These start off, so nothing sends until you arm it, and you can turn them on and off, edit them, or delete them freely.

Below both groups sit Sending soon (client emails waiting in their review window) and Recent activity (what has already gone out). More on those further down.

System emails: editing what 1pm already sends

Every account gets a set of ready-made emails so the app is useful out of the box. They cover the moments that already send an email today: inviting a crew member or portal contact to their link, sending a quote, invoice or confirmation, confirming a booking after payment, emailing the invoice PDF when a client generates one to pay by bank transfer, thanking a crew member when they finish their requests, prompting someone to re-upload an expiring document, telling them an upload was rejected, and welcoming someone who self-registers.

Alongside those sit the onboarding chases and alerts: nine of them, all switched off until you turn them on, because nobody should start chasing people in your name, or filling your own inbox, without deciding to. Most carry a day count you set.

Each shows as a card in the System emails group. To change the wording, click Edit, rewrite the subject and body (the same editor and merge fields as any other email action, covered below), and save. Your version is used from then on. Changed your mind? Reset puts the original wording back, and removes any actions you added. It leaves your settings alone: a system email you switched on stays on, one you switched off stays off, and its day count and lead form filter stay as you set them.

A few things to know:

Most are always on. A system email tied to a real moment in the app (you send a quote, a crew member finishes their requests) has no on/off toggle and no delete, because the moment happens whether you like it or not. Editing the wording is the control you have. The four scheduled chases are the exception, below.
Some fill in extra details automatically. The document prompt drops in the file name and its expiry date. The upload-rejection email drops in your reason. The invite carries the crew member's private link. You position these with a merge field and 1pm fills the rest in when it sends.
The ones you send yourself carry only their own email. The quote, invoice and confirmation emails, the invites, and the emails tied to a crew member finishing, uploading or registering are sent at that moment and nothing else runs with them, so their editor has no Add action. Build your own automation for anything extra.
Which ones you see depends on your account. If your account does not use the Leads funnel, the quote/invoice/confirmation emails are hidden. If your account is portals-only, you see the portal invite rather than the event crew invite.

The nine opt-in onboarding emails

These are the exception to "always on", and they all start switched off. Turn one on and set its number of days when you are ready.

Six of them reach the crew member:

Outstanding requests reminder, a set number of days after you invited them, if their requests are still not done. Starts at 7 days, and it fires once per person.
Document expiring reminder, a set number of days before a dated document you hold runs out. Starts at 30 days.
Document expired reminder, a set number of days after it lapsed with nothing sent in to replace it. Starts at 7 days.
Rejected upload reminder, a set number of days after you rejected a file, if no replacement has arrived. Starts at 7 days, and it repeats your original reason so they do not have to go and find it.
Time to ask again, a set number of days after you approved a document that carries no expiry date, asking for a fresh copy. Starts at 365 days.
Document approved, their confirmation that a file you approved is now on record and good until whenever it runs out.

Three report to you rather than to them:

Invite not opened, a set number of days after the invite, if the link has never once been opened. Starts at 3 days.
Upload not reviewed, a set number of days after a file arrives, if you still have not approved or rejected it. Starts at 2 days.
Everyone has finished, the moment the last person on an event or portal finishes everything required, so you know the whole roster is cleared.

Three of the nine cover gaps the others genuinely cannot see, and are worth understanding properly.

Invite not opened is not the outstanding requests reminder. Both fire a few days after an invite, but they describe opposite problems. The reminder means "they opened it and stalled", which is a person to nudge. This one means "the email never landed at all", which is usually a wrong address or a spam folder, and a second email to an address that does not work is a letter to nobody. That is why it is addressed to you: check the address, fix it, and send again.

Upload not reviewed watches your queue, not theirs. It is the only one of the nine that fires on something you have not done. Nobody can finish while a file sits unreviewed, so a fortnight-old submission nobody has looked at is your bottleneck rather than theirs.

Time to ask again is for the documents with no date on them. The expiry reminders can only watch a file that says when it lapses. A police check, a site induction, a policy sign-off and a WHS refresher usually print no date at all, so nothing was ever watching them and they sat approved forever. This one counts from the day you approved the document instead, and it only ever fires on files with no expiry date, so a dated certificate is never chased twice on two different clocks. Approving the replacement they send starts the same count again, so it repeats on its own with no "repeat every" setting to configure.

The document ones run per document, not per person, so a crew member holding three dated certificates gets three independent chases. Replacing a file re-arms the ladder, because the replacement is a new upload. Between them, these nine are the difference between a compliance list you have to work by hand and one that works itself; Chasing expiring documents covers the manual side.

The Invoice generated email works a little differently too. It sends when a client confirming by bank transfer clicks "Generate an invoice", and it always attaches the invoice as a PDF so their accounts team has a file to work from. You can switch it on or off, and you can limit it to one lead type (so, say, only wedding leads get it), the same filter custom automations use.

The shape of a custom automation

Everything in the Your automations group is built from two parts:

A trigger is when it runs. You pick one.
One or more actions are what happens when it runs. You can stack several, and they run in the order you list them.

Read together they make a sentence: "X days before the event, send this email and create these tasks", or "when a quote is sent, wait three days, then email the client a nudge". Change the trigger and the timing shifts; change the actions and the outcome does. Everything else in this article hangs off that one idea.

An automation is a rule for your whole account, not something you set up event by event. Once it is on, it applies automatically to every event (or lead, or crew member, depending on the trigger) that matches.

Triggers: choosing when it runs

The trigger is the first thing you pick, from a short wizard grouped by what the trigger fires off. You will see the groups that apply to your account.

Events (tied to the event date). These are swept daily and only ever touch bookings you have committed to:

X days before the event, for the lead-up: reminders, prep, a pre-event chat. Confirmed bookings only, since an event already marked done has no future left to count down to. For a booking that runs over several days, this counts back from the first day.
X days after the event, for the wrap-up: thank-yous, feedback requests, follow-up jobs. Confirmed or completed bookings, so marking a finished event Completed does not stop its follow-up running. That matters most for the long ones: "a year on, shall we do it again?" can only ever run against an event that finished long ago. For a booking that runs over several days, this counts from the last day, so on a Friday to Sunday booking, an automation set to 1 day after sends on Monday.

Type the number of days into the sentence that follows. Use 0 to land on the event day itself.

A date based automation matches one calendar date, so a booking taken inside its own lead time can never receive it. Any of these emails can be sent by hand for a single booking instead: see when an automation email doesn't send.

Leads (tied to a lead moving through your pipeline). These fire the instant it happens, straight to the lead, with no review hold:

Lead received, the moment a new lead is captured. Paired with the lead-type filter (below), this is what kicks off a form-specific welcome or nurture sequence.
Quote sent, Quote opened, Quote accepted, Agreement signed, and Booking confirmed, each firing as the lead crosses that step. Use these for a timely nudge, a thank-you, or an internal heads-up.

Five more watch for a step the lead has not taken, a set number of days after the step before it. These are swept daily and carry a day count you type into the sentence beneath them:

Quote not opened, a set number of days after a quote is sent, if the client still has not opened it.
Quote not accepted, a set number of days after a quote is sent, if they still have not accepted it.
Accepted, not signed, a set number of days after they accept, if they still have not signed the agreement.
Signed, no payment, a set number of days after they sign the agreement, if no payment has come in.
Accepted, no payment, a set number of days after they accept, if no payment has come in. This one spans both of the steps above, so it cannot tell you which of them a client stopped at. Reach for the pair when you want an email that names the step.

Each fires once per lead and stops as soon as they take the step you were waiting on. Leads you have marked lost or spam are never chased, and neither is a lead whose booking you have cancelled. Chasing a lead that goes quiet covers them in detail, including what to write in them.

Requests (tied to onboarding, on an event or a portal). Twelve of them, and they are the family that has grown most. Most fire off a specific crew member, so their emails and merge fields are personalised to that person.

Five fire the instant they happen:

Someone is added, the moment you put a person on an event or portal, which in 1pm means the moment their private link is created. This is the one to pair with a Send their invite action, below.
Requests completed, when a crew member finishes everything you asked them for.
Self-registration, when someone joins via a self-registration link or QR code.
Document approved, when you approve one of their uploads.
Everyone has finished, when the last person outstanding on that event or portal finishes, so the whole roster is clear. This one is about a group rather than a person, so it offers the internal emails and task creation only.

Seven are swept daily and carry a day count you type into the sentence beneath them:

Requests not completed, a set number of days after their invite if their requests are still outstanding. It fires once per person, and stops if they finish partway through.
Invite not opened, a set number of days after the invite, if the link has never been opened.
Upload not reviewed, a set number of days after a file arrives, if nobody has approved or rejected it.
Document expiring, a set number of days before a dated document you hold for them runs out.
Document expired, a set number of days after it lapsed, if nothing has replaced it.
Rejected upload not replaced, a set number of days after you rejected a file, if they still have not sent a new one. Stacking two or three of these at 7, 14 and 21 days is the intended way to build an escalating chase.
Time to ask again, a set number of days after you approved a document that carries no expiry date.

Two of the twelve are about you rather than the person, which changes what you can do with them. Invite not opened means the email never landed, so it is your address book that needs fixing rather than their memory. Upload not reviewed watches your own approval queue, and it deliberately will not let you add a "Send crew email" action at all: "we still have not looked at your file" is not a sentence to send the person waiting on it.

When a rule stops is decided per trigger rather than by one blanket rule. The outstanding-requests chase stops the moment they finish, so somebody who completes on day three never gets the day-five chase. The never-opened alert stops the moment they open the link, whether or not they have done anything yet. The document ones stop as soon as the file is replaced, parked, or decided, and the ones that email the crew member also stop when you archive the request. All of them stop if the person is taken off the event.

How often one fires. Once per person for the triggers keyed to a person, once per document for the ones keyed to a document. That is why you build a ladder by stacking automations rather than setting a repeat: chase at 30 days, again at 7, again a week after it lapses, is three automations on three triggers.

The built-in system email for these moments still sends. A custom Requests automation is additive: it lets you layer on your own drip, task creation, or an internal notification.

Invoices and payments (tied to a document rather than an event or a lead). These address the invoice's bill-to contact, which is what lets them work on a from-scratch invoice with no event behind it. They send immediately, with no review hold, because a reminder that an invoice falls due tomorrow is wrong by the time a day's hold expires:

Payment received, any time a payment is recorded against an invoice or a confirmation.
Paid in full, when a payment settles the whole balance. It fires in addition to Payment received, so if you have both wired up, write the two so they read sensibly one after the other.

When you record a payment yourself, the Record payment form has an Email the client about this payment checkbox. Untick it for a payment that arrived a while ago and none of these automations, nor Booking confirmed, emails the client about it. Emails to you and task actions still run.

Invoice due soon, a set number of days before an invoice falls due, if it is still owing.
Invoice overdue, a set number of days after it fell due, if it is still owing.
Quote running out, a set number of days before a quote's "Valid until" date, if it has not been accepted.
Quote ran out, a set number of days after it lapsed, if it still has not been accepted.

The last two are grouped here rather than with the lead triggers because they fire off a document and email its bill-to contact, like the rest of this family. Each fires once per quote and stops as soon as it is accepted, declined or put back to draft. See when a quote runs out for the validity date they read, and what a lapsed quote looks like to the client.

Appointments (tied to a booking's start time). One trigger, X minutes before an appointment, sends a reminder to either the Space contact or the client who booked, a set time before the appointment. Because it needs to know exactly when each appointment starts, it only works once you have set your calendar time zone, and it only fires for booked appointments.

Appointments (when a client does something). Three more, and they fire the moment it happens rather than on a schedule: when a client books an appointment, when a client moves one, and when a client cancels one. They run off the public booking page and the manage link in the client's confirmation, so an appointment you add yourself never triggers them.

These three come switched on, addressed to you, with the appointment attached as a calendar file. That attachment is the point of them: a booking that arrives as an email invite lands in your own calendar in one tap, instead of waiting for a subscribed feed to poll. A cancellation sends the matching update, so the slot clears out of your calendar too. They are ordinary automations, so you can rewrite the wording, point them at the Space contact or an address you type instead, or switch them off. If the Space has no contact with an email address, Recent activity shows the notice as Failed with that reason. There is no client recipient on these, because 1pm already sends the client their own confirmation, reschedule and cancellation notice. Moving the same appointment twice notifies you twice; submitting the same booking twice does not.

We add new triggers over time, so you may see more choices than these. Whichever you pick, the rest of the setup works the same way.

Running an automation for one lead type only

The event and lead triggers can be scoped to a single lead type with the Only for this lead type picker. Leave it on "Any" to run for every lead, or pick one to give that form its own workflow: a wedding lead can kick off an entirely different sequence than a general event lead. On a date-based schedule, this matches the lead type the event's original lead came in on.

Actions: choosing what happens

Actions are what the automation actually does when its trigger fires. Add one with Add action, pick its type, and fill in its details. Add more than one and they run top to bottom, so order them the way you want them to happen. Drag to reorder, and each action has a Remove control.

The actions available (which ones you can pick depends on the trigger):

Send client email. Emails the event's client contact. Every client email waits in a 24-hour review queue before it sends, so you always get a last look. More on that queue further down.
Send crew email. On a Requests automation, emails the crew member the automation fired off, personalised to them and carrying their private link. Use it for a thank-you, a welcome, or a chase. Not offered on Upload not reviewed, for the reason above.
Send their invite. On a Requests automation, sends that person the invite exactly as the Send button does, using your saved Crew invite or Portal invite wording. It carries no subject or body of its own, deliberately: the wording already has one home, on the invite card in System emails, and two places to edit it is how the two drift apart. Pair it with Someone is added and onboarding somebody becomes a single act. It is skipped, with the reason recorded, if they have no email address, if an invite went out in the last five minutes, or if your email allowance is used up. One automatic invite per person per event, ever, so removing somebody and adding them back does not invite them twice.
Give them a section. On a Requests automation, adds that person to the cohort of a conditional section, so the requests inside it appear on their link. Name the section by its title (the field offers the ones you already have), and the rule matches it on whichever event it fired for, which is what lets one rule work across every portal instead of being pinned to a single one. It only ever touches sections you have already limited to named people. A section anybody can see is left alone, because adding one person would hide it from everyone else, and the run says so in Recent activity rather than doing it quietly.
Set their status. On a Requests automation, moves that person's crew status on the event the rule fired for: Inducted, Docs verified, Cleared to work, or whatever your account has defined. It changes the status and records it in their status history, and it does nothing else. It does not email them: if they should be told, add a Send crew email action after it, so the wording sits in the automation where you can see it rather than hidden in a settings screen. Nothing happens if they already hold that status.
Send organizer email. Emails the event's organizer contact rather than the client. Set the organizer on the event itself (the Organizer picker sits next to the Client one). It stays in-house, so it sends straight away with no review queue.
Send account email. Emails the account owner (your own login email). Use it for internal heads-ups to yourself, for example "a booking just confirmed" or "chase the final numbers". Sends straight away, no review queue.
Email an address. Emails an address you type in. This is the one recipient that is not somebody 1pm already knows about, which is exactly the point: compliance sits on a shared inbox, a site has a manager who is not a user here, and the address that should act on "this certificate lapses in 30 days" is rarely the account owner's login. It is a full email action, so it takes the same merge fields, attachments, Preview and Send test as the rest, and it works on every trigger the account email does. Two things to know. It sends straight away, with no review hold. And unlike the organizer and account emails, it counts against your daily email limit and your monthly email allowance, on every trigger, because it is the only internal recipient that can reach anybody at all. When either limit is used up, nothing is sent and the reason shows in Recent activity or in Emails.
Remind the Space contact / Remind the client. On an appointment automation, emails the Space's contact or the client who booked, ahead of the appointment. On the three booked, moved and cancelled triggers the Space contact option is there too, sending the moment it happens rather than ahead of time; the client option is not, since the client already gets their own confirmation.
Send bill-to email. On an invoices and payments automation, emails the invoice's bill-to contact: a receipt, a due-date warning, an overdue chase. Sends straight away, no review queue.
Create planner tasks. Turns one of your saved workflows into work on the event: its steps become a single task named after the workflow, with a step for each item, for your team to tick off. Created right away, no review step. Workflows live on the Tasks page, and editing one there applies to future runs.
Wait. A pause, not a send. Drop a Wait between two actions and everything below it is delayed by that long, so you can build a drip: "email now, wait three days, email again". Set the pause as a number plus a unit (minutes, hours, or days), though on a date-based schedule, which is swept once a day, a wait is rounded to whole days. This is what turns a trigger that fires instantly, like Quote sent, into a spaced-out sequence.

One automation holds up to 20 actions, which is more sequence than most drips need.

As with triggers, the list of actions grows, so you may see more types than these. Each one explains itself as you add it.

Writing an email action

When an action sends an email, you are writing a short message: a Subject and an Email body.

Merge fields personalise each email. Click into the subject or body first, then click a field to drop it in. They fill from the client and event (or the crew member, for a Requests automation) when the email goes out, for example the person's name, the company or couple name, the event name and date, and the guest count. A crew email also offers the crew member's private link. Anything you do not recognise is left exactly as typed.

The body also takes light formatting: wrap a phrase in *asterisks* for bold, and use Link to add a button or link (handy for pasting your booking-page link so clients can grab a slot).

Attach a file to an email action with Attach, which opens your Files library. Attachments come from the library rather than an upload here, because an automation fires indefinitely and the file has to keep existing: an induction pack, a site map, a menu. When the document is reissued, use Replace file on it in Files and every automation attaching it sends the new edition from its next run. Attaching the same file twice does nothing.

Two buttons help you check an email before you commit:

Preview renders the email against a sample contact and event, so you see the merge fields filled in. The To line shows where that action really sends: the sample client for a client email, your account address for an account email, and the address you typed for Email an address. On an "after the event" rule, the sample event is dated in the past.
Send test to me emails the finished version to your own address, subject-tagged as a test, so you can read it in a real inbox. If you work in someone else's account, the test comes to you, not to the account owner.

Setting one up

In the Your automations group, click New automation. Give it a Name for your own reference (for example "Pre-wedding consultation invite"), pick a trigger and its timing, then add the actions you want. The Active (running) toggle arms it; new automations start off, so you can check the wording and preview an email before switching it on.

Save with Create automation. Back on the list, each automation shows an On or Off badge and a one-line summary, with Turn off / Turn on, Edit, and Delete to hand. Deleting keeps anything it already did (emails sent, tasks created) in place.

Checking it will actually do something

Before you switch a rule on, ask it. Each action carries a Show upcoming button beside Preview and Send test to me, and it lists what that action will really do over the next 30 days against your actual bookings: the date the client receives it, which booking it lands on, and beside anything that will not run, why not. Under the list, a Not listed summary counts the bookings that fell in the window and were filtered out, which is usually where the answer is hiding (they are still Tentative, or they came in on a different lead type).

It works on an automation you have not saved yet, so you can adjust the rule before it exists. Checking an automation will actually fire covers the whole panel, including what the blocked rows mean and why an edge trigger cannot be forecast.

The "Sending soon" review queue

The client email does not send the instant an event qualifies. This is the safety net worth understanding, and it applies to the client email only. The crew, organizer, and account emails, appointment reminders, and task creation all happen immediately.

When an automation's client email matches an event, 1pm prepares the email (recipient, subject, and body all filled in) and parks it in a Sending soon queue for 24 hours before it actually sends. That section sits on the Automations page, listing every pending email with when it will go, which automation and event it is for, who it is to, and its subject. The address shown is the one the email will actually go to: for a booking that came from a lead, that is the lead's email.

When anything is waiting there, an orange badge with the count appears twice: on Automations in the sidebar, so you know to look, and beside the Sending soon heading itself, so you can see what the number was counting once you arrive. Neither shows at zero.

The point of the hold is simple: what you see there is exactly what will be sent, and you have a full day to catch anything you would rather did not go. If an email looks wrong, or the situation has changed, click Cancel on its row. You are asked to confirm, and once cancelled that email will not send, and the automation will not try to queue it again for that event on that date.

The email is a frozen snapshot taken when it was queued, so editing the automation afterwards does not change one already waiting in the queue. The timing is worked out so the email still lands the right number of days from the event, review window included.

A client email runs once per event date, not once per event for good:

Moving a booking while its email waits cancels the queued copy, because the snapshot still quotes the old date. When the automation reaches the new date, it queues the email again.
Moving a booking after its email went out means the automation sends it again for the new date, as long as that send day is still ahead.
Sending the same email by hand while it waits (with Send automation on the client contact's Bookings tab) cancels the queued copy, so the client gets it once.

Below the queue, a Recent activity history shows what has gone out, each marked Sent (or Done, for tasks created) or, if something went wrong, Failed with the reason. Nothing retries silently, so a failure is always visible rather than lost. Invoice, payment and quote automations appear here too, alongside the event and lead ones.

Two markings worth recognising on that list:

Failed with a reason instead of a recipient. When an event has no client contact, or that contact has no email address, there is nobody to send to. The row says so rather than claiming it emailed the client, and the bell rings once with a link to the event.
Sent by hand. A badge on emails a planner dispatched from a booking rather than the schedule firing. Without it, a "14 days before" automation showing a send from today would read as a misfire.
Cancelled with a reason. 1pm cancelled a queued copy because the booking moved or the same email was sent by hand. The reason sits where the recipient normally is. An email you cancel yourself in Sending soon is not listed.

When an automation email doesn't send covers both, and the button that sends one by hand.

Where replies go

A client email is sent as part of the event's Leads conversation, from your account reply address. So when the client hits reply, their message threads straight back into your Leads inbox, alongside everything else you have said to them. You are not starting a separate conversation that lives in some other inbox, it is all in one place.

If the event came from a lead, it already has that thread. If you created the event directly (typed it in, or imported it), 1pm quietly sets up a matching lead for the client so the reply has a home. That lead shows under the Converted tab in Leads.

Turning it off

For a custom automation, there are two levels of control. To stop it running at all, Turn off the automation (or flip its Active (running) toggle). To stop one specific client email that is already lined up, Cancel it in the Sending soon queue. Turning an automation off stops it everywhere: nothing new gets queued, any of its emails waiting in Sending soon are cancelled, and any later steps still waiting out a Wait do not run. Turning it back on applies to what happens from then on; the cancelled emails stay cancelled.

System emails are the exception: they cannot be turned off, because they are tied to something you did in the app. If you do not want the wording to say anything at all, keep it to a minimal, neutral message, or reset it to the original.

Onboarding that runs itself is the recipe book for the twelve Requests triggers and the actions that invite, pack, chase and clear somebody without you touching it.
The weekly summary email is the once-a-week digest of everything still waiting on you, which is a different shape from a trigger and lives in its own settings screen.
Chasing a lead that goes quiet covers the funnel stall triggers in detail.
When a quote runs out covers the quote validity date and the two chases that hang off it.
When an automation email doesn't send covers the usual causes, and sending one by hand.
Tasks and checklists is your own private to-do list, and the source of the checklists a "Create planner tasks" action turns into work on an event.
Replying to leads covers the Leads thread that automation email replies land in.
Capturing leads with a form covers the lead types the "Lead received" trigger and the lead-type filter work off.
Event confirmations covers getting an event to confirmed, the point at which the date-based automations start running against it.
Asking crew for documents and info covers the requests a crew member completes, which the Requests triggers fire off.
Appointments and the booking page covers the appointments an appointment-reminder automation runs against, and the booking link you might send from an email action.