Request a Demo
OverviewCapabilitiesData qualityDomain catalogueBy roleBy industryCompareMigrateOutcomesResources
Capabilities Integration and sync

Four ways to run a domain, one model underneath.

A domain can run as a registry (a golden view over the sources, nothing copied), a consolidation (golden records materialised for analytics), a coexistence (maintained here and written back to the systems) or centralised (authored here first, then published).

Request a demoSee the connectors
Registrygolden view over thesources; nothing copiedConsolidationgolden records materialised foranalyticsCoexistencegolden records maintained hereand synced backCentralisedrecords authored here first,then publishedswitch a domain from registry to coexistence by turning on write-back; the model, the rules and the history staya company can run customers as coexistence, products as centralised and reference data as registry, side by side
The four implementation styles on one bed. A company can run customers as coexistence, products as centralised and reference data as registry, side by side.
4
implementation styles, chosen per domain
product
60
connectors in the library
connector library
off
write-back per object until a test write succeeds
product
100%
of writes acknowledged and logged
product
2
environments with a promotion gate
product
Step by step

How a change reaches the systems that need it

Whichever style a domain runs in, a change follows the same path.

Golden recordchanged or approvedSAPBAPI · IDocOracleREST · interfacesSalesforcesObject upsertLakesMERGEOtherswebhook · fileacknowledgement stored beside the change · reconciliation shows it arrived · replay on failureoff per object until a test write succeeds; approval rules per object; the source's own validation runs first
A golden change goes out the way each system accepts it, and the acknowledgement is stored beside the change.
A change is approvedA steward approves a merge, a rule fixes a value, an agent's proposal passes its threshold, or a user edits a cell with write permission.
Per system

The write path for each system, and what is set up first

Reads use released interfaces and change capture where allowed; writes use the interfaces the vendor supports.

SystemReadWriteRefresh
SAP S/4HANA and ECCreleased read interfaces; change capture where the basis team allows itBAPIs and IDocs (business partner, material, BOM, conditions, cost centres, bank details)live; minutes with change capture
Oracle Fusion CloudREST resources; BI Cloud Connector extracts for volumeREST resources; import management (FBDI) for volumelive through REST; extracts on schedule
Oracle E-Business SuiteJDBC in parallel partitions; last-update columnsopen interface tables and public APIsminutes to hours
SalesforceREST and Bulk APIs; Change Data Captureupsert on an external idlive; minutes with CDC
Workdayweb services and RaaS reportsPut operations with reference idslive through web services
ServiceNowTable API; exportsTable API; Import Sets with coalescelive; polled or event-driven
Snowflake · Databricks · Fabricin place, with pushdownMERGE into a governed schemalive for governed tables

Every catalogue entry names the objects and the interface per system, for example supplier on SAP S/4HANA or customer on Oracle Fusion.

Environments and versions

Configure and test in one environment, promote to production with an approval

Every domain configuration is a version with a change note: model, keys, rules, thresholds, hierarchies, security. A version is tested against live rows in the configuration environment and promoted to production through a gate that checks the rule results, the security matrix and the write-back test per object.

Running processes finish on the version they started on; new runs use the new version. A version can be withdrawn; the previous one takes over. The deployment page covers the three ways to run the platform.

Versionseach publish carries a note; append-only
Environmentsconfigure and test, then production; promotion gate
Write-backoff per object until a test write succeeds; approval rules per object
Reconciliationscheduled reads compare source and golden values
Replayfailed writes keep their error and replay after the fix
Rollbacka version can be withdrawn in one click
Terms on this page

RegistryA golden view over the sources with nothing copied; the sources keep their own records.
ConsolidationGolden records materialised for analytics and reporting; the sources keep their own records.
CoexistenceGolden records maintained in Lima and written back to the systems that own them.
CentralisedRecords authored in Lima first and published to the systems.
Promotion gateThe checks a version passes before it reaches production.
Questions

Can a domain change style later?

Yes. Registry to coexistence is a matter of enabling write-back per object after a test write; the model, rules and history stay.

What if a source refuses a write?

The error is stored beside the change, the write stays in the queue, and the steward sees it. Nothing is retried blindly.

How do planning systems get the golden records?

Through the Backbone's planning integration: the golden dimensions and hierarchies are loaded in the target's model with the nine checks, and the plan comes back. See planning integration.

See your first domain built on your data

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.

Request a demoHow the first day runs