Automator step types

The step-type picker in the builder groups every step into three sections. This article explains what each one does; see Building an automator for how to add and configure them.

An automator that runs on a contact only offers Instruction, Decision, Condition, Form, Task, Email, Text, Action, Recurring, Wait and End for now. Its Action steps, Form On submit and Decision When picked lists offer the contact actions only. Its steps can go to a specific person, the Home role or the Contact owner; its rules check the contact (buyer tier, contact type, contact fields and contact custom fields); its due dates and waits can count from a contact date such as Next follow-up or Birthday; and its Email and Text steps go to This contact (the person the run is about) with Contact merge fields such as {{contact.first_name}}.

Human steps

• Instruction — shows read-only guidance to whoever's on this step, with no action to take beyond continuing. A Who does this picker chooses who that is (see "Assigning a step" below).

• Decision — asks a person to pick one of several options; each option leads down its own branch. A Who answers picker chooses who that person is — it only shows up while the step is still a plain question; once any option gets an auto-answer rule it becomes a Condition instead (see Flow control below), which needs no assignee at all. Every option gets its own branch list under the step as soon as you add it — empty at first, with a + Add step to build off that option (see Building an automator). Under each option's name in the side panel, a line shows where it goes: "Starts with" its first step, or "No steps yet — continues to" the step it shares with the others.

  • When picked — under each option, a list of actions that run when that option is chosen: Add action offers the same actions as an Action step (add an expense, set a deal field, start another automator, send a deal-chat message, and more), each with the same fields. An option can run up to 10. They only apply while a person answers the step: once any option has an auto-answer rule the step becomes a Condition, the lists are hidden, and an option that still has actions shows a note that they won't run and will be removed when you leave the step with an auto-answer rule on — turn the rules off now to keep them. If an approval sends work back through this decision, an expense or showing on an option would be added again each round, so the builder warns you under it and publishing is blocked until you remove it or change the approval's send-back.

• Task — assigns a to-do that has to be completed. New tasks default to the automator's Home role (see "Assigning a step" below) — pick something else from the Assignment picker if this task belongs to someone specific. A Task can also require verification — turning that on makes it an Approval, where a second person signs off before the run continues. Choosing Approval as the step's kind is the direct way: pick an Approver role, and whoever holds that role on the deal gets Approve and Reject as soon as the run reaches the step — nobody has to mark anything done first. Because of that, an Approval doesn't offer Require file upload: on a Task with Requires verification, a matching upload completes the step automatically and the verifier sees the file afterward. An Approval that already has a file set (from an older draft, or a Task you switched to Approval) shows a warning, and publishing stops until you set it back to None. Approval requires the Pro plan — on other plans, the Approval option is shown with a Pro badge and can't be selected, and a draft that already has an approval (from Ask TED, or a library automator you edited) can't be published until you change it to a plain task. See Completing tasks and approvals. A Task can also optionally link a checklist item — pick one from the suggested list (keys already used on your deals or in your other automators, plus a handful of standard ones) or type a new one; typed keys are automatically lowercased and turned into the underscore_format the automator engine expects. When someone marks the task done, that item is checked off on the deal (if the deal doesn't have it yet, it's added already checked). See The deal checklist for what checking off an item looks like on the deal.

  If rejected (Approval only). An Approval's side panel has an If rejected setting that decides what happens when the approver says no:

  • Send it back to the same person (the default) re-opens the approval for the approver, with their note. Nothing else changes.
  • Go back to an earlier step sends the run back to a form, task, instruction or decision that comes before the approval, and runs forward from there again until the approval comes round once more. Go back to lists only the steps that work; if there are none, the panel says "Add a form or task before this approval to send work back to it." Stop after (1 to 10, default 3) caps how many times the work can go back — after that many rejections the approval returns to the same person instead and the run is flagged for attention.

  Every step between the one you pick and the approval runs again each round, and when an email, text or action sits in that stretch the panel warns you: "These steps will run again each round: …". Work can't go back across a sub-automator or recurring step, or to a stretch that adds an expense, books a showing or creates the Retail Resale (that would happen again every round). If rejected is only available while Blocking is on. The step list shows a "Rejected → back to …" chip on the approval, and the diagram draws a dashed line labelled Rejected from the approval back to that step. If you delete the step it goes back to, or move it so it no longer comes before the approval, the approval goes back to "Send it back to the same person" and a message tells you so. Choosing Go back to an earlier step without picking a step blocks publishing until you pick one.

  Freeze underwriting numbers on approval (Approval only). Tick this on a go / no-go approval for a flip, and the moment it's approved the project's ARV, purchase price, rehab budget and projected profit are saved as the approved plan — they fill the At approval column on the project's P&L tab (the profit only for roles with Transactions access), and the Fix & Flip deal's activity shows "Underwriting frozen at approval: ARV …, rehab …". It's off by default. "Only on deals that belong to a project" — on any other deal the approval goes through and nothing is saved. A project's plan is frozen once: if it was already frozen (by an earlier approval, or with Freeze underwriting now on the project), the numbers stay as they were. The checkbox only appears when the step's kind is Approval.

