Publishing an automator

Changes you make in the builder are only a draft until you publish them. This article covers checking your work, previewing it, publishing, and setting what starts the automator running.

Fixing validation problems

A banner below the toolbar shows a running count of errors and warnings (for example 2 errors · 1 warning) whenever something's wrong. Select it to expand the list; select an individual issue to jump straight to the step it's about. Publish stays disabled — with a tooltip explaining how many errors are blocking it — until every error is fixed. Warnings don't block publishing.

Each message is written in plain language and names the step it's about — never an internal id. If an issue has a Details link next to it, selecting it shows the original, more technical message underneath, in case you need it for a support conversation.

Previewing with a real deal

Select Preview and pick a deal to dry-run the automator against it — nothing is actually started or changed. The step list highlights the exact path that deal would take, with a bar at the top reading Previewing with the deal's address, or an explanation if the deal wouldn't actually qualify to run this automator at all. Any warnings along that path (a missing field, an unresolved recipient) list out in full rather than just a count. An Email or Text step shows who it would send from. If nobody would — the step sends from the Home role and nobody on that deal holds it — it reads "No one to send from — nobody on this deal holds the Home role (or the Transaction Coordinator, if no Home role is set).", because the real run would pause on that step until someone is staffed. An Email step that sends from a deal seat names the seat instead — for example "No one to send from — this step sends from the TC seat, and nobody holds it on this deal. Assign TC and the step sends from them." — and one that sends from a named teammate who has since left the team tells you to change who the step sends from. Select Change deal to try another, or Exit preview to go back to editing.

Publishing

Select Publish to open a summary of what changed since the last published version — added/removed/changed steps and whether the triggers changed — plus an optional What changed note for your team. A callout reminds you that runs already in progress stay on the version they started under; only new runs use the one you're about to publish. Confirm to make it live immediately.

Version history

Select History to see every past published version, plus your current unpublished draft (if you have one) pinned at the top. Each version shows who published it, when, and any notes. View opens that exact version read-only; Restore (confirm as Restore as new draft) copies it into a new draft you can edit and publish again — it never edits history, and a run that already completed stays pinned to whichever version it ran under.

What starts it — triggers

Above the step list, the Triggers card lists everything that starts this automator, if anything. Select Add trigger to add one: choose Status entry (a deal entering a specific pipeline stage and status), Status completed (a deal leaving a specific status by moving forward, or finishing every automator bound to a stage — use this to chain the next automator once the current stage's work wraps up; a stage also counts as finished the moment a deal reaches a closing status in that stage, even if not every automator has run yet; canceling, putting a deal on hold, or skipping a stage never counts as "completed"), Deal event (an offer changing status, a date field being reached, a deal being created, a showing being scheduled, a showing outcome being logged — completed, no-show, or canceled, optionally only when the buyer's Interest level is High, Medium, Low or None (leave it on Any interest to start on every result, including one logged without feedback), someone being assigned a seat on the deal, a buyer contract changing status, the buyer's EMD being received, a contingency on the purchase or buyer contract being resolved or waived, a Fix & Flip project changing status, a Retail Resale being created for a project, or the deal itself being put on hold, taken off hold, cancelled, or closed), or Manual start (team members start it themselves from a deal — no automatic trigger). See Building an automator for what putting a deal on hold or cancelling it does to a run that's already in progress. An automator started by Deal cancelled or Deal closed runs on the cancelled or closed deal from start to finish — use Deal cancelled for work that happens after a cancellation, like getting earnest money back. The deal counts as cancelled the whole time. Triggers are additive, not either/or — an automator can have a status or event trigger and a Manual start trigger at the same time, so people can still run it by hand even if it's also wired to fire automatically. Once you've added one trigger, a note under the list reminds you that you can add Manual start too. Every trigger also has its own Applies to section listing your team's named deal types (Settings → Deal Types) — leave everything unchecked to fire on any deal type, or check one or more to limit it. Two deal types built on the same underlying kind (for example, a Wholesale and a Subject-To type that are both, under the hood, wholesale deals) can each have their own trigger with a different Applies to selection. If your team hasn't set up any deal types yet, this section shows a link to Settings → Deal Types instead of a checklist. An advanced section lets you set Re-enrollment and Concurrency, each explained right under its options:

• Fire once per deal means this trigger starts the automator at most once for each deal, even if the deal meets it again. Fire every time the deal re-enters starts it again each time the deal meets the trigger. One exception: for the Deal cancelled trigger, "once" means once per cancellation. If a cancelled deal is reopened and later cancelled again, the automator starts a fresh run for the new cancellation.
• Only one active run per deal means that if a run is already in progress on the deal, a new one won't start. Allow multiple starts a new run even if one is already in progress on the deal.

A showing is scheduled starts the automator when a showing is booked on the deal — from the Dispo tab, by another automator's create-showing action, or by Ask TED. Use it for pre-showing work like confirming access with the seller or sending the buyer a confirmation. With the default Fire once per deal, only the deal's first showing starts a run; choose Fire every time the deal re-enters (and Allow multiple, if runs can overlap) to start one for every showing. Changing a showing's date or time doesn't start it again.

Someone is assigned a seat starts the automator when a person is given a seat on the deal. Pick the Seat it listens for — Acquisitions owner, Transaction Coordinator, Dispositions, or Project Manager (project deal types only) — the PM seat only exists on Fix & Flip, Retail Resale and other project deal types, so a PM trigger never fires on other deals; the trigger can't be added without one ("Pick a seat."). It fires when a deal is created with that seat already filled (including by your team's seat defaults), when the seat is filled later, and when it's handed from one person to another. Clearing a seat, saving it with the same person, or importing deals from a CSV file doesn't start it. Use it for lane work that belongs to whoever takes the seat — for example, a TC's intake checklist. When a seat changes hands — or a cleared seat is filled again — an automator whose home role is that seat already has its run in progress moved to the new person (see The deal header), so with the default Only one active run per deal no second run starts. To start a fresh run for the new person instead, choose Fire every time the deal re-enters and Allow multiple. The trigger reads "When someone is assigned the TC seat" (or ACQ, Dispo, or PM) in the list.

