Mastering HubSpot Integrations: User-Driven vs Event-Driven Architectures

In today’s digitally connected world, businesses that want to streamline their operations and enhance user experiences must create seamless integrations between their different systems and platforms. HubSpot, a leading customer relationship management (CRM) platform, offers powerful tools for building these types of integrations. However, developing highly effective integrations often requires a multi-faceted approach that addresses both real-time user interactions and efficient background processing.

This post delves into two key strategies for building robust HubSpot integrations: 

1. Leveraging HubSpot’s UI Extensions to create user-driven, interactive components that respond to real-time user actions.
2. Implementing event-driven architectures to handle background processing and data synchronization efficiently.

Understanding each approach and potentially combining them can result in developers creating HubSpot integrations that are responsive to user needs, scalable, and resource-efficient. Whether you’re looking to enhance your CRM’s functionality with custom UI elements or establish seamless data flows between HubSpot and external systems, this guide will provide you with the knowledge and tools to achieve your integration goals.

Let’s explore how to harness the power of HubSpot’s development ecosystem to build integrations that significantly improve your business processes and elevate user experiences.

First, we look at common attributes relating to both architectures

About User Action-Based Integration

1. Trigger: User-initiated actions (e.g., clicking a button, submitting a form, loading a page).
2. Real-time response: Users often expect immediate feedback from an interaction such as ranting approval, fulfilling an order, canceling a request, processing a refund, or even closing a deal.
3. Synchronous nature: To provide a real-time response, the data flow must be synchronous,  following a request-response pattern. In most cases this is simple to implement.
4. Resource usage: Using a synchronous flow means that there may be inefficient resource utilization during peak usage times as each user action triggers an API call that must complete before another action can occur.
   
   
5. Scalability challenges: A growing user base can create scaling challenges as each action requires immediate processing.
6. User experience: Slow API call response times may lead to lower user satisfaction.

The attributes mentioned in 4, 5 & 6 are contingent on the server receiving the API calls. Most platforms can scale to thousands of API calls. However, at high volumes, user driven actions could lead to long running workflows or short running workflows. Deep understanding of the business requirements and the platforms involved will help drive the decision on whether this particular workflow is best served by a User driven architecture or a hybrid which we will discuss later. The reason for the distinction is important.

For example, consider two buttons on a screen. One button’s action loads a view of a table in another platform while the other button’s action downloads the table. The API call to view the table may take milliseconds to display to the user and falls well within the jurisdiction of User-driven architectures.

Now consider the button for downloading the table. An intelligent integration will determine that the file is too large to load in the browser in a reasonable amount of time. In this case, a best practice is to use a  request-response flow where the user gets an initial notification that the process has begun, and another when the process is done, and the table is ready for the user to save. This scenario exemplifies the distinction between user and event driven integration.. Some user driven actions might not completely finish and as such they benefit from a hybrid scenario which we will get into below.

About Event-Driven Integration

1. Trigger: System events or changes in a data state or a table trigger actions i.e. when email is known, when deal stage is “Closed Won”, when Today is 12/25/25.
2. Asynchronous processing: This architecture can handle tasks in the background, potentially improving system responsiveness.
3. Decoupled architecture: Allows for better separation of concerns and more flexible system design.
4. Improved scalability: Can more easily handle high volumes of operations by queuing and processing events as resources allow.
5. Better resource management: The asynchronous nature of this architecture allows it to optimize resource usage by batching operations and processing during off-peak times (if applicable to the scenario/task at hand).
6. Complexity: Due to a decoupled architecture , there is additional complexity in terms of event management, error handling, and ensuring data consistency.
7. Real-time vs. eventual consistency: There could be a delay between an action occurring i.e. setting a deal’s stage to ‘Closed won’ and its effects being visible, which could be confusing for users if not properly communicated. 

The attributes in 2 & 7 show hybrid scenarios of the event-driven architecture. In these attributes, we see how we can improve the overall user experience even with event-driven architecture where the user is not readily present or is present but expects some confirmation that a task is done. The use of email and alerts can be useful in providing feedback to the user and manage their expectations, and improve their experience.

Hybrid

Now let us talk about the hybrid scenarios. Most architectures employ a hybrid approach in order to provide excellent user experience. A hybrid scenario combining user action-based and event-driven approaches can provide the benefits of both architectures. This approach can offer real-time responsiveness when needed while also ensuring efficient background processing for larger operations.

It typically manifests like this

The user will usually start the process. Like clicking a button to generate a report or download a table as a spreadsheet. The architecture has a duty to provide real-time updates for critical or time-sensitive data or specified data.

The architecture will use scheduled events to handle regular (there is always some form of frequency involved), full synchronizations or perform some action to ensure overall data consistency.

The architecture can manage and sync change events for near-real-time updates without constant polling.

There will be a queue-based system that provides a buffer for high-volume operations and improves fault tolerance within the architecture

There is a datastore to store the event state so it can continue if needed or know where to pick up from when it starts running.

As solution providers, how can we know when to employ a user driven architecture or an event driven architecture or even when to blend them into a hybrid to get the both architectures? It boils down to asking the right questions. I have listed out 10 questions to prod a new case with.