What is a customer hub?

Customer hub, defined

People ask this as: what is a customer hub, single view of the customer across crm records

A customer hub connects the records of one customer commercial lifecycle. Accordo combines an audited record chain with a bounded Customer Data Foundation: JSON imports, deterministic matching, human-governed logical identity and a consolidated profile across composed packages. It is not a full CDP or a complete cross-channel timeline.

Where this stops

Read this before the rest of the page. Every line below is a thing this does not do.

  • This page defines the term. It does not claim Accordo ships a finished customer hub product — the concept page for customer hub carries that argument with each domain's status attached.
  • Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search (L-06).
  • Customer Data Foundation provides a consolidated profile and Admin surface. It reports absent packages as unavailable and is not a complete cross-channel timeline.
  • A customer hub is not a customer data platform. The profile-hub reading belongs to a different category this framework explicitly refuses.
  • None of it is deployable: no authentication ships, and a deployment must supply the verifier (L-01), and no export or erasure path, so real customer data does not belong in it (L-09).

No authentication ships: the framework authenticates nobody. Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim. Every claim and every limitation is on one page.

The definition, and its three readings

A customer hub is a system where one customer's commercial records are connected rather than scattered: the quote knows its opportunity, the contract knows its order, the support case knows its entitlement. The value of the term is navigational — from any record you can reach the rest of the customer's history by following identifiers instead of re-keying names into other tools.

The phrase can mean a profile assembled across systems, an interface over tools, or a commercial record chain. Accordo supplies the chain plus a bounded customer foundation; that combination is not a full CDP.

The record-chain reading, as Accordo implements it

In an Accordo application the chain is written by the actions that move the process. A lead converts atomically into a Company, a Contact and an Opportunity through explicit, audited actions (C-06); a signed Order activates into a Commercial Contract that carries the orderId, quoteVersionId, opportunityId and companyId it descended from (C-10); delivery and service records carry the contract and company they serve. Every one of those identifiers is managed storage written by the framework, never a value a client supplied, and every mutation leaves an audit event and a step-level trace (C-16).

Customer Data Foundation reads a consolidated profile across composed packages and exposes an Admin surface. Canonical identity remains a logical link; no physical merge, global search or complete cross-channel timeline is supplied.

What this definition excludes

Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search (L-06). The profile reads composed package records; it does not ingest every external channel or infer a probabilistic identity graph.

The deployment reading is excluded too. A hub built here runs on one developer's machine: no authentication ships, and a deployment must supply the verifier (L-01), and no way to service a data-subject access or deletion request, which is why real customer data does not belong in it (L-09). For the fuller argument about what a hub built on this foundation is and is not, the customer hub concept page carries the commercial version of this definition with every status quoted from the catalogue.

The evidence this page rests on

Claims and limitations are printed from site/claims.json word for word. Job statuses come from docs/benchmarks/jobs.json; a job with no page of its own is listed with its status rather than linked.

Claims

  • C-06 A lead is captured, scored, routed, qualified and converted into Company, Contact and Opportunity through explicit actions, each one atomic and audited.

    LimitEnrichment runs against a fixture provider — no real external data source is wired. The Lead model is the starter's, not a built-in core module.

  • C-10 A signed Order activates into a Commercial Contract, an immutable contract version, a Subscription and explicitly pending delivery and service obligations — every component classified, never guessed.

    LimitTerms frozen into the signed quote document retain signed-order provenance; legacy orders without signed terms can use explicitly labelled post-signature operational metadata. Operational dates are never promoted to signed terms. Governed renewal and amendment execution creates a successor agreement from its own signed Order, with immutable lineage and a derived line delta. Historical contracts and subscriptions are not edited. There is no automatic renewal, cancellation execution, billing or customer notification.

  • C-16 Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it.

    LimitAudit records what the process did under an asserted actor. It is not a tamper-evident or externally attestable log, and it is not a compliance control.

Limitations

  • L-01 No authentication ships: the framework authenticates nobody. Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.
  • L-06 Bounded customer imports and logical identity; incomplete data operations. Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search.
  • L-09 Personal-data readiness requires deployment work beyond the foundation. Customer Data Foundation supplies bounded import and identity governance, not complete personal-data operations. Authentication must be supplied by the deployment, and complete subject export and erasure remain absent; the framework alone does not establish compliance or suitability for real customer data. Lead scoring remains deterministic, versioned and explainable.

Jobs it covers

Documented in

Proved by