• Form — collects one or more values from a person: text, numbers, dates, dropdowns, a contact/company picker, or a Rating (1–5 stars) question that shows five stars to click (use its answer in a Review a vendor action). A Who fills this in picker chooses who that person is (see "Assigning a step" below). A Title issues & liens field shows the deal's lien ledger right on the step — add, edit, or clear liens without leaving the run; whatever's still open when the person continues is what this step collects. Add field offers two kinds of question:

  • Deal field — pick the field the answer is saved to, from the full list of deal fields (grouped by where they live on the deal), including your team's own custom fields — property facts like Mortgage Lender, Year Built, Lot Size, Parcel Number and County included. A few fields that are managed elsewhere (the lien totals, foreclosure flags and JV split) aren't offered. Everything else fills in for you: the question's label is the field's name, its type matches the field, and a dropdown field brings its own options. The question shows Saves to the field with a Change field link that reopens the list. If an automator drafted by Ask TED saves one answer to more than one deal field, the question shows an Also saves to line. Those extra saves are kept when you edit the step. You can't remove one on its own: delete the question to remove all of its saves, or, if it saves to two fields, use Change field and pick the second one so the question keeps only that save. There's no type to pick — it always follows the field. You can reword the label into a question ("What type of property is it?"); changing the field later only replaces a label you haven't edited. A text field is asked as a short answer; turn on Long answer to give it a bigger box. Required stays on the question. Pick one of your custom fields and the question reuses that field's own type and options, so a dropdown or checkbox set up on the Deal Info tab works the same way here. If the field doesn't exist yet, pick New custom field… at the bottom of the list — see Creating a custom field from the builder. A custom-field question has no label of its own — its label and options come from the custom field, so edit them in Settings → Deal Page Layout and every form picks up the change. To point it at a different field, use Change field: the question keeps its place in the form and its Required setting.
  • Custom question — name the question and pick its type (text, number, date, dropdown, contact, Rating (1–5 stars) and so on). The answer is kept with the form's answers only; it isn't saved to a deal field.
  • Asking why a deal is being cancelled. Two Custom question types exist for this. Cancelled reason shows your team's cancelled reasons when the form is filled in, grouped Seller-side and Buyer-side like the deal header. Cancellation caused by asks who caused it: Seller, Buyer, Title company, Us or Other. Neither answer is saved to the deal. A later Cancel deal action reads them — see Cancelling a deal or putting it on hold.
  • Saving to a list field makes the question that field's dropdown. Pick a field with a fixed list (Property Type, Purchase Type, Title Status) or one of your team's own lists (Lead Source, Lead Source Detail, Selling Reason, Cancelled Reason, Property Condition) and the question becomes a Dropdown whose options come from that field — you don't type any. The builder shows Options come from the field, with a preview of its current options (the first eight, then +N more); a list with nothing in it yet says This list has no options yet. The options aren't copied into the automator, so when you add an option in Settings the form offers it the next time someone fills it in. A Lead Source Detail question shows only the details for the deal's lead source. In the template editor, a fixed list shows its values and a team list reads Each team's own list.
  • Changing a Deal field question to a different field re-fits it: pick Bedrooms instead of Property Type and the dropdown becomes a number question. If a form saves both Lead Source and Lead Source Detail, the lead source is always saved first.
  • Changing a question's field or type keeps everything that reads its answer attached — a Condition rule, or a Set a deal field action that saves the answer to one of your custom fields. If one of those can no longer work with what the question asks now, publishing stops until you fix it. The message names the step and the question, for example In "Route by occupancy", the rule on question "Bedrooms" compares to "Vacant", but the question now collects a number. Compare to a number instead. or In "Save the answer", question "Bedrooms" collects a number answer, which can't be saved to custom field "Move-in date" (it takes a date). Rules are compared as text, so contains works on any answer and greater than / less than work on any answer that's a number — "Occupancy contains vacant" or "greater than 4" on a text question still publish. A rule saying a dropdown answer is (or is any of) something has to use one of its choices, and a multi-choice answer can only be checked with contains, is empty or is not empty. A dropdown saved to a custom field can only offer choices that field accepts (a dollar amount takes at most 2 decimal places) — one message lists every choice that doesn't fit, by name. Change the rule or the save, or change the question back. A text custom field takes any answer.
  • Forms you built before this change keep working and open in the same layout: a question that saves to a deal field shows as a Deal field, and every other question as a Custom question. Nothing changes until you edit it, and a team-list question is switched to the live options the next time you change the step. A few things to know about older questions: if a question's type doesn't fit its deal field (say, a Number question saving to a date field), it reads This question doesn't match the field, with a Match link that re-fits it to the field. A length or number limit saved on a Deal field question is shown (for example, Limited to 500 characters) with a Remove limit link, and changing the field clears it. And a dropdown you typed by hand that saves into a text field keeps its options editable.
  • Publishing an automator with a question that doesn't fit its deal field is blocked until it's fixed. The answer is saved to the deal the moment the form is submitted. If the person leaves that question blank, the deal field keeps whatever it already had. If the save can't be made (for example, the dropdown option was archived after you published), the answers are still kept and the run pauses for attention. Choose Retry now to try that save again or Skip action to move on without it. If several saves fail, each one is flagged in turn, so none is lost.
  • Preview form — below the questions, Preview form shows the form exactly as the person filling it in will see it: the question labels and dropdown choices (never the saved values), with no Submit button. It updates as you edit, and nothing is written to any deal. In Preview mode with a deal picked, it also shows that deal's current answers filled in and the live options for list fields; without a deal it shows the options saved on the step and says live options appear when you preview with a deal.
  • Typing your own dropdown choices — each choice has a Label (what they see) and a Saved value (reports & logic). The saved value fills in from the label until you change it, so you only type both when you want them to differ.
  • On submit — at the bottom of a Form step, a list of actions that run when the person submits the form: Add action offers the same actions as an Action step (add an expense, set a deal field, send a deal-chat message, and more). Where an action can use a form answer — an expense's amount, say — From a form answer lists only this form's own questions. Also save to a deal field on a question keeps working and isn't listed here. A Static value on a Set a deal field action here is written to the deal when the form is submitted — the person filling in the form never sees it. A form can run up to 10 actions in total, counting those saves. Answers are saved to their deal fields first, then the on-submit actions run, so an action can rely on them. If an approval sends work back to this form, an expense or showing added here would be added again each round, so the builder warns you under it and publishing is blocked until you remove it or change the approval's send-back.

• Email — sends an email, optionally pausing for a reply window before moving on. A Send from picker chooses whose connected mailbox it sends from — the Home role by default, or a specific Deal seat (ACQ/TC/Dispo) or person. If there's no one to send from when the step is reached, nothing is sent and the run pauses with "This step has no one to send from" (see Needs attention on a run). Replies can't be detected in this version, so a reply-wait step always advances once its timeout is reached, whether or not anyone actually replied — the builder flags this on the step when you turn the wait on. See Reviewing and sending automator emails.

• Email your buyer list — an Email step that's already set up to go to your buyer list: To is Buyer list, Send from is the Home role, and Skip buyers already emailed about this deal is ticked. It sits right under Email in the step picker; search "buyer" to find it. Once added it's an ordinary Email step, so you pick the template and choose which tier to send to in the side panel (see "Buyer list" below).

• Text — sends a text message to the seller, the buyer, or one specific contact from a teammate's smrtPhone number. Needs texting turned on for your team, and only sends during your team's texting hours. See Sending a text from an automator.

Assigning a step

