Skip to content
WealthTech ProsWTP Suitability Report← WTP Docs

ADR-0001: CRM-Bridge Eventual Extraction

Capability: DATA-INGEST-CRM (client-onboarding) · Status: Accepted Repo: suitability-engine

  • Status: Accepted (decision recorded; extraction itself not yet scheduled)
  • Date: 2026-08-16
  • Deciders: Rob Duncan (raised), confirmed in conversation with the user
  • Related: SPEC-153 (client-onboarding/docs/features/153-origo-adviser-crm-api.md), this repo’s own extraction precedent (SPEC-152)

Context

Section titled “Context”

suitability-engine (this repo) was extracted from client-onboarding mechanically — it was already a bounded, UI-decoupled capability, so extraction was “move code, add a read-API seam” (SPEC-152). SPEC-153, the CRM/Adviser API, is a different shape: still draft, only one platform (Plannr) live, inbound-only, cursor-persistence still a known gap. It remains embedded in client-onboarding (packages/datawarehouse/src/DataPump/DataPump.Crm/, DataPump.CrmBridge/).

A second demand signal has now appeared beyond Origo: data-backbone wants the same CRM integration capability as an internal consumer, not just Origo as an external one. Two independent consumers wanting the same capability from two different directions is the same pressure that made suitability-engine’s extraction obviously correct once it appeared — staying embedded in client-onboarding risks the FINIO problem repeating: shared infrastructure quietly gated by one product’s own Pulumi stack, deploy cadence, and CI, for consumers that have nothing to do with that product.

Decision

Section titled “Decision”

CRM-bridge will extract to its own repo — but only once SPEC-153’s bidirectional design has stabilised, not now. Extracting an unfinished, still-single-platform, still-inbound-only design would just relocate something unfinished, per SPEC-152’s own precedent reasoning (“extracting a repo before the bidirectional design is even built would just move an unfinished thing”).

Additional reason to separate, beyond reuse: isolating CRM-bridge into its own repo lets its testing, audit, and robustness posture be optimised independently of client-onboarding’s. A bidirectional integration touching multiple CRM platforms’ live data (webhook signatures, idempotent write-back, per-platform credential isolation) warrants a different rigor bar — and a different release cadence for hardening that rigor — than a single product’s feature velocity should have to accommodate or be constrained by.

Consequences

Section titled “Consequences”

Positive

Section titled “Positive”
  • data-backbone and any future internal consumer have a real target to plan against, rather than either waiting indefinitely or building a duplicate integration in the meantime.
  • CRM-bridge’s test/audit/robustness investment isn’t coupled to client-onboarding’s release cadence once separated.
  • Repeats a proven extraction pattern (SPEC-152) rather than inventing a new one.

Negative / open

Section titled “Negative / open”
  • Not scheduled. This ADR records the decision to extract eventually, not a committed timeline. data-backbone’s own team should not assume imminent availability — this should be communicated explicitly, not left implicit.
  • The trigger condition (“bidirectional design has stabilised”) is not itself precisely defined here — SPEC-153’s own open questions (cursor persistence, Key Vault credential migration, the four-platform capability matrix) are the concrete list to close before this is ripe.
  • Same three-protocol interface question this repo just resolved (REST/ gRPC/GraphQL, see docs/architecture/api-interface-strategy.md) will need repeating for CRM-bridge once its design is stable enough to define a contract against — explicitly deferred, not designed here.