A buyer contract changes status starts the automator when the deal's buyer contract (on the Dispo tab) moves to a new status. Pick the Buyer contract status it waits for — Sent, Signed, Fell through, or Closed — or leave it on Any status change. With Run again every time on, it starts on every move; otherwise only the first. Use it for the work that hangs off the buyer side — for example, a TC checklist when the buyer signs, or a re-marketing push when a contract falls through (turn on Run again every time so it starts again when a second buyer falls through). Closed and Fell through also start on a deal that's already closed or cancelled, since the buyer contract often closes at the same moment as the deal. The trigger reads "When a buyer contract is signed" (or sent, falls through, closes, or "changes status" for any change) in the list.

The buyer's EMD is received starts the automator once, the first time a received date is entered for the buyer's earnest money deposit on the buyer contract. Changing that date later doesn't start it again.

A contingency is resolved or waived starts the automator when a contingency is marked resolved or waived — on the deal's purchase contract (see Contract facts and earnest money) or on its buyer contract (see Tracking buyer offers). Pick the Contract it listens on — Purchase contract, Buyer contract, or Either contract (the default, and what every contingency trigger made before the choice existed now uses) — then the Contingency type it listens for — any type on your team's list — or leave it on Any contingency type, and pick the Outcome: Resolved, Waived, or Resolved or waived. Reopening a contingency doesn't start it. With the default Fire once per deal, only the first matching contingency starts a run; choose Fire every time the deal re-enters (and Allow multiple, if runs can overlap) to start one for each. The trigger reads "When the Inspection contingency is resolved" (or "When a contingency is resolved or waived"; with a contract picked, "When the purchase contract's Inspection contingency is resolved" or "When a buyer contingency is waived") in the list. If the type it names is later removed from your list, it shows in amber with pick a new one and blocks publishing until fixed.

To act before a contingency deadline instead, use A scheduled date is reached with one of the contingency deadline dates — Inspection Contingency Deadline, Appraisal Contingency Deadline, Financing Contingency Deadline, Survey Contingency Deadline, Title Contingency Deadline, or Sale of Home Contingency Deadline — and an offset such as 3 days before. It uses the deal's active buyer contract; if that contract has more than one contingency of the type, the earliest deadline wins, and with none (or no deadline set) nothing is scheduled. The purchase contract has its own six — Purchase · Inspection contingency deadline through Purchase · Sale of Home contingency deadline — which read the contingencies on the deal's Deal Info tab the same way (earliest deadline of that type wins). Moving a deadline moves the scheduled date with it. Only the six default types have a deadline date here — types your team adds can start an automator when they clear, but can't be scheduled from.

