In 2017, I started as a HubSpot consultant, advising go-to-market teams on their strategies and how to implement them with HubSpot software. Early on, HubSpot certifications were the critical part of my learning. After I was up-to-speed, certifications helped freshen and broaden my working knowledge. For example, before we launched Service Hub, I didn't know how to talk "customer service." The service strategy and software certifications helped me start on that learning curve. Ditto revenue operations.
The two HubSpot architecture certifications are for technical people what those classic marketing, sales, and service software certifications are for go-to-market consultants: a required 101 to working in this environment.
In 2023, I started as a HubSpot solutions architect, helping our customers with more technical challenges and opportunities. As I pivoted, I was really excited to learn that we had two HubSpot certifications for the role (not coincidentally, developed with some help from my new boss, the leader of our solutions architecture practice). The certifications are available to help HubSpot Solutions Partners get certified to deliver high-level projects and a lot of the content came from collaborations with our team. They're also useful to help people who know technology learn HubSpot's framework and for people who know HubSpot learn more about its technology—people at our solutions partners, that is. The certifications are gated for people working in for those companies.
They worked for me. I completed HubSpot Architecture I in July, right after I started. I was able to put almost all of the learning to immediate use as I started developing solution plans for our customers. I completed HubSpot Architecture II this April, as part of our certification week. Here are my top-level lessons learned from both.
Lessons Learned from HubSpot Architecture I: Data Models and APIs
Architecture I focuses on the core CRM functionality. A full HubSpot implementation's data can be really broad, as it's used for marketing, sales, and service operations, automation, and reporting. Good architecture starts with what HubSpot knows and how it knows it, and helps you understand where limitations exist and extensions or integrations are often necessary.
In go-to-market, everything starts with data. In HubSpot's context, the kinds of data marketers, sellers, and service folks work with differs. Being specific about how the system stores and processes data is the sine qua non of solution architecture. I've found the distinctions between the kinds of data you have and what you;re trying to do with them vital.
|
Type of data |
Usage |
Considerations |
| Objects: HubSpot CRM includes primary person, company, deal, and additional native and custom objects. Custom objects work similarly. |
CRM functionality is built on foundational objects. Customized business functions can be supported by custom record types. These work especially well when there are core use, reporting, and automation needs for the data. Solid records and properties mirror the real world and thus can be trusted. |
Limitations on the total count of records (in the millions for most subscriptions) and costs to increase; limitations on the number of properties per record and length of property values (in the hundreds); limitations on available associations between records. Standard objects drive specific functionality, it can be hard to mimc that functionality in custom objects (i.e. forecasting revenue without using Deals, sending marketing email not using Contacts). It doesn't make much sense to deploy objects when there are no people managing the objects. |
| Activities: CRM user inputs, like 1:1 email, calls, SMS, and meetings. |
See the history of a relationship or context around a potential deal or service-side ticket; monitor user behavior and progress towards primary objectives. These work particularly well when integrations to the underlying communications platform (call, email, meeting) automatically create the activity records. |
Automation and segmentation on recurring activities can be challenging; activities can't store much customizable or canonical data. Manual work on activity records can be tedious, so only high-impact activities should require it. |
| Events: native functionality like marketing email and website tracking as well as custom integrations and manual loads can store events related to CRM records. |
Events have far higher limits compared to objects, allowing things like software app usage activity to be stored in the CRM. HubSpot uses events for web and marketing email data. Limits on events thus rise to the tens of millions per month, with hundreds of potential property values on each event record. Custom events with custom property values can be configured for storing and driving far more intricate reporting and automation use cases. |
For uses aside from reporting, like automation or profile building, events need to be related to standard or custom objects to be useful (visible). Far higher limitations apply to events, with tens of millions of events able to be written into HubSpot each month (at the ENT subscription tier). |
Custom events are the under-utilized tool in HubSpot.
Since completing this certification, I've noticed that many HubSpot portals significantly under-utilize custom events. In flexibility and functionality, they are far superior to the 1:1 activity tooling, which by the same measure is over-used. The ability to directly control property values on the event make them ideal for most integrations of larger data streams. That segmentation, automation, and reporting can be driven off of custom events make them almost as powerful as objects. The intricacy of reporting and automation use cases are vast. I often find myself building architectures around event functionality.
Custom objects sometimes aren't worth the effort.
Database modeling almost always starts with relational databases. Since the CRM is a relational database, a lot of HubSpot administrators reach for custom objects to represent anything that doesn't neatly fit into the standard objects. That's what they're intended for, but too often I see objects that aren't used in a core business process. If there's not a rep seeing the object on a screen, then my rule of thumb is you probably don't need a full object. Relationship labels, sync properties, custom cards, or integrations with other systems often accomplish the goal with far less time/effort spent.
Complex integrations don't need to be built from scratch.
After database design, most architecture projects are integrating systems with HubSpot. The assumption is often that if a native integration doesn't exist, then the solution has to be completely custom with owned code. That's not quite true: there's a surprising amount of functionality in point-and-click tooling. You can run go-to-market ops, including integrating systems, without knowing code. You have to know data, you have to know your systems, and you have to think programmatically (like a developer), but you don't have to actually be a developer. HubSpot's own integrations (Ops Hub Pro+) and 3rd party iPaaS and ETL/rETL services aren't a fallback. They're first-class options. I rarely find myself getting to the custom-build step of the evaluation.
Watch out for API authentication nuance and rate limitations.
I see a lot of custom integrations get bent around the axle with poor initial design. Developers often authenticate into HubSpot using the method they're comfortable with, rather than the method that best fits their use case. API calls are often inefficiency chained together (putting everything after a CRM search call, for example), which works but doesn't scale with higher volumes. Making things efficient, with bulk calls or separate apps, enables scale.
Building something more complex, like webhooks interacting with HubSpot workflows, puts custom code outside of a self-hosted app and into the more feature-rich parts of HubSpot technical options.
Consultative > technical or consultative → technical.
Even after a long survey of complex tooling and technical nuance, the case studies for successful solution architecture showed that the real challenge is usually about problem definition, not solution design. Why matters a whole lot more than what or how. Solution architecture needs to start with a business objective, even if it's an obvious one like efficiency or growing revenue, and then with specific problem definition before any proposed solution can be considered.
HubSpot Architecture I: Data Models and APIs
(Note: this link will only work if your HubSpot account is marked as a Solutions Partner.)
Lessons Learned from HubSpot Architecture II: Content and Messaging Tools
Architecture II moves in two directions, architecting two kinds experiences: more technical and more marketing. On the technical side, it highlights elements like query languages like GraphQL and serverless functions for applications; on the marketing side, it reviews the tools for scalable, data-driven content experiences. The mix of themes is similarly wide: how to think like executives, communicate with developers, and deeply customize HubSpot's admin tooling.
Technical consulting begins with the end: without a strong understanding of the business objective, the most artful technical solution won't fly. Solutions need to be presented in terms of the ultimate goal they serve so that potential benefits can be weighed against potential costs. Presentations can get wrapped around the axle if they attempt to include both the plan and the education of how to execute it. Keeping things clear starts with clarity of goal and approach.
Architects need to speak with developers, but don't need to be step-by-step: while any project prefers low- or no-code solutions, typically code needs to be deployed. When working with developers, architects face two pitfalls: being overly detailed or being too high-level. The middle ground is the sweet spot: solid architecture provides sufficient detail to work from and resources for developers to build their own step-by-step plans. You know you're getting it right if your project charter is clear, you're including data/system diagrams, and specify which sets of documentation to reference for the builds.
Content-driven marketing shouldn't require brute force: hyper-personalized marketing can be done on almost any platform with brute force. When a campaign includes many slightly different sends to slightly different segments and requires hours of marketers time to configure, you're in brute force territory. If you have hundreds of smart content rules on a web asset, you're using brute force. Like any enterprise-grade platform, HubSpot has tooling to deliver more elegant solutions. These include HubDB and CRM-data for programmable email web content. These tools fit into architecture as marketers may need developer support in figuring out how to make scalable and lasting projects from these more robust tools.
It doesn't stop with HubSpot: the quick overviews of GraphQL and serverless functions help broaden the boundaries of what might be included in a custom architecture. HubSpot can interact with multiple systems to find, process, and display data. Interactivity for users, either in HubSpot CRM or in HubSpot-hosted content experiences, can be robustly customized to support broad objectives. This may seem vague--and it is. These are the multi-tools of HubSpot software for developers, and the use cases documented in the certification are worth focusing on.
HubSpot Architecture II: Content and Messaging Tools
(Note: this link will only work if your HubSpot account is marked as a Solutions Partner.)
Final thoughts
If HubSpot solution architecture is cooking up a delicious meal, then these two certifications are excellent overviews of HubSpot's pantry of the ingredients. Not only that, but they also show off some of the meals other chefs have made from the pantry.
When encountering a new scenario, I can now dig in, define the challenge, and then realize what seems like an obvious solution. Maybe there are fine points of detail to resolve, but the building blocks are clear. That clarify comes from digging into the topics these two certifications include.
If you want to brush up on the technical aspects of HubSpot builds or if your team is doing that kind of work already, then I highly recommend these two certifications.