A 5 Part Series on Becoming a HubSpot Workflow Champion
There is no question about it: HubSpot’s workflow tool offers some of the most powerful and accessible automations out there. When you consider that this single tool accesses information across your entire front office and all client touch points across virtually all tools in HubSpot, the possibilities are truly endless.
That said, you can’t tap into the potential of HubSpot workflows if you don’t understand them at a foundational level. So dive into part one of my five-part blog series that will give you the understanding you need to level up your workflow game!
There are several types of workflows you can run depending on the Hubs you have. Most people have at least the contact, company, and deal options to work with.
For the sake of this blog, when I say "workflow type" I am referring to the object type that the workflow is based on, not whether it is a standard, date based, or date property based workflow.
While they seem very similar at the outset, there are important differences that need to be taken into account.
Understanding the differences between object-based workflows will save you a ton of time and open the doors to new automation opportunities.
The first thing to understand is that the object that the workflow is based on is the object intended to be impacted by the workflow.
For example, in a contact-based workflow you can trigger the workflow based on a form submission.
You can’t do that in a company, deal, or ticket based workflow. Why?
Because you can’t submit a form as a company, deal, or ticket. Only contacts can submit a form.
Similarly, you can’t add a company to a contact list in a contact-based workflow. You are acting on the company record, not the contact record. You can add a company to a company list in a company workflow, but not in a contact workflow.
Triggers change based on the type of workflow you are building. Triggering using the properties that the object the workflow is based on will always provide you with the most conditioning options.
What do I mean by conditioning of triggers?
Conditioning a trigger is a way in which you drive how HubSpot will consider the value of the property when triggering a workflow. Will we have to have an exact value? Contains the value? Has never or ever been the value? This is how we are conditioning the way that HubSpot triggers a workflow using the property that we chose to center that trigger on.
Here is an example - if I am running a contact-based workflow, I can trigger that workflow using the Annual Revenue property of the contact or the company.
It would seem like it would not matter which one you used, but when you look closely, it does matter.
When you use the contact property for Annual Revenue (a number property type) in a contact- based workflow you get one more option to condition that numeric value - has ever contained any of. This option is not present if you use the Annual Revenue company property to trigger a contact workflow.
Let’s take a look at date properties that trigger workflows.
If you create a trigger on a contact workflow using a contact date property, you will have the option to say that the day is more or less than X days ago or X days from now.
If you try to trigger that same contact workflow with a company date property you will notice that those two options are not there. Same goes if you try to use a deal, ticket, or custom object date property.
Curiously, these limitations on the date property only exist in contact-based workflows. When you trigger any other object type workflow using a date property of any object, you not only get the two options mentioned above, but you get other conditions as well.
You can trigger based on the date being updated in the last X days, is after or before another property, or was updated before or after another property.
These behave just like triggers in that everything I said above, as it pertains to conditioning properties within triggers based on the object type for your workflow, is also true for if/then branches.
This means that the same way in which you are able condition dates, numbers, text, etc within each workflow type for triggers will be available for if/then branches.
You will want to follow the same rules as in the above sections when considering your if/then branches and what type of workflow you want to build with.
Figuring these things out on a document or schematic (Lucid, Miro, etc.) will save you a ton of time and help you produce better workflows.
Copying Properties When Creating a New Object
When you are creating a new object within a workflow it is very important to use the right type of workflow.
You will only have properties available to be copied to the new object from the object type that the workflow is based on.
If you want to create a new object in a deal workflow you will only be able to copy deal properties.
If you want to create a deal in a company workflow you will only be able to copy company properties.
You can always set properties for all records created within a workflow, such as the deal stage to start a new deal that is created via workflow, but if you want to copy properties from another record when creating that new record in a workflow, you will only have the properties of the object the workflow was based upon.
The same goes when you are copying properties. Just like with the record creation step, you can create or update any record type, but you will only be able to copy properties from the object type the workflow was based on.
This is another important consideration. One of the best things in workflows is being able to use tokens to dynamically name tasks, deals, etc. and to add context to the messages you send through the workflows.
Whatever object type the workflow is based on will determine the types of tokens you can use in your workflow actions.
If it is a contact workflow you will have contact properties in the tokens.
If it is a company workflow you will have company properties in the tokens.
The same goes for deals, tickets, and custom objects.
Custom objects make HubSpot even more awesome. This is largely because of how powerful they are.
Your custom objects will have the same power and capabilities in workflows as the native objects do.
You will be able to condition dates and numbers for triggers and if/then branches the same way that you can in company, deal, and ticket-based workflows.
You will be able to create new records of your custom object type.
You will be able to associate newly created records to your existing object type.
You can update pipeline stages if you have them built for your new object type.
The custom object is a powerful way to make your workflows even more dynamic and provides you with some additional options when designing your automations.
While there are clear differences between workflow types, they have more in common than not.
I can update a company property in a contact workflow
I can update a deal stage in a deal, company, or contact-based workflow
This happens because of associations. We can impact records that are associated with the object record types that we are triggering the workflow from.
You are now more equipped to build the workflow automations that dreams are made of. In our next piece in this series, we will discuss how to condition triggers for creativity and precision.