Customer architecture
Which customer domains are active, which sources make them trustworthy, and the shared Party master.
Revenue is the first operating layer of your customer architecture. Customer architecture (/app/settings/customer-architecture, admins) describes how Sales, Marketing and Service fit together around one shared customer identity.
Overview
See which customer domains are active, planned or intentionally not used, and which sources make each one trustworthy. Cross-domain KPIs stay blocked until Party identity and relationship coverage are verified.
Domain settings
For each domain, set the operating status, the primary source and any supplemental inputs. This is a workspace-admin decision: it changes how the architecture is described, not what a provider can do, and it does not change existing Revenue mappings. Setting domains is optional and does not block Revenue setup.
Master data (/customer-architecture/master-data)
One Party master connects commercial relationships across Sales, Marketing and Service. Source records stay source-owned; every canonical decision is reversible and traceable.
| Area | What you do there |
|---|---|
| Candidates | Review identity candidates. Fuzzy evidence creates candidates; only validated strong identifiers can auto-link. |
| Profiles | Promote a draft profile once identity, classification and source evidence are understood. |
| Attributes | Configure reliability per attribute — it is not inherited from a domain's primary source. |
| Hierarchy | Legal entities and enterprise groups are classifications on Organization Parties; effective dates prevent silent hierarchy drift. |
| Write-back | Admins control policy; stewards preview and approve individual changes. Write-back stays fail-closed. |
Stewardship (/customer-architecture/stewardship)
Review merges and duplicates that need a decision.
Advanced multi-source mastering, governance and lineage are part of Blocchi Data+.
Related
Last updated on