Project status changed starts the automator on a Fix & Flip deal when its project moves to a new status. Pick the Project status it waits for — Under contract, Owned / Rehab, Rehab complete, Listed, Under contract to sell, Sold, or Fell through — or leave it on Any status change. It fires whether the status was changed by hand, by another automator, or on its own: funding the Fix & Flip moves the project to Owned / Rehab, cancelling it moves the project to Fell through, a signed buyer contract on the Retail Resale moves it to Under contract to sell (back to Listed if that contract falls through), and funding the Retail Resale moves it to Sold. A sold or fell-through project never moves on its own. Use Owned / Rehab to start the hold-phase work — the rehab checklist, insurance, utilities. The trigger reads "When a project moves to Owned / Rehab" in the list.

Retail Resale created starts the automator on the Fix & Flip deal when a Retail Resale is created from its project, or an existing one is linked to it. It reads "When a Retail Resale is created for a project" in the list.

Both project triggers always run on the Fix & Flip (buy) deal, never on the Retail Resale. A funded Fix & Flip keeps starting runs — for these two triggers and for every other trigger on it, such as someone being assigned the Project Manager seat — so hold-phase automators aren't stopped by the purchase closing. Sold or Fell through ends that exemption. Once the project is Sold, every other trigger (except Deal cancelled / Deal closed, which follow their own rule) stops starting runs on the Fix & Flip, but the two project triggers still do — so a Project status changed trigger set to Sold works. Once the project has fallen through, the Fix & Flip stops starting runs, except for Deal cancelled and a Project status changed trigger firing for the fall-through itself.

Contact triggers

An automator that runs on a contact (see Building an automator) has its own triggers. Select Add trigger and the dialog offers Contact event and Manual start — no status, deal event or Applies to choices. Pick the Event:

• A type is added to a contact — for example when someone becomes a Buyer. Under Contact types, tick the types it listens for, or leave them all unticked for any type. Turn on Only new contacts to start it only when the type is added as the contact is created (within a few minutes), not when you retag someone you've had for a while. It reads "When a new contact is added as a Buyer".
• A contact's buyer tier changes — pick the Buyer tier the contact moves to (for example Gold), or Any tier. Clearing a contact's tier doesn't start it, and neither does landing in Unverified — where TED puts every new Buyer until you pick a tier. It reads "When a contact moves to the Gold tier".
• A contact's follow-up date arrives — starts at 9:00 AM in your team's time zone on the day a contact's Next follow-up date comes due. Set someone's follow-up to today later in the day and it starts within about 15 minutes.
• A contact goes without contact — set Days without contact (1 to 365). Every morning at 9:00 AM team time, it starts for each contact nobody has reached out to in more than that many days (counting from when they were added, if nobody ever has). It starts once per gap: it won't start again for that person until someone contacts them and the gap opens up again. By default it only counts gaps that run out after you publish it — people already past the limit that day don't all start at once. It reads "When a contact goes more than 30 days without contact".
• It's a contact's birthday — starts at 9:00 AM team time on their birthday, once a year. Someone born on February 29 is celebrated on February 28 in other years.

The last three can also be limited to Contact types, the same way — for example only Seller contacts. Each date only counts once: moving a follow-up date to a new day starts it again on the new day, but checking twice on the same day never does.

To work the people who've already gone quiet, turn on Include contacts who already lapsed under Days without contact. With it on, the trigger also starts for everyone already past the limit when you publish — at most 25 people every 15 minutes (about 100 an hour), starting at the 9:00 AM team-time sweep, so a big list can take a day or more to work through instead of starting all at once. If today's sweep has already run, starts begin at the next 9:00 AM sweep — and the trigger reads "When a contact goes more than 30 days without contact (including existing)". With it off (the default), only people who go quiet after you publish start it. If you turn a goes-without-contact trigger off and back on later, it counts from when you turned it back on: people whose gap ran out while it was off don't start (unless Include contacts who already lapsed is on).

Advanced reads per contact here: Fire once per contact starts the automator at most once for each person; Fire every time starts it each time the contact meets the trigger — every follow-up date, every birthday. The three date triggers default to Fire every time when you add them. Only one active run per contact skips a new run while one is still in progress on that person.

