Most Reltio problems are not platform problems. They come from decisions made early in the project, often without much thought: how source records are keyed, how loosely match rules were written to hit a deadline, which value wins when two systems disagree, and whether anyone can tell what changed in the configuration last month.
None of these show up in a demo. They show up after go-live, as a steward queue that never shrinks, a false merge that reaches the CRM, or a new source that takes a quarter to onboard.
This guide covers the practices we follow on every Reltio implementation. They are opinions, formed from projects in life sciences, healthcare, insurance and energy, and you should adapt them to your own data.
Start with the decisions, not the configuration
Before anyone opens the Console, write down three things for each domain you plan to master:
- What counts as the same entity. Is a customer a person, a household, or an account? Is a healthcare provider the individual, the practice location, or both? Two teams that disagree on this will build match rules that fight each other.
- Who owns the data. Name a business owner for each domain. They approve match thresholds and survivorship, and they decide when a disputed merge is right.
- Who uses the mastered record. List the systems and reports that will read golden records, and what each one needs. This drives the data model and the integration design more than the source systems do.
These answers fit on a page. Without them, every configuration question turns into a meeting.
Keep the data model close to the business
Reltio models data as entity types, relationship types, and interactions, with attributes on each. It is tempting to copy the structure of the biggest source system into the tenant. Resist that. Source systems change, and a model shaped around one of them makes every other source harder to onboard.
Some practices that hold up:
- Model the entity, not the source. Attributes should describe the customer, product, or supplier in business terms. Source-specific codes belong in reference data, mapped to one standard list.
- Use relationships for real relationships. An organization’s locations, a provider’s affiliations, and a contact’s role at an account are relationships. Packing them into nested attributes on one entity makes them hard to match, survive and query.
- Add attributes when a consumer needs them. Every attribute has to be mapped, cleansed, survived and tested. Loading a field “in case someone wants it” adds work on every release.
- Manage code lists as reference data. Country, state, specialty and status codes should map from each source’s values to one canonical list, so match rules and downstream systems see one value, not five spellings of it.
Treat crosswalks as the foundation
Every source record in Reltio is tied to its entity through a crosswalk: the source system and the record’s key in that system. Crosswalks are how Reltio knows which record to update when the source changes, which values came from where, and what to separate if a merge has to be undone.
Get them right early, because they are painful to change later:
- Use a stable source key. The crosswalk value should be the source system’s own primary key, the one that never changes for the life of the record. Avoid keys that are built from names, emails or other values that get edited.
- Register each source separately. Two systems that happen to share a database are still two sources if they have different owners, update rules or trust levels. Survivorship and lineage both depend on the distinction.
- Plan for deletes and deactivation. Decide what happens when a record disappears from a source. Ending the crosswalk, flagging the record inactive, and leaving it alone all have different effects on the golden record, and the choice should be deliberate.
Prove match rules before you trust them
Matching is where most Reltio projects spend their effort, and where most of the risk is. A false merge joins two different customers into one record, and once other systems have used that record it is hard to unpick, even though Reltio can unmerge it. A missed match is cheaper: two records for one customer, which stewards can catch over time.
So build matching around that difference:
- Test against your own records. Build a labeled sample of a few hundred pairs, marked same or different by people who know the data, and include the hard cases on purpose. Measure every rule change against it.
- Cleanse before you compare. Normalize case, phone formats, email quirks, nicknames and addresses so that rules compare like with like. Many hard matches become easy once both values are written the same way.
- Keep match tokens selective. Tokens decide which records get compared at all. A token that groups thousands of records together, such as a common surname on its own, slows matching and produces weak candidates. Combine attributes so each token group stays small.
- Use automatic merges sparingly. Reserve automatic match rules for evidence that is close to certain, such as a shared, validated identifier. Send everything else to stewards as a potential match until the labeled sample shows it can be trusted.
- Write hard rules for what must never merge. Two records with different tax IDs or license numbers should not merge however similar the names are. Make that a rule, not a hope.
- Add machine learning carefully. If you use FERN matching, start it in scoring mode alongside your rules, and only let the top band auto-merge once steward decisions show where it is reliable.
Set survivorship with the data owner
When sources disagree, survivorship decides which value appears on the golden record. Reltio lets you set a strategy per attribute: the most recent value, the value from the most trusted source, the most frequent value, and others. Using one default for everything is the easiest way to end up with golden records nobody believes.
Agree survivorship attribute by attribute with the data owner. A legal name may come from the most trusted system of record. A phone number may be best taken from whichever source updated it last. A marketing preference should come from the system where the customer actually set it. Write the reasons down, because someone will ask why a value won, and “the configuration says so” is not an answer.
Keep the losing values. They are useful for stewardship, for audit, and for spotting a source that keeps sending bad data.
Design stewardship as a workload
Data stewards are the people who keep the tenant honest, and their time is limited. Plan their work the way you would plan any operational team:
- Size the queue before go-live. Run the match rules against a full load in a lower tenant and count the potential matches. If the queue is bigger than the stewards can clear, tighten the rules or the scope before you launch, not after.
- Route work to the people who know the data. Provider records should reach someone who understands provider data. Use workflow and data change requests so edits are reviewed, not just made.
- Make decisions stick. When a steward marks a pair as not a match, that decision should hold on every later load. Check that it does as part of testing.
- Feed decisions back. Steward decisions are the best labeled data you will ever get. Add them to the match test sample so rule changes are measured against them.
Integrate around events, not extracts
A golden record only has value if other systems use it. The common failure is a hub that holds good data while every downstream system keeps its own copy, refreshed by a nightly extract that nobody monitors.
- Use the right path for each job. Bulk loads suit initial migration and large backfills. The APIs and Reltio’s integration tooling suit real-time creates and updates. Event streaming suits keeping downstream systems in step with changes, including merges and unmerges.
- Handle merges and unmerges downstream. When two entities merge in Reltio, the systems that hold references to the losing entity ID need to know. Design for this early. It is the integration detail most often missed.
- Land mastered data in the warehouse. Analytics and AI teams should read golden records from Snowflake or Databricks, not rebuild matching on their own. Treat that feed as a product with an owner and quality checks.
- Load at real volume before go-live. Test the full initial load and a realistic daily change rate in a lower tenant. Matching and indexing run after records land, so measure how long the tenant takes to settle, not only how long the load takes.
Run configuration like code
A Reltio tenant’s configuration covers the data model, match rules, survivorship, validation and more. It changes constantly after go-live, and it is easy to lose track of who changed what.
- Keep configuration in source control. Export it, review changes as pull requests, and promote the same configuration from development to test to production tenants. Avoid hand edits in production.
- Test every change against the same checks. Rerun the match test sample and the data quality checks on each release, and block a release that adds false merges.
- Know what a change triggers. Some changes, such as new match rules, need existing records to be rematched or reindexed before they take effect everywhere. Plan that work and its timing into the release, especially on large tenants.
- Keep lower tenants useful. A test tenant with a few hundred synthetic records will not reveal matching or performance problems. Refresh it with a representative, appropriately masked set of real data.
Onboard one source at a time
Loading every source at once makes it impossible to tell which one caused a matching problem. Start with the most trusted source to establish a clean base, then add the others one by one. For each new source, measure what it adds: how many records match existing entities, how many are new, and how many go to stewards. If those numbers look wrong, stop and find out why before adding the next source.
This also gives the business something useful early. A first domain with two sources, live and trusted, does more for an MDM program than five domains half finished.
Measure the tenant after go-live
Agree a short list of measures with the data owners and review them regularly:
- false merges found, and how they were found
- the size and age of the steward queue
- data quality rule results by source
- how quickly changes reach downstream systems
- how long a new source takes to onboard
These numbers tell you whether the tenant is getting healthier or slowly drifting, and they make the case for the next phase of work.
Summary
A good Reltio implementation is mostly good decisions made early and kept up afterwards. Agree what “the same” means and who owns it. Key every source record properly. Prove match rules on your own data before they merge anything, and set survivorship with the people accountable for the data. Plan stewardship as a real workload, push changes to downstream systems as events, and manage the configuration like code. None of this is specific to one release of the platform, and all of it is cheaper to do at the start than to retrofit.
We design, configure and run Reltio for customer, provider, product and supplier data. Our Master Data Starter brings data models, match and survivorship rules, a stewardship workflow and a precision check that runs in your pipeline. If you are planning a Reltio implementation, or want a second look at one that is already live, get in touch.
