HubSpot Industry System Integrations
An industry system is not a general tool configured for a sector. It encodes how that sector operates, which means its object model is the sector's object model and mapping it onto a CRM is a translation rather than a field exercise.
A matter is not a deal. A project is not a deal. A policy is not a deal. Each of them has a lifecycle, a set of participants and a regulatory context that a deal object does not carry, and flattening one into the other loses exactly the information the business runs on.
14 systems in this category, 4 of them documented in a published case study.
Translating an industry object model onto a CRM
The first decision is which object the industry record corresponds to, and often the answer is that it corresponds to none of the standard ones and needs a custom object.
The second is direction. An industry system usually owns the work. The CRM owns the relationship, and everything that happens before the work starts. Where the industry system is allowed to own the commercial pipeline as well, the CRM becomes a duplicate address book.
The third is confidentiality, and in regulated sectors it constrains the design rather than decorating it. What may cross the boundary is a legal question before it is a technical one, and the answer is frequently that a status may cross and a detail may not.
A regulated sector's object model expressed in CRM objects
Which records may cross the boundary and which are referenced rather than copied
Systems in this category
Documents generated from CRM data, with an approval gate before send.
Envelope state moving the deal rather than a person remembering to.
Matters modelled one-to-many against the engagement, not one-to-one.
Bookings and memberships joined to the customer record.
Policies and renewals surfaced where the relationship is worked.
Enrolment and family records reconciled to one contact.
Donor history joined without overwriting constituent definitions.
Ticketing and attendance resolved to one fan record, with the buyer distinguished from the attendee.
Reservations, stays and guest history joined to the account, with the booker and the guest kept apart.
Documented engagements
Each of these is a published study of one build, with the object model, the decisions taken and what the approach does not establish.
- PandaDocDocuments generated from CRM data, with an approval gate before send.
- ClioMatters modelled one-to-many against the engagement, not one-to-one.
- SeatGeekTicketing and attendance resolved to one fan record, with the buyer distinguished from the attendee.
- NewbookReservations, stays and guest history joined to the account, with the booker and the guest kept apart.
Common Questions
Frequently Asked Questions
The industry system almost always owns the work and the CRM owns the relationship and the pipeline before work begins. Attempting to run the commercial process inside a practice management system usually produces neither a good pipeline nor a good matter list.
Where the industry record has a lifecycle of its own and there may be several per client, yes. A matter, a policy and a property each behave that way. Forcing them into deals works until the second one exists for the same client.
It is a design constraint decided before anything is built. In several sectors the defensible position is that a status, a date and an owner may cross into the CRM while the substance stays in the system built to hold it under the relevant obligations.
Further reading
Long-form already published on the argument this category turns on.
Related categories
A system in this category that is not listed
The directory shows range rather than limits. A scoped build is quoted from the object model on each side and the fields that have to cross between them.