Adding contacts through an import, merging two contacts, or transferring a book of contacts never starts a contact trigger, and neither do archived contacts. A contact trigger only works on an automator that runs on a contact — publishing a deal automator that has one stops with "Contact triggers only work when the automator runs on a contact. Remove them, or switch Runs on to Contact." Switching Runs on removes the triggers that don't fit (a message tells you how many).

Each trigger has its own on/off switch, and Edit/Delete. If a trigger points at a stage or status that's since been removed, it shows in amber with pick a new one; a seat trigger without a seat shows in amber with pick a seat, and a buyer tier trigger whose tier was removed shows in amber too. Any of these blocks publishing until it's fixed.

If you publish with no triggers staged at all, TED automatically adds an enabled Manual start trigger for you first — a banner confirms this — so the automator is never published in an unstartable state. You can still remove that trigger and add your own; if you publish with truly zero triggers staged, the card says plainly that the automator can't be started until you add one. See Running an automator on a deal for how Manual start shows up there.

Manual start is available on every plan. Status entry, Status completed, Deal event and Contact event triggers — anything that starts the automator automatically — require the Scale or Pro plan. On Starter, publishing an automator that has one of these triggers set up shows a message asking you to upgrade; switch it to Manual start to publish without upgrading.

Approval steps require the Pro plan too. On other plans, publishing an automator that still has an approval in it — one Ask TED drafted, or a library automator you edited — stops with "Approval steps require the Pro plan". Change each approval to a plain task (or remove it) to publish without upgrading. An automator that was published while your team was on Pro keeps running its approvals after a downgrade; it's only publishing a new version that needs Pro.

Common issues

• Publish stays greyed out — fix every error in the validation banner first; warnings alone won't block it.
• "This step only succeeds on a cancelled deal. This automator also starts on open deals, where it will fail — bind it to Deal cancelled only, or remove the step." — the step sets the deal's Cancelled Reason, which only works once the deal is cancelled, and this automator has an automatic trigger (like A deal is created or Status entry) that can start it on a deal that is still open. You only see this warning when that's the case: an automator that's started by hand, or only by Deal cancelled, doesn't get it, and neither does a step that comes after a Cancel deal action. You don't need a step for it: choosing Canceled in the deal header already asks for the reason, and so does the Cancel deal action. To cancel a deal from an automator, replace the step with a Cancel deal action. Otherwise remove the step, or remove the other triggers so the automator only starts after the deal is cancelled.
• "Steps after Cancel deal won't run unless 'End when the deal is cancelled' is off." — a warning, not a block. The automator ends when its own Cancel deal step cancels the deal. Move the follow-up steps to a separate automator started by Deal cancelled, or turn the setting off. "Steps after Put on hold will wait until the deal resumes unless 'Pause when the deal is on hold' is off." is the same idea for Put on hold: the later steps run once the deal comes off hold.
• "Cancel deal" only works on an Action step — remove it here and add an Action step for it. — Cancel deal and Put on hold can't sit on a Form's On submit actions, a Decision option or a Task (the message names Put on hold when that's the one). Add an Action step right after and put the action there.
• "Cancel deal" has to be the last action in its step — move the actions after it into their own Action step. — the step has another action after Cancel deal (the message names Put on hold when that's the one). Either one can end or pause the automator, so nothing can come after it in the same step. Put the other actions in an Action step before it.
• Pick a cancelled reason for the "Cancel deal" action. — the action has no reason yet. When the message goes on with "the one it used is archived, was removed, or was never set", the reason it pointed at is gone. Open the step and pick a reason, or switch it to Use the answer from a form.
• An admin can't archive a field or option your automator uses — that's deliberate. While a published automator, or a run still in progress on an older version, uses a custom field, one of a dropdown's options, or a lead source, selling reason, cancelled reason or property condition, Settings won't archive or remove it and lists what uses it instead. Publish a version that no longer uses it, and let the runs on the old version finish (or cancel them), then archive it.
• "Lead Source (Legacy Text) can no longer be set. Use Lead Source instead." (or the same for Reason for Selling (Legacy Text) and Selling Reason) — the old free-text lead source and reason-for-selling fields are retired for automators, because writing them skips your team's own list. Change the action or form to set Lead Source or Selling Reason instead; that saves the option and fills in its name too. Anything already published keeps running as it is until you change it.