TL;DR: With the power of Github workflows, we built a great system to free our sales/support teams from having to manually perform mundane administration tasks.
As with any good solution, let’s start with our problem. At Anecdotes, we manage our customers and leads with Hubspot’s CRM. So when the Sales & Onboarding team wanted to manage customers on our platform, they would need to manually update the customer data.
As you probably understand, this is not an ideal solution, and as developers, we don’t like to do things manually every time.
Creating an administration platform for managing customers could be a decent solution but we aim to simplify our sales process without adding on additional tools. Furthermore, as a startup, we will always opt to invest our energy into our product (which is awesome ;).
So How did We do it?
We considered two main options:
- On pull — We already have a scheduled task that syncs our platform to Hubspot and enriches our customer usage data. So we thought of adding another field that could then be used to create users.
- On push — This could be accomplished by using Hubspot workflows to create customers on our platform.
Hubspot has an option to use workflows for any change that is happening on the data (and even manually).
We chose the “On push” approach because we wanted the customer creation to be done immediately, without increasing the wait time of our scheduled task.
But we faced some obstacles:
- These endpoints are part of our back-office service. Since this service is internal, it would be dangerous to change and leave it exposed to the “outer” (internet) world.
- We could add an access token to Hubspot. However, this might also be dangerous since this token could be a gate to one of our main services.
{{banner-image}}
Our Solution
I will start with the fact that we are using Github actions on our CI/CD process, so it was a simple solution to use them here as well.
We now have a new workflow that has two parts — Hubspot’s workflow and GitHub’s workflow.
- We created a new workflow on Hubspot that is triggered by a change in a new field. This field represents the contact’s status.
- The cool part is that we used custom code on Hubspot’s workflow and we call our Github workflow. The code is written using Node. However, the code is somewhat limited as there are only a few libraries available, Axios included.
This is an example of our custom code in Hubspot.
- We created a new repository on Github dedicated to Hubspot workflow integrations. To this Github repository, we added specific permissions to our GCP account.
- On Github, we had the option to create a workflow for each action type but we decided to use one workflow and split the actions by the parameter “ACTION_TYPE”.
- On Github’s workflow, we called to the relevant endpoint by the “ACTION_TYPE”.
This is an example of Github's workflow.
- As part of each action on our backend, we now update the status on Hubspot. With this update, our sales team has the data if the contact was created or if there was any type of exception.
- We also have another part of the Hubspot workflow that updates the status to “unknown issue” if there is no response after 5 minutes.
What Have We Achieved?
After creating these combined flows, we simplified the process down to a few actions that our sales team can do by themselves. For instance, creating accounts and users, deleting an account, etc.
In addition, with these new flows, we achieved a full circle of data enrichment from Hubspot to our platform and to the opposite side.
Conclusion
In this blog post, I hope I gave you a taste of combining two worlds - Sales and Engineering. For me as a developer, it was a great opportunity to understand a bit of Hubspot and try to leverage its power, not only for sales but for easier data management.
