Your CRM should know the customer, not run the product

A CRM is often the first existing system available when a commercial product needs to remember a prospect.

It already has contacts, companies, owners, lifecycle stages, and deals. Adding a few properties for questionnaire progress or report status can look cheaper than building product state somewhere else.

The shortcut changes the product’s failure model. A CRM outage can now interrupt the client journey. Retries can create duplicate records. Questionnaire versions become provider-specific fields. A commercial edit can accidentally overwrite workflow state.

The better boundary is not to remove the CRM. It is to let it own the context it is good at while the product owns the exchange it promises.

Name the two systems of record

For the commercial inquiry design, HubSpot remains authoritative for CRM identity and commercial context:

• contacts and companies;
• commercial owner and lifecycle stage;
• qualification and deal context; and
• associations used by the sales process.

The product remains authoritative for its operational workflow:

• inquiry identity and lifecycle;
• questionnaire definitions, versions, progress, and submitted answers;
• report-generation runs and input snapshots;
• report artifacts and versions;
• delivery attempts, failures, and retries;
• privacy evidence; and
• synchronization state between the two systems.

This is not duplicated ownership. It is field-level authority.

Do not put the provider in the request path

The public form submits to the product, not directly to HubSpot.

After validating the request and recording the inquiry, the platform durably queues a CRM synchronization operation. A temporary CRM outage can set the sync state to pending or failed without losing the inquiry or asking the prospect to start again.

The questionnaire and asynchronous report continue under the product’s own lifecycle. When relevant milestones occur, an outbox sends the minimum commercial summary HubSpot needs.

This makes availability honest. The product cannot promise that CRM context is immediately current during an outage, but it can preserve the user’s work and reconcile later.

Bidirectional does not mean symmetrical

The platform sends identified inquiry context, selected providers, assessment status, qualification summary, and a controlled report reference to HubSpot. It does not copy every answer and artifact into CRM by convenience.

HubSpot can return owner, company, association, lifecycle, and deal context that improves authorized follow-up. Webhooks carry relevant changes, while polling provides reconciliation rather than becoming the primary integration.

The two directions still obey different field authority. A source marker and per-field policy prevent sync loops:

• a CRM-owned lifecycle field is not overwritten by a stale product snapshot;
• a product-owned report state is not replaced by an incidental CRM edit; and
• cross-system identifiers remain opaque integration references, not public URLs.

Bidirectional synchronization is useful only after ownership is asymmetric and explicit.

Never ask twice is a data contract

Reusing information sounds like a user-experience rule: if a prospect already selected their cloud providers and described their estate, do not request the same answers during a deeper audit.

Delivering that promise safely requires more than prefilled form fields.

The shared model must preserve:

• which tenant and inquiry supplied the information;
• which questionnaire version gave the answer meaning;
• when and for what purpose it was collected;
• which consent or lawful basis applies;
• whether the value is self-reported or derived from provider evidence; and
• which later product operation is allowed to use it.

An approximate estimate from an inquiry and an audit-derived estimate may be two fidelities of the same concept. They should reconcile without pretending they carry equal evidence.

Continuity is valuable because provenance survives, not because every system can copy the latest value.

Asynchronous work needs a durable lifecycle

Generating a report inside the form request couples the prospect to calculation, document rendering, storage, email, CRM, and notification latency.

The accepted design instead snapshots the submitted answers and questionnaire version, then starts an idempotent generation run. Report delivery and internal notification are separately observable and retryable.

The lifecycle includes successful states such as submitted, generating, report-ready, delivery-pending, and delivered. It also names CRM sync, generation, and delivery failures rather than collapsing them into a spinner.

Repeated events must not create a second contact, generation run, report, email, or notification. Idempotency is part of the commercial experience even though the user never sees the key enforcing it.

Minimize what crosses the boundary

The CRM needs enough context for accountable follow-up. It does not need the full questionnaire, report, privacy record, or every operational event.

Data minimization improves more than compliance. It reduces schema coupling, limits what must be reconciled, and makes ownership easier to explain when a customer asks where information lives.

The same rule applies in the other direction. The product may use authorized CRM context without cloning the entire sales database.

A useful integration can still be a design

The inquiry lifecycle, HubSpot boundary, and shared model are accepted decisions in the DS documentation. They describe a coherent product contract. They do not establish that the complete journey is integrated, deployed, or used by customers.

That distinction makes the architecture more useful, not less. It gives a future implementation a clear test: disconnect the CRM, submit an inquiry, complete the questionnaire, generate the report, restore the integration, and prove that one commercial record reconciles without losing or duplicating the product workflow.

If the system cannot pass that test, the CRM is still running part of the product.