Welcome to Automations 2.0. Now, you can leverage conditional logic, integrate with 3rd party apps, and automate multiple tasks across projects—letting you handle more with less work. With an enhanced builder comes a new setup process, and we’ll cover everything you need to get up and running below.
📚 Tip
Haven't switched to Automations 2.0 yet? Learn more and request to switch here.
Key terminology
Term | Definition |
Trigger | The event and conditions that will cause the automation to start running in projects |
Step | A “step” in an automation (i.e. an action, wait, or condition in Automations 2.0) |
Action | Something that happens when the automation runs (e.g. “send email”) |
Wait | An amount of time between steps |
Condition | Criteria that causes the automation to branch to unique steps based on whether or not it’s met |
Run | An instance of an automation triggered in a project |
Moving to Automations 2.0 from the old builder
Automations 2.0 fundamentally change how you build and “activate” workflows. Previously, only one automation could be applied per project, and automations were activated only when an inquiry came in via form (or manually). Automations ran through a project’s entire lifecycle–from inquiry received to project closure.
With Automations 2.0, automations can fit almost any scenario (outside of just inquiries). Multiple automations can be applied per project, and they are activated automatically, whenever a certain trigger criteria is met. All of the steps in an automation are connected sequentially, which means you’ll likely find yourself building more, smaller automations in your account. You can think of Automations 2.0 as a set of automated rules that will apply to all of your projects if they fit the criteria, versus a single workflow only available to one project.
| Automations 2.0 | Old automations |
Trigger | Comprehensive triggers including scheduling, files, bookings, and other project milestones. | Limited to lead/contact form submission or manual application to a project. |
Building blocks | Each automation consists of a trigger, actions, waits, and conditions. | Automations consisted of only actions, with the “waits” built into the actions themselves; and a trigger configured from the automations builder. |
Project type filtering | Project types for the automation are selected under the trigger. | Project types for the automation were selected from the automations builder, under the “Automate via contact form” column. |
Application | Global application—automations apply automatically, whenever the trigger criteria is met in a project, once activated. | Automations were applied per project; either automatically, when a form was submitted; or manually. |
Scope of automations | Multiple automations can run in the same project, whenever the trigger criteria is met. | Only one automation could be applied per project. |
Relationship between steps | Steps are sequential, meaning each step waits for the previous step to complete before running. | Steps were independent and could occur in any sequence. |
Conditional logic
| Supported
Read more about using conditional logic in your automations here. | Not supported |
Centralized view of all automation runs | Supported
View and filter all of your active automations, across all projects, from the Activity tab. | Not supported |
External integrations | Supported
Currently supported: Calendly and Flodesk. | Not supported |
Manual apply | Only automations configured with the “Manual trigger” trigger can be manually applied to a project. | Option to manually apply any automation to any project. |
Edit email before sending | Only emails created through the “Create email draft” action can be edited before sending. Emails created through the “Send email” action cannot be edited before sending. | Any email included in an automation could be edited before it was sent, so long as the step was set to “Require approval before sending.” |
Step approval | Automation step approval is available from the corresponding project or the Automations 2.0 Activity tab. | Step approval was done through tasks. |
Updating email and file templates | Email and file templates will update automatically in all upcoming steps in active runs, and future automation runs will send the updated version. | Any changes made to templates used in an automation would not apply to the template in the automation. |
Example
Let’s say you always send a specific questionnaire to your corporate branding clients, 2 days after an invoice is paid in full. 5 days after the questionnaire was sent, you send a reminder if it hasn't been submitted. If it has been submitted, you send a "be in touch soon" message.
Automations 2.0 | Example |
Trigger | 2 days after invoice paid in full |
First action | Send questionnaire file |
Condition | If questionnaire is submitted |
Additional actions | (if yes) Send “be in touch soon” email (if no) Send reminder email |
Wait | 5 days after questionnaire was sent |
Here’s what this looks like in Automations 2.0:
Here's what this looked like in the old builder:
Here's what this looked like in the old builder:
📚 Tip
Key differences:
In the old builder, the “wait” was combined into the automation step itself
In Automations 2.0, it’s broken out
In the old builder, you needed to tie the automation to a lead form(s), contact form(s) and project type(s), or activate it manually in a project, in order for it to “run”
In Automations 2.0, you set the appropriate project type(s) for the automation under the trigger, then activate the automation, and it will then “run” whenever the trigger criteria is met
Additional resources
Still have questions? Feel free to send us a message by clicking the Question Mark icon on any HoneyBook page. Our team is always happy to help!