HCT Architecture & System Design 2 — Questions and Answers
Question 1: When designing a HubSpot portal for a B2B company with multiple business units, which architecture best prevents data cross-contamination between units?
- Use a single portal with custom properties to tag each unit
- Create separate Business Units with distinct branding and user permissions (Correct answer)
- Deploy separate portals per business unit linked via HubSpot Connect
- Segment contacts using static lists per business unit
Correct answer: Create separate Business Units with distinct branding and user permissions
Business Units in HubSpot allow one portal to serve multiple brands with separate assets, users, and reporting without data leakage.
Question 2: A client wants to sync ERP order data to HubSpot deals in near real-time. Which integration pattern minimizes API rate limit exposure?
- Poll the ERP every minute via a scheduled workflow
- Use webhooks from the ERP to push changes to a middleware queue that batches HubSpot API calls (Correct answer)
- Directly call HubSpot's API from the ERP on every order save event
- Import a CSV from the ERP daily via the HubSpot import tool
Correct answer: Use webhooks from the ERP to push changes to a middleware queue that batches HubSpot API calls
A webhook-driven middleware queue decouples the ERP from HubSpot, enabling batching and retry logic that respects HubSpot's rate limits.
Question 3: Which HubSpot object relationship type should be used when a single Contact can be associated with multiple Companies and vice versa?
- One-to-one association with a primary company flag
- Many-to-many association using the native Associations API (Correct answer)
- A custom object acting as a junction table
- Duplicate contact records per company
Correct answer: Many-to-many association using the native Associations API
HubSpot's Associations API natively supports many-to-many relationships between Contacts and Companies with association labels.
Question 4: When should a HubSpot trainer recommend using Custom Objects instead of standard CRM objects?
- When a client needs to store data that has no logical fit within Contacts, Companies, Deals, or Tickets (Correct answer)
- Whenever a client wants additional properties on existing standard objects
- When standard objects exceed their property limits
- To bypass GDPR data retention rules
Correct answer: When a client needs to store data that has no logical fit within Contacts, Companies, Deals, or Tickets
Custom Objects are appropriate when the data entity (e.g., Subscriptions, Vehicles) cannot be accurately represented by any existing standard CRM object.
Question 5: A trainer is evaluating a client's workflow architecture and finds 47 active contact-based workflows firing on the same enrollment trigger. What is the primary risk?
- HubSpot will auto-archive workflows after 30 days of overlap
- Conflicting actions across workflows can create race conditions and unpredictable contact property states (Correct answer)
- Workflows cannot share enrollment triggers in the same portal
- The portal will be flagged for spam by HubSpot's trust team
Correct answer: Conflicting actions across workflows can create race conditions and unpredictable contact property states
Multiple concurrent workflows acting on the same contact properties can overwrite each other's changes depending on execution order, producing inconsistent data.
Question 6: Which approach correctly handles a scenario where a HubSpot form submission should create a deal only when the contact does NOT already have an open deal in a specific pipeline?
- Use a form submission workflow with an 'if/then' branch checking deal association count in that pipeline (Correct answer)
- Set the form to create a deal automatically via the form's deal creation setting
- Use a list membership enrollment trigger instead of a form trigger
- Export form submissions to a spreadsheet and manually create deals
Correct answer: Use a form submission workflow with an 'if/then' branch checking deal association count in that pipeline
An if/then branch inside a workflow can check the associated deal count or stage before conditionally creating a new deal.
Question 7: When architecting HubSpot's data model for a SaaS company tracking product usage, where should recurring subscription MRR data best reside?
- As a Contact property updated monthly
- On the Deal object using a recurring revenue deal type with an associated line item
- In a Custom Object called 'Subscription' associated to the Company (Correct answer)
- In a HubSpot List used as a revenue segment
Correct answer: In a Custom Object called 'Subscription' associated to the Company
A Subscription custom object keeps recurring billing data normalized and associated to the correct Company without polluting Deal pipeline semantics.
When designing a HubSpot portal for a B2B company with multiple business units, which architecture best prevents data cross-contamination between units?