Something went wrong in your workflow? Did a contact move through but wasn’t assigned a contact owner as expected? Or, perhaps you saw that an action was unable to be completed? Because workflows are an automated process, they are executing actions in the form of a race. This means that down to the second, the time stamp of the action is important. When something doesn’t go as planned - you see a property wasn’t set as expected or a different owner was assigned to your contact, it is likely that the workflow was racing against another automated process. This is what we call “a race condition".
Because HubSpot offers a number of automatic processes that save you time, like active lists, workflows, and conversation to ticket automation - often times you end up using multiple automation features at once. This is when we see the race condition come into play most. Since this is scenario based, let’s look at a couple of examples so that the next time you see something unexpected happen with a record in your workflow, you might be able to pin point the hurdle in no time.
Please note: Workflows are only available for Professional and Enterprise subscriptions
Examples of Race Conditions When Using HubSpot Automation
Example #1: An automation race for ticket ownership
When using conversation to ticket automation features in conjunction with a workflow, a race condition is common. For example, by default, incoming conversations are left unassigned for your team to triage. If you want to route the conversation to specific users and team members, you can click to toggle the automatically assign conversations switch on. When this is on, you can select to route incoming email conversation to a contact's owner or to a specific user or team. To create a ticket for each new conversation, you can also turn on the toggle to automatically create tickets. A guide on those settings here.
In this scenario, when the conversation is set to be assigned to the contact’s owner, the expectation would be the following: contact submits a form to your support inbox, the email triggers the creation of a ticket, the ticket record is assigned to the contact’s owner. However, what if there is a workflow that the form submission is linked to a lead rotation workflow too? This would mean we have two automation processes aiming to set the contact’s owner, and here is where the race condition will be what decides the owner.
Hypothetically, we have contact John Doe who submitted the “I need help contact ticket form.” This triggered the creation of a ticket: “Question about my marketing campaign.” The issue is that John Doe’s ticket was not assigned an owner.
In addition to the ticket creation, this form submission is linked to the "Contact Us Auto Assign” workflow which has a lead rotation action to assign the contact to a contact owner. If you compare the timestamps recorded when the ticket was created (you can view this by navigating to the ticket record, clicking “view all properties” on the left panel, then search for ‘create date’ > hover and click on ‘details’), with the timestamp recorded when the contact record was assigned to its owner, we will see that the ticket was created during the same timestamp the contact owner was set by the workflow and it is most likely, that the ticket was created first before the contact was given an owner by the workflow, therefore the ticket remained unowned. To nail down the exact timestamps further down to the seconds, you can contact HubSpot’s Support team for confirmation.
The best solution for this scenario would be to use a ticket workflow to automate all processes. If you would like to automatically assign tickets created like the above example after the contact owner has been assigned, you may wish to consider doing so with a ticket workflow which can be done with a Service Hub subscription.
Example #2: A race condition when a contact is ineligible to sync
When a workflow is enrolling contacts automatically based on criteria, this means the enrollment process will begin the moment the contact is created and/or contact meets the criteria. Unfortunately, sometimes we see errors on the workflow’s history tab that don’t make sense right away.
In this scenario, we have a workflow that is enrolling contacts based on the create date being known, then the workflow is setting the Salesforce campaign. This issue is John Doe’s workflow enrollment has an error: “This contact is ineligible to sync to Salesforce because it doesn't have a valid email address or isn't on the inclusion list.“
Since there is an inclusion list set, any contact not within the inclusion list will not be synced to Salesforce. But, when we check the inclusion list post-error, John is in the list. This helps us nail down that there was likely a race into the list and the workflow. We expect the error message to appear because the workflow attempted to set the Salesforce campaign before the contact entered into the inclusion list. If we hop into John Doe’s contact record, we can reference his timeline activity to see the timestamp for when he enrolled in the workflow and when he was added to the Inclusion list. If they’re the same timestamp, a race condition is likely the cause and, as mentioned above - we can confirm the timestamp down to the seconds with HubSpot’s support team.
To rectify this issue, and any similar scenarios, you can add a delay to the start of the workflow or include inclusion list membership in enrollment criteria of the workflow. Either of these will prevent the race condition that caused the workflow error.
While these are just a couple of scenarios that help explain what a race condition is in the workflows tool and how they can look, they are a great jumping off point for when you see something go array with a record’s automation and how to prevent it. Something may not be broken or bugging out, but rather two processes are racing against one another.
Originally published Dec 30, 2019 1:06:32 PM, updated January 15 2020