One record per real customer, assembled from the ERPs, the CRM and the portals, with every source key kept.
Tables are read in place through the Snowflake connector with filters and aggregates pushed down; nothing is copied out.
| Object | Read from | Fields the domain uses | Freshness |
|---|---|---|---|
| Customer | CONFORMED.CUSTOMER | customer_key · source_system · source_id · name · country · vat_id · postcode | as fresh as the landing pipeline; live for governed tables |
| Sales order | CONFORMED.SALES_ORDER · CONFORMED.SALES_ORDER_LINE | order_id · customer_key · order_date · net_value · status | as fresh as the landing pipeline; live for governed tables |
| Invoice | CONFORMED.AR_INVOICE | invoice_id · customer_key · due_date · open_amount | as fresh as the landing pipeline; live for governed tables |
The first object above carries the strong keys; the standardised attributes come from the same rows. Two records match when a strong key agrees, or when name and address agree closely and no strong key disagrees.
Golden records and their history are written with MERGE into a governed schema, so the warehouse always carries the current keys.
| Interface | Used for | Result |
|---|---|---|
MERGE INTO GOLDEN.CUSTOMER on the golden key; history in GOLDEN.CUSTOMER_HISTORY | golden values approved for write-back: identity; addresses; contacts and roles | the id or error Snowflake returns, stored beside the change |
Write-back is off per object until a test write succeeds, and approval rules can require a person per object. Reconciliation compares the source row with the golden value on a schedule.
Snowflake roles and row access policies are honoured; Lima adds its own layers on top.
Customer on
Other domains on Snowflake
The golden record reads the objects above in place. History the pivot needs at scale is landed in your lake by the Backbone, under the same keys, security and audit.
Grant the read access and the write interfaces listed above and agree the refresh method. Nothing is installed in Snowflake.
Yes. Write-back stays off per object until a test write succeeds; the golden view, the API and the pivots work from day one on reads.
Bring two systems that hold the same customers, suppliers or materials. In one working day we connect them, run the match on live rows, review the queue with your steward and publish the first golden view with its API.