Instruction, Decision, Form, Task, and Approval steps (and an Email's "Send from") all share the same assignee picker, in this order:

• Home role — whoever holds this automator's Home role on the deal. The option names the role, for example Home role — Transaction Coordinator, with a line under the picker explaining who it goes to; with no home role set it reads Home role (not set) and goes to the deal's Transaction Coordinator. This is the default for a new step, so most automators never need to change it — and unlike picking that same role by hand, it follows along if you later change the automator's home role, and it goes to one person on the deal rather than everyone holding the role.
• Deal seat — a specific deal-header seat (ACQ/TC/Dispo, or PM (project deal types only) — the Project Manager seat, which only exists on Fix & Flip, Retail Resale and other project deal types), resolved straight off the deal — no staffing setup required. If the seat is empty but someone with that seat's role is on the deal's Employee tab, the step goes to them; if nobody is, the run pauses until the seat is filled (see Needs attention on a run).
• Staffed employee role — whoever's staffed into one of your team's roles on this specific deal.
• Specific person — one exact team member. Prefer a role instead where you can, so any new hire can pick up the automator without you having to edit it.

An email's recipient picker additionally offers Deal seat and Staffed employee role as recipient kinds, alongside Seller, buyer, or agent, Vendor by type, Specific contact, Email address, and Collected earlier.

Seller, buyer, or agent — emailing the people on the deal

Pick Seller, buyer, or agent, then the role, to email whoever fills that role on the deal when the step runs:

• Seller — the deal's seller.
• Buyer — the deal's buyer. If the deal has no buyer set, the email goes to the buyer on the deal's current buyer contract.
• Listing agent — the Listing Agent in the Listing group of the Sale section on the deal's Dispo tab.
• Buyer's agent — the Buyer's Agent on the deal's current buyer contract (the Buyer & Agents group of the Sale section). A contract that fell through doesn't count.

If nobody fills the role, or that person has no email address, an email with that role in To pauses the run so someone can fix it (see Needs attention on a run). In Cc or Bcc, that recipient is skipped and the email still goes out. The run preview shows who each role would reach on the deal you preview with.

The same goes for anyone marked Do not email on their profile, whatever recipient kind reaches them (including a typed-in address that belongs to them): in To the run pauses; in Cc or Bcc they're left off and the run's timeline notes "Skipped ⟨name⟩: do not email". The run preview warns when a To recipient is marked do not email.

Vendor by type — emailing the title company, inspector or photographer

Pick Vendor by type to email whichever vendor of that type is on the deal when the step runs, such as the title company or the home inspector. The type list shows your team's own contact types and company types, by the names your team gave them in Settings, for example "Photography". Behind each name is the shared Ted-wide type it Maps to (set on the Contact Types and Company Types lists), and that shared type is what the email matches on. A team type that isn't mapped to anything doesn't appear.

Each type reaches the vendors on the deal tagged with that type:

• A type that both your contact types and your company types map to, such as your title company or lender type, shows once and reaches people and companies tagged with it.
• If two of your types map to the same shared type, they show as one entry with both names, such as "Photography / Videography", and the entry reaches vendors tagged with either one.
• Types that map to different shared types stay separate, even when the names look alike. If you keep an Inspector contact type and an Inspection company type mapped to different shared types, they're two entries: Inspector reaches only people tagged Inspector, and Inspection reaches only companies tagged Inspection. A contact type on its own reaches people, not companies.

A step you've already saved shows your team's name for its type. If you rename a type in Settings, the step shows the new name; nothing about who it emails changes.

If you deactivate a contact type or company type in Settings, its name drops off this list, but vendors already tagged with it still get the email. If it was the only type behind an entry, the entry goes away and a step you'd already saved shows an empty type picker; that step still sends. Activate the type again to see it.

Pick the type the vendor is actually tagged with on the deal.

When the vendor is a person, the email goes to that person. When the vendor is a company, TED sends it to the first of these that has an email:

1. The person set on the deal for that company. For the title company, that's the deal's Title POC.
2. The company's point of contact.
3. The company's own email address.

Vendor by type with your title company type (whatever your team calls it) always emails the title company set on the deal page, with no extra setup — even if the deal has another vendor tagged as a title company, including one added more recently. If you change or clear the deal's title company, the old one stops getting these emails. At the deal page's title company, TED emails the first of these that has an email:

1. The deal's Title POC.
2. The person picked with that company on the deal's vendor list.
3. The company's point of contact.
4. The company's own email address.

The {{title_company.name}}, {{title_company.contact_name}} and {{title_company.email}} merge fields follow the same rule, so the email always names the company and person it was sent to. Only when the deal page has no title company do the recipient and the merge fields use a vendor tagged with your title company type.

If the vendor has no email anywhere, the email isn't sent: the step pauses as needs attention. For a company the reason names it, for example "Acme Title has no email on file." For a person it reads "contact has no email on file" — check the deal's Assigned Vendors list (on the Employee tab) to see who that is.

Buyer list — emailing your buyer list from an automator

Add Email your buyer list from the step picker, or pick Buyer list as the To recipient on any Email step, to turn the step into a marketing campaign instead of a single email — useful for cases like "email my VIP buyers this new deal when it hits a certain stage." It's a different kind of step, so a few things change once you pick it:

• It has to be the only recipient — no other To entries, and Cc/Bcc drop away entirely.
• Send policy locks to Send automatically (a campaign can't be parked as a draft for review), and the pause-for-reply option disappears.
• A tier picker lets you target VIP only, Gold and above, and so on (based on your team's own buyer tiers — untiered buyers, buyers in an archived tier, and buyers still in the built-in Unverified tier are never included), plus a switch to send only to buyers whose buy box matches the deal. That switch includes every matching buyer in the chosen tiers, however many there are.
• Skip buyers already emailed about this deal is ticked on a new buyer list step. It leaves out every buyer who was already sent a buyer-list email about this deal — by an earlier step, another automator, or Send this deal to buyers. Untick it for a deliberate re-send, such as a price drop. A buyer list step saved before this option existed opens with it unticked and keeps sending to everyone until you tick it.
• The template picker narrows to Buyer and General templates, since this is going out to a list rather than one person.
• Send from has to be a real choice: the Home role, a Deal seat or a specific person. An older step still set to Step assignee — legacy or Deal owner — legacy shows "Pick who this buyer email is sent from." and can't be published until you pick one.

Behind the scenes, the step sends one email per buyer from the chosen sender's mailbox, paced to protect deliverability — buyers who've opted out of deal marketing are skipped automatically, and so is any company whose email is an opted-out buyer's address. The campaign line under the step on the run's timeline shows how many were skipped for opting out. If the sender hasn't turned on auto-send, or your team hasn't set a deal-marketing footer address in Settings, the run pauses and flags it rather than failing silently.

Tiered rollout example. Email your VIP buyers first, then widen the list a couple of days later without emailing the VIPs again:

1. An Email step to Buyer list with VIP only.
2. A Wait step for 2 days.
3. A second Email step to Buyer list with Gold and above and Skip buyers already emailed about this deal ticked — only the Gold buyers get it.

If everyone on the wider list was already emailed, the second step sends nothing, finishes, and the run moves on — it doesn't stop in Needs attention. Its line on the run timeline says "No new buyers — all N were already emailed about this deal."

Once the step completes, the run's timeline shows the campaign's live progress (sent-so-far/total, status, and the pause reason if it's paused) right on that step, with a link to the deal's Dispo tab where the full campaign list lives.

Setting a due date

Instruction, Decision, Form, Task and Approval steps — and the task a Recurring step creates — can each carry a due date. Turn on Set a due date in the step's side panel, then say when it's due:

• Relative to — what the date counts from: This automator started, This step was reached, or A deal date field.
• Deal date field — shown when you pick A deal date field: one of the deal's dates (the closing date, the due diligence date and so on), or one of your team's custom date fields.
• Offset (days) — how many days after that point the step is due. Use a negative number for "before", for example -3 with the closing date for three days before closing.
• Business days — count weekdays only.

The line under the picker reads the due date back in short form so you can check it — for example "3d after this step was reached", or "2bd" for two business days.

A due date tied to a deal date follows the deal: if the closing date moves, the due date of a step that's already waiting moves with it. If that date isn't filled in on the deal yet, the step has no due date until it is. A step that comes around again — after an approval sends work back to it — gets a fresh due date.

A Decision only has Set a due date while a person answers it. Once an option has an auto-answer rule the step is a Condition, which nobody waits on, so it has no due date.

A step with a due date shows it wherever the step shows up, and reads as overdue once the date passes. That's the same for a Task, an Approval, an Instruction, a Decision and a Form: the date appears on the step's card on the deal and on its row in My Tasks, where the step moves into Overdue, Today, This week or Later by its date. An overdue step is also listed in the assignee's daily briefing, and Ask TED counts it when you ask what's due or overdue. Nothing sends an automatic reminder for a due date.

In the builder, a step with a due date carries a small chip in the step list that reads the date back, such as "Deal date +3d".

If you turn Set a due date on and never choose anything in the picker, the automator won't publish, and the step is listed with "has a due date turned on but no anchor is set — pick one." Change any of the picker's settings, or turn the switch back off.

Automated actions

• Action — runs one or more automated actions on the deal with no person involved — things like setting a field, assigning a vendor, adding an expense, checking off a checklist item (same suggested-list-or-type-your-own picker the Task step uses), or Clear a title issue, which marks one lien on the deal's ledger as resolved. A special case, Status change, moves the deal to a different pipeline status. On a canceled or on-hold deal the pipeline status still moves, but the deal stays canceled or on hold — a status change never reopens or resumes a deal. A pipeline status never cancels a deal or puts it on hold either; use the Cancel deal or Put on hold action for that (see Cancelling a deal or putting it on hold).
  • Setting a list field. Fields with a fixed set of choices — Property Type, Purchase Type, Title Status, Lead Source, Selling Reason, Property Condition, a custom dropdown — only accept one of those choices. When you pick one as the Target field, the value is a dropdown of the same choices the deal page offers — Property Type shows its ten options, Lead Source shows your team's current list — so you pick instead of typing.
  • A custom field that doesn't exist yet. The Target field list's "Custom fields" group ends with New custom field… — create the field and it becomes the target, ready for a value. See Creating a custom field from the builder.
  • Where the value comes from. The value has three sources. Static value is a fixed value you set now — for a date field, pick the date; the same one is written every time. Collected field uses an answer a person entered on an earlier Form step; the list only shows questions asked on every path before this step (not ones asked later, or on only one side of a branch) that also fit the target, so a date field lists date questions, and if none fits it says "No earlier Form step collects a date yet." For a list field such as Lead Source, only a dropdown question that takes its choices from that same list is offered — a Selling Reason dropdown can't feed Lead Source. Today's date writes the day the step runs. If you want the person doing the run to enter the value, use a Form step instead — Add field → Deal field → pick the field — and their answer saves straight to the deal; no Action step needed. If you choose Static value for a date and leave it empty, publishing is blocked with a message like "Pick a date for Title Ordered Date." The same goes for a number or money field such as Contract Price: an empty Static value is not turned into 0 — publishing is blocked with "Enter a value for Contract Price." Type 0 if you really want to write zero.
  • Only fill if empty. By default Set a deal field always overwrites whatever the field holds. Tick Only fill if empty — never overwrite an existing value to write only when the field is blank — useful for a stamp like "Title Ordered Date = Today's date" that shouldn't replace a date someone already entered. Blank means no value, empty text, a field still at its starting default (for example Title Status "Not ordered"), or a custom field that was never filled in. A 0 someone typed counts as a value. When the field already has a value, nothing is written (Lead Source keeps its Lead Source Detail too), the run carries on, and the deal's run timeline says so on that step, for example "Skipped Title Ordered Date: it already had a value." The same checkbox is on a Form step's On submit actions and a Decision option's When picked actions.
  • Calculated fields aren't on the list. Assignment Fee is worked out from the buyer and seller contracts, so you can't pick it as a field to set. Publishing an automator that still saves to it is blocked with "Assignment Fee is calculated automatically - remove this step." An automator published before this change keeps running: the step does nothing and the run timeline says "Skipped Assignment Fee: it's calculated automatically."
  • Buyer contract fields. The field list has a Buyer contract group: Buyer Contract Sent Date, Buyer Contract Signed Date, Buyer DD End Date, Projected Buyer Close Date, Buyer EMD Amount, Buyer EMD Received Date and Buyer EMD Held By can be set; Buyer's Agent, Buyer Contract Status, Buyer Exit Type, Buyer Contract Amount, Buyer Contact and Buyer Fell-Through Reason can only be used in conditions (change the buyer price with Renegotiate in the Dispo tab's Sale section). These fields always mean the deal's current buyer contract — the one that hasn't fallen through — so after a buyer falls through and a new one signs, the same automator works on the new contract. If the deal has no current buyer contract, nothing is written, the run carries on, and the run timeline says, for example, "Skipped Buyer EMD Amount: no active buyer contract." A condition on one of these fields sees it as empty, and a Form question that saves to one is shown greyed out with "No active buyer contract on this deal." and doesn't need an answer — including a question that also saves to a field outside the Buyer contract group, which is greyed out as a whole. Because conditions read the current contract, a condition never sees Buyer Contract Status as Fell Through and always sees Buyer Fell-Through Reason as empty; to react to a buyer contract falling through, use the buyer contract status-changed trigger (coming soon).
  • Changing the target field. Switching to a different field clears a value you typed or picked, since it was meant for the old field. A value from a collected field stays.
  • Lead Source Detail. A Lead Source Detail target lists every detail as "Source — Detail".
  • Archived or out-of-date values. If an option has been archived since you picked it, it stays selected and is marked "(archived)". If a saved value isn't one of the choices any more (for example, "Single Family" typed in before this was a dropdown), the dropdown is empty and a message under it names the value — pick a current one. If a list has no options yet, the dropdown is disabled with "No options yet. Add them in Settings."
  • When something is missing. If the builder can't load your deal fields, the step shows "Couldn't load deal fields." with a Try again button. A field that automators can no longer set shows "[field] can no longer be set by an automator." and its value is locked.
  • Publishing. If the value you entered isn't one of the choices, publishing is blocked. For Property Type, Purchase Type, Title Status and custom dropdowns the error lists the values the field accepts; for your team's own lists (Lead Source, Selling Reason, Property Condition) it names the list, so pick from the team's current options. Today's date isn't offered for a list field.
  • Lead Source side effects. Setting Lead Source also fills in the lead source name and clears the deal's Lead Source Detail when the source changes, the same way the deal page does.
  • Cancelled Reason. A Cancelled Reason can only be set on a deal that's already canceled, so Set a deal field can't be used to cancel one. To cancel a deal from an automator, use the Cancel deal action.
  • Fields that can't be blank. Every deal needs an Address and a Title Status, so an action can't clear them. Leaving the value empty blocks publishing ("Title Status can't be blank"); if an Action step saves a form answer that was left blank into one of them, the run pauses and flags the step for attention with the same message.
  • Adding an expense. Add an expense records an expense on the deal when the step runs. Category is a dropdown with the same choices as the deal page's add-expense form (Earnest Money isn't one — it's entered on Contract Facts). Amount is in dollars, to the cent, up to $9,999,999,999.99. A new action starts with no category and a blank amount, so you can save the draft and come back; publishing is blocked with "Pick a category for this expense." or "Add an amount for this expense." until both are set. An amount that's there but can't be used is blocked too: 0 or less shows "Enter an amount greater than $0 for this expense.", and anything over the limit shows "Enter an amount of $9,999,999,999.99 or less for this expense." (the same message appears right under the Amount box — the builder keeps what you typed rather than changing it). If an older action holds a category typed in before this was a dropdown, the dropdown is empty and a message under it names the old value — pick one from the list.
  • Expense ledger, phase and source. Under Amount, Ledger says where the expense goes: This deal (the default) or Project ledger — the Expenses tab of the flip project the deal belongs to (see Automators for a flip). Phase is where it lands in a flip's P&L: Automatic (the default — Hold on the project ledger, Sell on a sell-side deal, otherwise Buy), Buy, Hold or Sell. Source is Out of pocket (the default) or Settlement statement, the same choices as the add-expense form.
  • Expense amount from a form answer. Next to Amount, choose Fixed amount to type a dollar figure, or From a form answer to use what someone entered on an earlier Form step — for example a Form step that asks "Inspection cost" followed by an Action step that adds an Inspection expense for that answer. The answer list shows only Number and Currency questions asked before this step (not later ones); if there aren't any yet it says "No earlier Form step asks for a number or currency amount yet." The amount is rounded to the cent when the step runs. If the answer is left blank, is $0, or is negative, no expense is added and the run carries on (the same goes for an answer over $9,999,999,999.99, or one that isn't a number). The deal's run timeline says why on that step, for example "No expense added — the answer was blank, $0, or negative." Publishing is still blocked if a saved pick now comes after this step or is only asked on some paths into it ("This step uses a value collected at …, but there's a path into this step that skips that step"), if it no longer exists, or if it isn't a Number or Currency question ("The form answer used for this expense amount isn't a number or currency question — pick one that is."). Category and Description are always fixed on the step.
  • Adding a vendor. Add a vendor puts a contact or company on the deal's Assigned Vendors list when the step runs. Source is a specific contact, a specific company, or From a form field — whoever was picked on an earlier Form step. Vendor type (optional) tags them: pick one of your team's types, or leave it at — None — to add them with no type. When the source is From a form field, the list also offers From the picked vendor, which "Adds them under each type on their profile." Use it when a form lets someone pick whoever is doing the job — a photographer one time, a runner the next — so each is added under their own type and a Vendor by type email reaches them. A vendor with two types is added twice, once per type; a vendor with no type is added once with no type. Types your team has turned off are skipped. Running the step again doesn't add duplicates. Switching the source to a specific contact or company clears From the picked vendor, since there's no form pick to read. If the vendor is already on the deal with no type — because a showing, an offer, the title company field or an earlier automator put them there — the step gives that entry the type instead of listing them a second time (with From the picked vendor, the entry takes their first type and any others are added). An entry someone added by hand with no type is left as it is, and the typed entry is added next to it.
  • Starting another automator. Trigger another automator starts a published automator when the step runs; yours keeps going right away and doesn't wait for it. If the automator you pick declares any Starting inputs, the Params section — the same one the Sub-automator step has — lets you hand it values: Add param, pick which starting input it fills, then choose where the value comes from (Static value, Collected field or Today's date). The automator you start reads each value the way it reads a form answer, so it doesn't have to ask again — a kickoff can tell a photos automator the visit date, for example. If the automator takes no starting inputs, the panel says so and there's nothing to add. If a value is blank when the action runs, it's passed as empty and both automators carry on. Publishing is blocked if a param reads an answer that isn't always collected before this step ("This step uses a value collected at …, but there's a path into this step that skips that step"). To start one copy for each value in a list, or to wait for the other automator to finish, use a Sub-automator step instead. Run on picks the deal it starts on: This deal (the default) or Linked deal — the other deal of this deal's Fix & Flip project (see Automators for a flip).
• Sub-automator — starts another automator from this one. Pick the target automator. If it declares any Starting inputs in its own Advanced menu, the Params section lets you hand it values when it starts — each param picks one of those inputs, so you can't mistype it (see Building an automator). If the target doesn't declare any starting inputs, the panel just says so — there's nothing to pass and no param to add. If a value you'd already picked is later removed from the target automator, the step shows an error naming it so you can pick another.
  • Start one for each value in a list — the switch under the Params. Off (the default), the step starts the target automator once and moves on. On, you pick a List field (from an earlier form) — a multi-select question, or an open-liens question, that someone answers on an earlier Form step — and Pass each value in as one of the target's starting inputs. The step then starts one copy of the target for each value chosen, handing it that value. For example, a form lists a deal's open liens and one "cure this lien" automator starts for each lien. If nothing was chosen in the list, nothing starts and the run carries on without an error. If the same value shows up twice, only one copy starts. If no earlier form has a multi-select question yet, the panel says to add one.
  • Wait for it to finish — a switch under the Params. Off (the default), your automator keeps going right away and doesn't wait for the one it starts. On, your automator pauses at this step until the other one ends, then carries on — handy when you need a shared sub-flow, like a common form or an approval, to be done first. On the deal's Automators tab the run reads "Waiting for the automator's name to finish" while it waits. If the other automator is canceled or gets stuck, your run is flagged as needing attention. Waiting can't be combined with Start one for each value in a list: while one switch is on the other is greyed out ("Not available when starting one per value" or "Not available when waiting for it to finish"). An automator that somehow has both on one step can't be published ("A step that starts one automator per value can't also wait for them to finish.") — turn either switch off to publish. An automator published before this check still stops its run at that step and asks for attention.
  • It's per run, not per deal. The list is read each time this automator runs, so running it again on the same deal starts the copies again. The Fire once per deal option on a trigger (see Publishing an automator) is a different setting — it limits how often a trigger starts an automator, not how many copies this step starts.
• Recurring — repeats a task or email on a schedule until a condition is met, like "check in weekly until the title is clear." A new Recurring step's task goes to the automator's Home role, like a new Task does. Under Stop when, pick A pipeline status is reached, A deal field is set, or Manual stop only. Manual stop only keeps repeating until someone selects Stop recurring on the deal's Automators tab. Whichever you pick, Stop after N occurrences is the safety cap: the step stops on its own after that many repeats (52 unless you change it, and never more than 100).

Automators for a flip

A Fix & Flip is two deals — the Fix & Flip deal and its Retail Resale — under one project (see Flip projects). An automator running on either deal can reach the other deal and the project:

• Set a deal field on another deal or the project. The Target field list ends with two more groups, both captioned "Only resolves on deals that belong to a project": Project (Project ARV and Project Name) and Linked deal — the other deal of the project, with the same fields as this deal except the buyer contract ones. A linked-deal field reads "(linked deal)" once you pick it, for example "Listing Price (linked deal)". A change to the project is logged in this deal's field history; a change to the linked deal is logged on that deal.
• Create the Retail Resale creates the project's sell deal, the same as Create Retail Resale on the project page: it starts in MSB with NAT and OTTO skipped. Pick the Deal type — a new action starts on Retail Resale. If your team has no sell-side deal type turned on, the action says to turn on Retail Resale in Settings → Deal Types.
• Set project status moves the project to the Project status you pick — the same seven statuses as the project page. It's recorded in the project's history as an automator change, and automators that start on Project status changed start as usual.
• Trigger another automator with Run on: Linked deal starts the other automator on the other deal of the project.
• Add an expense with Ledger: Project ledger books the cost on the project's own Expenses tab instead of the deal — for example an Action step, or a Form's On submit list, that books one holding cost such as a month of utilities or an insurance payment while you hold the house. Under the Ledger choice it says "Only on deals that belong to a project. On any other deal, no expense is added and the run carries on."
• Freeze underwriting numbers on approval, on an Approval step, saves the project's ARV, purchase price, rehab budget and projected profit as the approved plan when the step is approved (see the Task step above). On a deal that isn't part of a project, nothing is saved.

When there's nothing to act on, the action is skipped, the run carries on, and the step's timeline says why — for example "Skipped Listing Price: this deal has no linked deal yet.", "No expense added — this deal isn't part of a project.", "No Retail Resale created: the project already has one.", or "Project status not changed: the project is Sold." A sold or fell-through project is never moved by an automator — change it on the project page. Project fields can't be used in a Condition step yet.

Changing a contact from an automator

Six actions change a contact instead of the deal. They're on Action steps, a Form's On submit list and a Decision option's When picked list, on any automator:

• Set buyer tier — puts the contact in one of your buyer tiers (including Unverified). It never changes whether they're a buyer. Automators that start on Buyer tier changed start as usual.
• Set follow-up — sets Next follow-up a number of days after the day the step runs (in your team's time zone), on a specific date, on the day it runs, or from a Date question on a form, with an optional note. The note replaces the contact's follow-up note; leave it blank to clear it. A blank date answer sets nothing and the run timeline says "No follow-up set — the date answer was blank."
• Add to a list — adds the contact to one of your team's static lists. Smart lists fill themselves from their filters, and a private list belongs to one person, so neither is offered. A contact already on the list stays as they are.
• Change contact owner — makes a specific team member, or the person picked on a form, the contact's owner.
• Set a contact field — sets How we met, Notes, Preferred channel, Check-in cadence, Buyer status, the mailing address, Birthday, a buyer checklist date (Talked to them live, Buy box confirmed, Buying entity confirmed, Proof of funds confirmed — When this runs stamps the moment the step runs), or one of your contact custom fields. Only fill if empty leaves a field that already has a value alone. A blank answer never clears a field.
• Log a note — adds a note to the contact's timeline from the run's owner. It doesn't count as contacting them, so their Last contacted date doesn't move.

Who is this for? Every one of them starts with this picker:

• This contact — the person the run is about. Only on an automator that runs on a contact.
• The deal's seller or buyer — only on an automator that runs on a deal. The buyer is the deal's buyer, or the current buyer contract's buyer when the deal has none. For example: after closing, set the buyer's follow-up to 30 days out.
• A contact from a form answer — the person picked in an earlier Contact question (on a Form's On submit list, one of that form's own questions).
• A specific contact — one person you pick.

Picking the other subject's option blocks publishing with a note saying which to use instead. Each change shows on the contact's profile and in its history as made by the automator. If the step can't find anyone when it runs — the deal has no seller, the form answer was blank, the contact was archived — the run stops and its banner says the step failed (View error reads "No contact to act on"). Fix the cause and choose Retry now, or skip the action.

Reviewing a vendor from an automator

Review a vendor leaves a 1–5 star review on a vendor at the moment their work lands on the deal — for example, rating the photographer right after the photos come in — instead of waiting for the review prompt when the deal closes. The review shows on the vendor's profile like any other (see Rating and favoriting contacts).

The usual setup is a Form step with a Vendor question, a Rating (1–5 stars) question and, optionally, a Text Area for comments, and Review a vendor under the form's On submit. The On submit list offers it once the form has a Rating question and a Vendor or Contact question (on an automator that runs on a contact, a Rating question is enough). Adding it picks the form's own questions for you.

• Who to review — A vendor from a form answer (a Vendor or Contact question), The deal's vendor of a type (the deal's newest vendor of the type you pick, such as Photographer or Title Company — only on an automator that runs on a deal; a vendor added without a type counts when the company or person has that type on their profile), or This contact (the person the run is about — only on an automator that runs on a contact). A company is reviewed through a person: the person linked on the deal's vendor row, or else the company's main contact.
• Stars — From a Rating question, or A set number of stars. A blank rating leaves no review, so the question can be optional; the run timeline says "No review left — the rating was blank."
• Comment (optional) — a text answer from the form, or typed text.
• Review left as — The person who submits the form (the default) or The run's owner. When nobody submits a form — the action is on an Action step, or it runs again after Retry now — it's left as the run's owner.

The review is filed under the vendor's role on the deal (for example their Photographer tab), and the deal's review prompt for that person counts as done — closing the deal later won't ask for them again. Retrying never leaves a second review; if the run comes back to this form later, the new answer leaves a new review.

If there's no one to review when it runs — the deal has no vendor of that type, or a company vendor has no main contact — the run stops and its banner says the step failed (View error reads, for example, "No person to review at Acme Title"). Set the company's main contact (or add the vendor) and choose Retry now, or skip the action.

The Property Access, Photos & Deal Packet and Closing Day, Funding & Wrap library automators include an optional "Rate the property runner" and "Rate the title company" step. Automators you've already installed keep their current steps and don't get these. To add one to your copy, open it in the builder and add the step yourself. (A copy that has never run can also be removed and installed again to get the new version.)

Cancelling a deal or putting it on hold

Two actions on an Action step change the deal itself, the same way the Status dropdown in the deal header does. They're on Action steps only; a Form's On submit actions and a Decision option's When picked actions don't offer them. Each one has to be the last action in its step, because it can end or pause the automator. On a step that already has more actions, the Action type list leaves them out and says "Cancel deal and Put on hold have to be the last action in a step." Give them their own Action step.

Cancel deal cancels the deal and records why, in one go:

• Cancelled reason — choose Always use the same reason and pick one from your team's list (grouped Seller-side and Buyer-side), or Use the answer from a form and pick an earlier Form step's Cancelled reason question. Only questions asked on every path before this step are listed. If there aren't any, it says "Add a Form step before this one with a "Cancelled reason" question, then pick it here."
• Caused by — Match the reason's side (the default: Seller for a seller-side reason, Buyer for a buyer-side one), one of Seller, Buyer, Title company, Us or Other, or the answer to an earlier Cancellation caused by question.

When the step runs, the deal becomes Canceled with that reason and Caused by, TED records the stage it was in, and automators that start on Deal cancelled start as usual. In the deal's activity, the cancellation is credited to whoever's click ran the step — the person who submitted the form or finished the task just before it. When the step runs on its own (after a wait, say), it's credited to the run's owner, or to whoever created the automator if the run has no owner.

A common setup is three pieces:

1. A Form step asking "Why is this deal being cancelled?" with a Cancelled reason question.
2. An Action step with Cancel deal, using that answer.
3. A separate automator started by Deal cancelled that does the follow-up: the notice, getting earnest money back, closing things out.

Keep the follow-up in its own automator. An automator set to End when the deal is cancelled (the default) ends the moment its own Cancel deal step runs, so steps after it never run. The builder warns you: "Steps after Cancel deal won't run unless 'End when the deal is cancelled' is off." Turn that setting off if you want this automator to carry on.

Put on hold has nothing to set up. It puts an active deal on hold. An automator set to Pause when the deal is on hold (the default) pauses right after the step and picks up at the next step when someone takes the deal off hold; the builder says so: "Steps after Put on hold will wait until the deal resumes unless 'Pause when the deal is on hold' is off."

What happens when the deal isn't in the expected state:

• Cancel deal on a deal that's already canceled — nothing changes, the reason on the deal stays as it was, and the run timeline says "Deal not cancelled again — it was already cancelled."
• Cancel deal on a deal that's on hold, closed or funded — the deal is canceled, as it would be from the deal header.
• Put on hold on a deal that's already on hold, canceled, closed or funded — nothing changes, and the timeline says why, for example "Deal not put on hold — it is cancelled."
• No usable reason — if the form question was left blank, the run stops for attention with "Cancel deal needs a cancelled reason" and the deal is left alone. See Needs attention on a run.

A reason picked with Always use the same reason can't be archived in Settings while the published automator uses it — Settings lists the automator instead. Publish a version that uses a different reason first.

In a shared template, Cancel deal can only take its reason from a form answer, since every team has its own list of cancelled reasons.

Flow control

• Condition — branches automatically based on data already on the deal, with no person asked anything. A new Condition starts with one branch whose rule is Deal type is set, plus an Otherwise branch for everything else — change the field, operator or value, or remove the rule, from the side panel. Each branch, including that one, has its own list under the step with a + Add step. The field it checks can be a standard deal field, one of your team's own custom fields — pick it from the "Custom fields" group in the field picker, and the operator and value options adjust to match that field's type (a dropdown offers its own options, a checkbox offers yes/no, and so on; New custom field… at the bottom of that group creates one on the spot) — or, from the "Title issue type" group, a specific lien's canonical type ("is one of" / "is not one of" a checklist of your team's title-issue types).
  • Comparing to a list field. When the field has a fixed set of choices (Property Type, Purchase Type, Title Status, Lead Source, Selling Reason, a custom dropdown…), the value is a dropdown of the same choices the deal page offers — pick "Single Family", not a typed code. The operator list for these fields is is, is not, is any of, is none of, is empty and is not empty; "is any of" and "is none of" turn the dropdown into a checklist so one branch can match several choices. "Is not" and "is none of" never match a deal where the field is blank — use "is empty" to catch those. A custom dropdown or plain-text custom field offers the same two; for a plain-text field, type the values separated by commas. Currency, number and date fields keep their comparisons ("greater than", "at most"…) and a typed value.
  • Switching the field. Picking a different field keeps the operator and value only if the new field can use them; otherwise they reset.
  • What the branch says. Under the rule, a line such as "Takes this branch when Property Type is Single Family" spells the rule out using the choice's name.
  • Advanced rules. A rule saved in an older format shows "Advanced rule — can't be edited here yet." with its switch locked. Select Replace rule and confirm "Replace this rule? The current rule will be removed." to swap it for an editable one (Deal type is set to start); the step stays a Condition.
  • Out-of-date rules. If a saved value isn't one of the choices any more, the dropdown is empty and a message names the value — pick a current one. A saved field that's since been retired or archived, or an operator the field no longer supports, is flagged the same way. If the builder can't load your deal fields, the rule shows "Couldn't load deal fields." with a Try again button. A list with no options yet shows "No options yet. Add them in Settings."
  • Publishing. The value you compare to must be one of the field's choices — otherwise the branch could never match, so publishing is blocked until it's fixed.
  • Deal type and Buyer's strategy. Deal type isn't in the deal-field list; the separate Deal type option routes on the deal's own named deal type (from your team's Deal Types list, Settings → Deal Types) — pick "is"/"is not" one of your team's deal types, or "is set"/"is not set". A Buyer's strategy option reads the deal's selected buyer's buy box — pick one of your team's enabled strategies and whether the buyer's box should include it, not include it, or have no strategy set at all. It only shows up once the automator's Home stage is Marketing Searching for Buyer (MSB) or later, or has no Home stage set — a buyer isn't picked before then.
  • The offer that started the run. When an automator is started by an offer (the A buyer offer changes status trigger), a Condition can decide about that offer. Pick Offer amount or Offer status from the "Offer that started this run" group in the field picker.
    • Offer amount compares with is, is not, greater than, at least, less than or at most, against a number (type a dollar amount), a deal field (pick one of the deal's money or number fields, or one of your team's number or currency custom fields from the Custom fields group), or Floor price ("Contract price + your team's floor profit"). A field is read as it is when the condition runs.
    • Example — compare to the floor price. Set your team's floor profit in Settings > General (see Floor profit and floor price), then choose Floor price. The branch reads "Takes this branch when Offer amount ≥ Floor price". With a $100,000 contract price and a $5,000 floor profit, a $106,000 offer takes the branch and a $104,000 offer goes to Otherwise — for example, to start a renegotiation. If the team has no floor profit, or the deal has no contract price, the comparison is never met, so the run takes Otherwise. An automator that uses Floor price won't publish until the floor profit is set: "Set your team's floor profit in Settings → General before using Floor price."
    • Example — compare to a custom field. If your team keeps a negotiation ceiling in a currency custom field called "Max Offer", choose a deal field and pick Max Offer under Custom fields. The branch reads "Takes this branch when Offer amount ≥ Max Offer (custom field)". With a Max Offer of $90,000, a $95,000 offer takes the branch and an $85,000 offer goes to Otherwise. Only number and currency custom fields are listed, and custom fields aren't available in shared library templates. While an automator compares to a custom field, you can't archive that field — Settings shows which automators use it.
    • Offer status is is or is not one of Pending, Accepted, Rejected or Withdrawn.
    • Example — accept at or above your floor, otherwise send it to the manager. Trigger: an offer becomes Pending, set to Fire every time the deal re-enters (under Advanced). Condition: one branch with "Offer amount at least $100,000" leads to the steps that accept the offer; the Otherwise branch leads to a Task for your manager. The branch reads "Takes this branch when Offer amount ≥ $100,000". A deal only runs one at a time by default, so a higher offer that arrives while the manager is still deciding on a low one would be skipped — turn on Allow multiple in the same Advanced section so every offer gets its own run.
    • Set the trigger to fire every time. A new trigger is set to Fire once per deal, so only a deal's first offer would start a run. The rule says so: "This trigger fires once per deal, so only the first offer starts a run. Set it to fire every time, and turn on Allow multiple if runs can overlap, to handle each offer." To change it, open the trigger's Advanced section, choose Fire every time the deal re-enters, and turn on Allow multiple if runs can overlap.
    • Runs started any other way take Otherwise. A run started by hand, or by any other trigger, has no offer to check, so the branch isn't taken — the rule shows "Only applies when this automator is started by an offer. Otherwise this branch is never taken." when the automator has no offer trigger. The same happens if the offer is deleted before the Condition runs, or the field it compares to is blank. None of these stop the run or flag it as needing attention, and a preview of the automator always takes Otherwise here.
• Wait — pauses until a set amount of time, or a specific date, has passed.
• End — marks one path through the automator as finished.

Creating a custom field from the builder

Anyone who can build automators can add a new custom field without leaving the builder — you don't need to be an admin. Three places offer New custom field…:

• an Action step's Target field list (under "Custom fields"),
• a Form step's Add field → Deal field list (under "Custom fields"),
• a Condition rule's field list (under "Custom fields").

Pick it and fill in the same details an admin would in Settings → Deal Page Layout — a label, a type, options for a dropdown, and so on — then select Create Field. The new field is picked for you right where you started (on a Form question's Change field list, the question itself switches to the new custom field — it keeps its place and its Required setting), and a message confirms it's on the deal page under Custom Fields. A new dropdown's options are offered straight away, so you can set its value or compare against it without reloading. If the builder can't reload its field list right after, the field is still created — the message says so; reopen the step to pick it.

Only admins can rename, edit or archive a custom field afterwards, from Settings → Deal Page Layout. Your team can have up to 100 active custom fields; at the limit, the builder tells admins to archive one in Settings first, and asks everyone else to have a team admin do it. Library templates only use built-in deal fields, so the option doesn't appear there.