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 per second. 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. In a situation where a table is large, 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 to manage their expectations, and improve their experience.

Hybrid

Now let’s talk about 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 as follows:

The user will typically start the process by 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 an action to ensure overall data consistency. It will also manage and sync change events for near-real-time updates without constant polling.

A queue-based system will provide a buffer for high-volume operations and to improve 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 do we determine whether 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.

Here are 10 categories of questions that help uncover the specific requirements. These questions cover various aspects of the project, including user needs, system requirements, data characteristics, and business processes. By answering these questions, you can gain a clearer picture of whether a user action-driven, event-based, or hybrid approach would be most suitable for your project.

1. User Interaction and Expectations

• How frequently do users need to interact with the system?
• Do users expect immediate feedback or results from their actions?
• Are users willing to wait for background processes to complete?
• Is real-time data synchronization critical for user workflows?

2. Data Characteristics

• What is the typical volume of data being processed?
• How frequently does the data change?
• Are there specific times when data updates are more frequent?
• Is the data time-sensitive?

3. System Performance and Scalability

• What are the performance requirements for the system?
• How many concurrent users does the system need to support?
• Are there expected periods of high load or traffic?
• How does the system need to scale as data or user base grows?

4. Integration Complexity

• How many systems or APIs are involved in the integration?
• Are the integrated systems capable of pushing events or webhooks?
• Do the APIs have rate limits or usage quotas?
• Is the integration bidirectional or unidirectional?

5. Business Process Alignment

• Do the business processes require immediate action on data changes?
• Are there any regulatory or compliance requirements for data handling?
• How critical is data consistency across systems for business operations?
• Are there specific business hours or time zones to consider for processing?

6. Error Handling and Recovery

• How should the system handle failures or errors in the integration process?
• Is there a need for a retry mechanism for failed operations?
• How important is it to maintain an audit trail of all actions and events?

7. Resource Utilization

• Are there constraints on computing resources or API call budgets?
• Is it more cost-effective to batch process data or handle it in real-time?

8. Maintenance and Monitoring

• How will the integration be monitored for performance and errors?
• How easily can the integration be updated or modified in the future?
• Is there a need for detailed logging of all actions and events?

9. User Control and Flexibility

• Do users need the ability to trigger synchronization manually?
• Is there a requirement for users to schedule or customize integration runs?

10. Latency Tolerance

• What is the acceptable delay between an action occurring in one system and its effect being visible in another?
• Are there any processes that require near-instantaneous updates across systems?

Here’s a brief explanation of how to interpret the answers:

User action-driven architecture may be more suitable if:

• Users frequently interact with the system and expect immediate feedback
• Real-time data synchronization is critical for user workflows
• The data volume is relatively small and can be processed quickly
• The system needs to handle a moderate number of concurrent users
• Business processes require immediate action on data changes

Event-based architecture may be more appropriate if:

• Data updates occur frequently or in large volumes
• The system needs to handle high loads or traffic spikes
• There are multiple systems involved in the integration
• Batch processing is more cost-effective
• The business can tolerate some delay in data synchronization

Hybrid approach might be best if:

• Some processes require immediate action while others can be batched
• Users need real-time updates for critical data but can wait for less important information
• The system needs to balance responsiveness with efficient resource utilization
• There’s a mix of high-volume background processes and low-volume user-triggered actions
• Varied user expectations: Some operations require immediate feedback, while others can be processed asynchronously.
• Mixed data processing needs: The system handles both small, urgent updates and large batch operations.
• Fluctuating system load: There are periods of both low and high system usage.
• Complex integration landscape: Multiple systems are involved, each with different capabilities and constraints.
• Diverse business processes: Some processes need real-time action, while others can be batched.
• Tiered error handling: Different types of errors require varying levels of immediacy in response.
• Resource optimization requirements: The need to balance real-time processing with efficient resource utilization.
• Comprehensive monitoring needs: Both immediate alerting and long-term trend analysis are required.
• Flexible user control: A combination of automated processes and manual user controls is necessary.
• Variable latency tolerance: Different operations have different acceptable delay times.

It’s important to understand that these are general guidelines, and that the best architecture for your project will always depend on the specific requirements and constraints involved. It is also helpful to prototype or test different approaches to see which one performs best in your particular use case.

Summary

The key reasons for using each type of approach are:

Performance: Event-driven systems generally offer better performance at scale, as they can optimize resource usage and handle peak loads more efficiently.

User experience: User action-based systems provide immediate feedback, which can be preferable for certain interactions. However, event-driven systems can offer a smoother experience for complex or time-consuming operations.

Scalability: Event-driven architectures typically scale better, especially for systems with high transaction volumes or complex workflows.

Development complexity: User action-based systems can be simpler to implement initially, but event-driven systems often provide more flexibility and are easier to maintain in the long run.

Error handling: User action-based systems may provide more straightforward error handling and recovery, as errors can be immediately reported to the user. Event-driven systems require more careful consideration of error states and recovery processes.

Data consistency: User action-based systems can provide stronger guarantees of data consistency at the cost of performance. Event-driven systems may operate with eventual consistency, which can be more performant, but requires careful design to handle potential inconsistencies.