Reltio Implementation Best Practices: A Technical Blueprint for Multidomain MDM That Holds Up in Production

Reltio implementations fail in a narrow and predictable band, and almost never because the platform could not do the thing. They fail because the programme signed off a data model before it had agreed what a customer is. Because matching was switched on before anyone could measure whether it was right. Because survivorship was left at its default and, four months later, every downstream consumer turned out to be reading the most recently loaded value as though it were the truth. The technology is mature and well documented. The failure modes are organisational decisions expressed in configuration, which is why they survive code review.

This paper is a working blueprint for implementing Reltio well: tenant topology and the promotion path, model design, source onboarding, load sequencing, match rule design and measurement, survivorship, stewardship and workflow, extension points, downstream contracts, and the non-functional track that most plans skip until user acceptance testing embarrasses them. It is written for the architect who has to sequence the work, the delivery lead who has to size it, and the data owner who has to sign that the consolidated view is defensible. It assumes you already know what a crosswalk, an entity type and an operational value are. Where the guidance turns on platform specifics that move release to release, it says so rather than pretending an article can substitute for the current documentation and your own sandbox.

1. The ground has moved. Most of it does not change your plan.

SAP announced its intent to acquire Reltio on 27 March 2026 and completed the acquisition on 7 May 2026. SAP's stated logic is that Reltio becomes a core capability inside Business Data Cloud, unifying SAP and non-SAP data so that agentic workloads have something trustworthy to stand on. That is a coherent thesis and it has already changed the tone of every Reltio conversation we are in. It has changed remarkably little about how you should implement the platform this quarter.

What has genuinely changed is the product's centre of gravity. The 2026.1 line, generally available from 24 April 2026, is unambiguously agentic: AgentFlow Unstructured turns PDFs, Word files, scanned documents and HTML into governed profile context through LLM-powered extraction with human validation; Agent Builder lets teams author custom agents with mandatory approval workflows before publishing; Profiler assesses a source's quality and schema alignment before you load it, with optional auto-mapping to your model. Segmenter and agent task management are in early access. Identity Builder is in limited availability on AWS, and the integration surface has widened with zero-copy interaction ingestion from Databricks and a direct Confluent Cloud Kafka integration.

The implication for an implementation is worth stating plainly, because it cuts against the marketing instinct. Every one of those capabilities assumes your model is coherent and your match quality is measured. An agent that proposes attribute values from an unstructured document is only as safe as the survivorship rules that decide whether its assertion wins. A profiler that auto-maps a source to your model is only useful if the model is worth mapping to. Agentic features amplify whatever discipline the programme already has. They do not supply it, and a team that reaches for them to escape a modelling argument will ship the argument to production with a confidence interval attached.

For programmes already in flight, the acquisition is mostly a set of watch items rather than a replan trigger. The one substantive design question it introduces is whether your target architecture should now assume an SAP-adjacent consumption path that it previously did not.

The rest of this paper assumes you are implementing Reltio, or re-platforming onto it, and that you want the result to still be defensible in year three.

2. What a Reltio tenant actually is

Most design mistakes in Reltio trace back to a single misunderstanding, so it is worth being explicit about the mechanic that makes the platform different from a relational hub. Reltio does not overwrite. Every value every source has ever asserted is retained against the crosswalk that asserted it, and the consolidated profile the business sees is computed at read time from those assertions according to your survivorship configuration. Nothing is destroyed by a merge; a merge changes which crosswalks belong to which entity. That is why unmerge is possible at all, and it is why a badly configured survivorship group can make a technically perfect load look like data corruption.

The L3 configuration is the centre of the diagram and the centre of the programme. It is a single versioned JSON document that defines entity types and their attributes, relationship types, match groups and their comparison formulas, survivorship groups and strategies, cleansers, and the lookup behaviour that binds attributes to reference data. It is not a schema in the relational sense; it is the executable specification of your organisation's opinion about its own data. Treat it as source code from day one, because within six months it will be the only artefact that explains why the platform behaves as it does.

The match engine deserves early attention for a structural reason rather than a quality reason. Matching in Reltio is a two-stage process: tokens narrow the universe to plausible candidates, then the comparison formula in each match group adjudicates a candidate pair to true, false, or a relevance score. The consequence is operational rather than theoretical. Because tokens are materialised, any change to your rules requires the tenant to be retokenised and reprocessed through a rebuild of the match table. That job's runtime scales with your profile count, and it is the single most under-planned dependency in a Reltio schedule. A team that expects to iterate match rules weekly needs to know what a rebuild costs in wall-clock hours on their own data volume before it promises anyone a tuning cadence.

Two capabilities on the diagram are routinely discovered late and then rushed. Reference Data Management is the canonical home for code lists and cross-source mappings, and teams that skip it end up expressing country, status and classification mappings as bespoke transformation logic in five different ingest pipelines, each drifting independently. Lifecycle Actions are Java artefacts, self-contained JARs built against the lifecycle framework, and every one of them is a permanent commitment to a build pipeline, a test harness and a person who understands it. Section 11 argues for a much higher bar before the first one gets written.

Finally, note what is not in the diagram: infrastructure. You do not tune a JVM, size a cluster or schedule a reindex window at two in the morning. In exchange you design within published platform limits, and you accept that some remediation paths require a support ticket rather than a script. That trade is almost always favourable, and it is only unpleasant for teams that discover the limits during a load test rather than during design. Section 13 exists because that discovery is usually late.

3. Tenant topology and the promotion path you will wish you had built

Decide your tenant topology in week one and write down the rule for what each tenant is allowed to contain, because the failure mode here is slow and expensive. Three tenants is the practical minimum: a development tenant where the model changes daily and the data is small and synthetic-plus-sample, a test tenant that holds a production-representative volume and is the only place where match tuning results mean anything, and production. Teams under regulatory pressure add a fourth for training or for a masked data-subject-request rehearsal. Teams that try to save money by tuning match rules in a development tenant with fifty thousand records will ship rules that behave differently at ten million, because token selectivity is a function of data volume and distribution, not of rule syntax.

The more consequential decision is how configuration moves between those tenants. Reltio configuration is promotable through its configuration APIs, and a mature programme treats every promotable artefact as code in Git with a pipeline that applies it. What catches teams out is the asymmetry: most things can be promoted, a few cannot, and one category behaves badly when overlaid rather than replaced.

One practice pays for itself repeatedly and costs almost nothing: make the pipeline export the target tenant's live configuration before every apply, and store that export as the rollback artefact. Reltio's configuration APIs make this a few minutes of work, and the first time a survivorship change behaves unexpectedly in production you will recover in ten minutes rather than reconstructing intent from a Confluence page written three months ago.

4. The L3 is a product, not a document

Every Reltio programme has a modelling phase, and the honest description of what goes wrong in it is over-modelling. A modelling workshop is a room full of people who each know a real edge case, and the path of least resistance is to add an attribute for every one of them. Six weeks later the entity type has four hundred attributes, ninety per cent of which have never been populated by any source, and the steward UI is unusable because the layout has to show them all. The attribute count also matters technically: object size drives the batch size you can push, and section 6's loading guidance changes materially past three hundred attributes.

The discipline that works is to give every attribute an owner and a consumer before it exists. If nobody can name the downstream process that reads it, it does not go in the first release. This sounds bureaucratic and it is the cheapest control available, because removing an attribute after go-live means auditing every crosswalk that populated it, every survivorship group that references it, and every consumer that may have started reading it opportunistically.

Three structural choices deserve more argument than they usually get. The first is nested attribute versus separate entity with a relationship. The test is not conceptual tidiness, it is whether the thing has an independent lifecycle, its own identity across sources, or its own match requirement. An address is nested. An employer is an entity. A licence with its own expiry, issuing authority and renewal workflow is an entity even when it feels like a property of the person, because the moment you need to match licences across two regulators you will need it to have been one.

The second is what belongs in reference data rather than in free-text attributes. Anything with a controlled vocabulary that more than one source expresses differently belongs in RDM with per-source mappings, and the list of such things is longer than teams expect: country, state, status, salutation, specialty, industry classification, channel, consent purpose, relationship type. Expressing those mappings in ingest logic instead is the most common source of the phenomenon where two sources agree on a fact and the platform still shows a conflict.

The third is relationship modelling, which is where multidomain programmes either earn their premium or quietly abandon it. Reltio's graph is genuinely useful for hierarchy traversal, household and affiliation logic, and influence networks, and it is also the part of the model that grows fastest without anyone deciding to grow it. Decide explicitly which relationships are mastered in Reltio and which are merely reflected from a system that owns them. A relationship the platform does not own but does store will drift, and the drift will be discovered by a business user, not by a monitor.

Finally, version the model as a product with a release cadence rather than a ticket queue. Publish a changelog that a business audience can read, hold a fortnightly change forum with the data owners, and require that every model change name the match, survivorship and downstream implications it carries. The 2026.1 profiler will happily propose an auto-mapping from a new source into your model; that proposal is a starting point for the forum, not a substitute for it.

5. Sources, crosswalks, and the register that keeps everyone honest

A crosswalk is the platform's memory of who said what. Get the source taxonomy wrong and every subsequent decision inherits the error, because survivorship, lineage, data subject requests and steward trust all resolve through source identity. The recurring mistake is granularity: treating a whole ERP as one source when three of its modules have materially different data quality, or splitting one CRM into six sources because six teams use it. The rule that holds up is that a source is the narrowest unit for which you would ever want to express a different survivorship priority or a different trust level. If you would never treat two feeds differently, they are one source.

Before a single record is loaded, maintain a source register that the data owners actually sign. It is a small artefact with a large effect: it converts arguments about whose data wins from a corridor conversation into a documented decision with a date on it.

The register's most valuable row is the one about known defects, because match rules are designed against real data pathologies rather than against a clean schema. Placeholder values are the classic case. If forty thousand records in a source carry noreply@example.com, an email-based match rule will collapse forty thousand distinct people into one profile the first time it runs, and it will do so at three in the morning during the initial load. The remedy is not a clever comparator; it is a documented ignore list applied at tokenisation, plus a profiling step that finds the next such value before it finds you. The 2026.1 Profiler agent is genuinely useful here, and it is a faster first pass than a hand-written profiling notebook, provided a human reads what it produces.

Onboard sources in an order that reflects trust, not politics. The first source in should be the one you understand best and trust most, because it establishes the baseline against which every later source's contribution is judged. Loading the messiest source first, on the reasoning that it needs the most work, means every early match result is confounded and the team loses the ability to attribute a quality change to a cause.

6. Load first, match second. This is not a shortcut.

The most useful counter-intuitive instruction in the Reltio operating manual is to load large datasets with matching and merging disabled, then reinstate the rules and rebuild the match table afterwards. Teams resist this because it feels like deferring the interesting part, and because a plan that says “load ten million records, then run a rebuild” looks slower on a Gantt chart than one that says “load and match in one pass.” It is not slower. Matching during a bulk load means every incoming record is adjudicated against a partially populated tenant, which produces match decisions that are a function of load order. Load order is the least meaningful variable in your entire architecture, and letting it determine which profiles merged is how programmes end up unable to explain their own data.

The same rule applies to any incremental load large enough to change the shape of the tenant. A migration that adds a source doubling your profile count is an initial load wearing a delta's clothing, and it deserves the same disable, load, rebuild sequence. Genuine steady-state traffic is different: records arriving in real time from applications, and edits made by stewards in the Hub, should flow through cleansing and matching normally. That is the state the rules were tuned for.

Throughput is then a question of object size, and the platform's guidance is specific enough to plan against. Reltio's documented recommendation scales batch size and parallelism inversely with object complexity.

Around that table sit four engineering habits that separate a loader you can operate from one you babysit. Pool your HTTP connections rather than opening and closing one per record. Retry with exponential backoff on any non-200, and retry only the records that failed rather than the whole batch, which requires the loader to parse per-record responses instead of treating the POST as atomic. Route permanent failures to a dead letter queue with the original payload and the full response, because a failed record without its response body is an investigation you cannot finish. And treat HTTP 429 and 503 as the platform telling you the tenant's concurrency ceiling has been reached: the correct response is to slow down, not to add threads.

Choose the loading mechanism per source rather than picking one for the programme. The Console Data Loader is the right tool for a one-off file, an early exploratory load or a business-user-supplied spreadsheet, and it accepts CSV, Excel and JSON with generous file-size headroom on CSV. Integration Hub earns its place where the source needs orchestration, retries and a schedule that someone other than an engineer can see. The Data APIs are the right answer for anything with volume and a bespoke transformation, and the ROCS utilities remain the pragmatic choice for repeatable bulk operations. Streaming ingestion, now including a direct Confluent Cloud Kafka path, is for genuinely event-driven sources and it is worth resisting the temptation to use it for a nightly batch dressed up as events.

One sequencing detail is worth a line in the plan because it is invisible until it hurts: load entities before the relationships that reference them, and load reference data before either. A relationship whose endpoint does not yet exist fails in a way that is easy to retry and tedious to reconcile at scale, and an attribute bound to a lookup that has no values will either reject or silently pass through raw source codes, depending on configuration. Neither is discovered by a smoke test on a thousand records.

7. Designing match rules that a data owner can defend

Match configuration in Reltio is organised as match groups on each entity type. A group holds one rule, expressed as a comparison formula over attributes using operators such as Exact, ExactOrNull and Fuzzy, together with the properties that govern how that rule behaves: whether a hit merges automatically, queues for a steward, or contributes to a relevance score. Cleansers normalise address, email, phone and similar attributes before comparison, and the engine additionally applies its own match-level cleansers. Match tokens exist so that the engine can find candidate pairs without comparing every record to every other record, which is the difference between a feasible system and a thought experiment.

The most important thing to understand about Figure 2 is that tokenisation is a hard ceiling. If a true pair never becomes a candidate, no amount of comparison-formula sophistication will find it. Programmes that spend months refining fuzzy thresholds while leaving tokenisation untouched are optimising precision inside a recall boundary they never examined. Conversely, tokens that are too loose generate candidate volumes that inflate processing cost and steward queues without improving accuracy. The token strategy is the design decision; the formula is the tuning knob.

Design the rule set as a small ladder rather than a large flat collection. At the top sit one or two high-confidence identity rules built on strong identifiers with strict comparison, and those may merge automatically. Beneath them sit the compound rules, name plus normalised address, name plus date of birth plus partial identifier, that carry most of the real-world matching and should queue for review until measurement earns them promotion. At the bottom sit deliberately loose discovery rules that only ever queue, and exist to reveal the pairs your ladder is missing. Ten well-understood groups beat forty that nobody can trace, because every group is a permanent maintenance obligation and a permanent contributor to token volume.

Three specific practices repay the effort disproportionately. First, be explicit about null handling: ExactOrNull is convenient and it quietly means “absence is agreement,” which is defensible for a middle name and indefensible for a national identifier. Audit every use of it against the attribute's population rate in real data. Second, maintain the ignore lists that keep placeholder values out of tokenisation, and treat every newly discovered placeholder as a production incident rather than a curiosity, because each one is a merge storm waiting for the next load. Third, use negative evidence deliberately. Two profiles that agree on name and city but disagree on a strong identifier are not a match, and encoding that as an explicit exclusion is far more maintainable than lowering a fuzzy threshold until the symptom disappears.

On AI-assisted matching, the platform's own framing is the right one: it generates additional potential matches beyond what the rules produced, and supports bulk resolution of them, with pretrained models available for specific industries such as life sciences. Read that as a recall instrument. It is very good at surfacing the long tail your tokens missed, and it does not absolve you of a rule set you can explain to an auditor. Run it alongside the rules, review what it finds that they did not, and let those findings drive rule changes. A programme that cannot explain a merge to a regulator has a governance problem regardless of how the merge was proposed.

8. If you cannot measure the match, you are not tuning it

This is the section that separates programmes that improve from programmes that merely change. Most Reltio implementations tune matching by anecdote: a steward reports a bad merge, someone tightens a threshold, the ticket closes, and nobody knows what the change did to the pairs that were previously found correctly. That loop can run for a year and end with worse matching than it started with, because every adjustment trades recall for precision invisibly.

The fix is a labelled golden set built once, early, and maintained deliberately. Take a stratified sample of candidate pairs from the test tenant, deliberately over-sampling the hard cases: same name different address, transposed given and family names, married-name changes, corporate entities sharing a registered office, and the placeholder-value clusters from the source register. Have two stewards independently adjudicate each pair as match, non-match or genuinely ambiguous, and keep the disagreements as a third class rather than forcing a decision. Between two and five thousand pairs is enough to be statistically useful and small enough that a pair of stewards can complete it in a fortnight. That fortnight is the highest-return two weeks in the whole programme.

With that set in place, every rule change becomes an experiment with a reported result rather than a hope. Publish the numbers on a dashboard the data owners see.

Two asymmetries should shape how you read that scorecard. Over-merging is worse than under-merging, because an unmerge is a technical operation with a business apology attached, whereas a missed match is an inefficiency nobody notices this week. Start conservative: let almost everything queue, and promote rules to automatic merge only when the golden set and the steward reversal rate both say the rule is safer than the humans reviewing it. And treat the golden set as a living asset. Refresh it when a major source is onboarded or when the population changes shape, because a golden set built on two sources will silently stop being representative the moment the fifth one lands.

9. Survivorship: the configuration most likely to embarrass you

Matching and survivorship are independent processes in Reltio, and conflating them is the conceptual error behind a surprising share of production incidents. Matching decides which crosswalks belong to the same entity. Survivorship decides, for each attribute, which of those crosswalks' values is the operational value. A merge does not choose a winner; it changes the population from which the winner is computed. And that computation happens just in time, whenever the entity's values are requested, which is why a survivorship configuration change can alter what every consumer sees without a single record being touched.

The trap is the default. Where an attribute has no explicit survivorship mapping, the platform applies Last Update Date, which means the most recently updated crosswalk wins. That is a reasonable default and it is almost never the policy anyone would write down. It means a marketing list refresh can overwrite a verified regulatory address, and it means the answer to “which address is authoritative?” is “whichever integration ran most recently,” which is not an answer any data owner will sign once it is phrased that way. Go through the attribute list and assign strategies deliberately. The attributes you leave on LUD should be a documented decision, not a gap.

The strategy catalogue is broad, and choosing well is mostly a matter of matching the strategy to the attribute's nature rather than picking a house favourite.

Fallback chains are where survivorship goes from adequate to precise, and they are underused. A strategy can return more than one winner, and what happens next is governed by the fallback criteria: the default triggers when two or more winners survive, another variant triggers on zero or on more than one, and a third fires only when nothing won at all. That third case is the useful one for a pattern most programmes need and few configure: prefer the authoritative source, and when that source has said nothing, fall back to the most recently updated value from anyone else. A fallback can also carry its own source list, distinct from the primary strategy's, which lets you express “the regulator wins; failing that, the CRM; failing that, whatever we have” as configuration rather than as a Lifecycle Action.

Two operational notes. Survivorship groups let more than one configuration exist per entity type, with non-default groups applying to users holding particular roles. That is powerful and it is also how two teams end up looking at the same profile and reporting different values in the same meeting, so document which group each audience sees and treat a second group as a decision with a rationale rather than a convenience. And because the operational value is computed on read, a survivorship change has no migration and no backfill: it takes effect for everyone at once, including every downstream consumer that cached yesterday's answer. Promote survivorship changes with the same ceremony as a schema change, and tell the consumers named in section 12 before you do it.

10. Stewardship is a capacity plan, not a screen

Every design decision in the preceding four sections converts into minutes of somebody's day. A loosened token, a rule left on manual review, an aggregation strategy that surfaces four conflicting values, a validation rule that fires on a legitimate edge case: each is a small tax on a finite pool of steward attention. Programmes that never build the arithmetic discover at go-live that the queue arrives faster than it clears, and the failure looks like a people problem when it is a configuration decision made three months earlier.

Build the arithmetic explicitly during design. Estimate the arrival rate of potential matches per day from the test tenant, measure the median handling time for a review in a timed session with real stewards rather than assuming two minutes, and compare the product against the hours the business has actually committed. When the numbers do not reconcile, the honest choices are to tighten the rules, promote well-measured rules to automatic merge, add capacity, or accept a documented backlog with a triage policy. The dishonest choice, which is the common one, is to go live and hope stewards are faster than the measurement said.

Data Change Requests are the other half of stewardship and they carry a design question people answer by accident. A DCR routes a proposed change through review before it lands, which is exactly right for a compliance-relevant attribute and exactly wrong for a call-centre agent fixing a misspelled first name while the customer waits. Decide per attribute, per role, which edits are direct and which are proposals; if the answer is “everything is a proposal,” the review queue becomes a rubber stamp within a month and the control becomes theatre. Note also that submitted DCRs can be edited before approval, which is useful for the approver who needs to correct a nearly-right proposal and is a hole in your audit story if nobody defined who may do it.

One last piece of stewardship design is easy and almost always skipped: capture the reason. A steward who rejects a potential match knows something the rules did not, and if that knowledge lands only as a resolved queue item it is lost. A short mandatory reason code on reject, reviewed monthly against the match scorecard, is the cheapest continuous-improvement mechanism available to an MDM programme, and it is the input that makes the golden set in section 8 stay honest.

11. Extending the platform without accumulating regret

Reltio gives you several ways to make it do something it does not do out of the box, and they differ enormously in what they cost you over five years. Configuration — survivorship strategies, fallback chains, validation rules, RDM mappings, workflow definitions — is promotable, reviewable, and survives platform upgrades without anyone thinking about it. A Lifecycle Action is a self-contained Java JAR built against the lifecycle framework, and it brings with it a Maven build, a release pipeline, a test harness, a dependency surface, and a person on your team who understands it well enough to debug it under pressure. Both are legitimate. They are not interchangeable, and the drift from the first toward the second is how a clean implementation becomes a bespoke application.

The rule we apply is that custom code needs a named owner, a test, and a written statement of what happens when the platform changes underneath it. If the requester cannot supply all three, the requirement goes back to the design forum to be re-expressed as configuration. The overwhelming majority of proposed Lifecycle Actions turn out to be a survivorship fallback chain, a validation rule, an RDM mapping, or an integration concern that belongs upstream of the platform entirely.

Where a Lifecycle Action is genuinely warranted, two constraints should shape it. Keep it fast and keep it side-effect-free where you can, because it executes inside the platform's processing path and a slow action degrades every write that triggers it. And keep it idempotent, because reprocessing happens: a match table rebuild, a replayed load, a corrected feed. An action that increments a counter or appends to a log will produce a mess the second time it sees the same record, and it will see the same record.

The 2026.1 agentic surface adds a new item to this list and it deserves the same discipline. Agent Builder requires custom agents to pass an approval workflow before publishing, which is a well-designed guardrail, and it is only a guardrail if someone reviews with the same seriousness they would apply to a code merge. An agent that proposes attribute values is a source. Register it in the source register in Table 3, give it a crosswalk identity, decide where it sits in your survivorship priority lists, and measure its acceptance rate the way you measure a steward's reversal rate. Treating an agent as a feature rather than as a source is how you end up unable to explain where a value came from.

12. Downstream: publish a contract, not a payload

An MDM platform earns its budget downstream, and it loses its credibility there too. The recurring architectural mistake is to treat publication as an export problem: stand up a feed, let each consumer subscribe to whatever it likes, and move on. Two years later the platform cannot change a survivorship rule because eleven consumers depend on undocumented aspects of its output, and the team that was supposed to improve data quality spends its capacity not breaking things.

Publish a versioned contract instead. For each consumer, write down the entity types and the specific attributes it is entitled to read, whether it consumes the operational value or needs source-level detail, the delivery mode and latency it can rely on, and the behaviour it must implement for merges, unmerges and deletes. That last item is where most integrations are quietly broken. When two profiles merge, one identifier stops being the right one to reference; a consumer that stored the old identifier and never handles a merge event will keep pointing at a profile that no longer represents the customer. Every consumer needs an answer to that, and the answer must be tested before go-live rather than discovered during a quarter-end reconciliation.

Choose the transport per consumer's real need rather than per fashion. Operational systems that need a single profile now should read the entity APIs directly and cache with a short, deliberate lifetime. Systems that need to react to change belong on the event stream, and 2026.1's direct Confluent Cloud Kafka integration makes that path materially less bespoke than it was a year ago. Analytical consumers belong in the lakehouse, and the zero-copy interaction integration from Databricks is a genuine simplification for teams that were previously exporting, landing and reconciling the same data three times. Reporting consumers who ask for a nightly extract of everything should be asked what question they are answering, because roughly half the time the honest answer is that they want a lakehouse table someone else already built.

Keep the contract transport-agnostic. This is the one place where the SAP acquisition genuinely should influence your design, and the influence is modest: if a Business Data Cloud consumption path becomes attractive in eighteen months, you want adding it to be the work of registering another subscriber against an existing contract, not of untangling eleven point-to-point integrations that each encode their own assumptions about your model. The same applies to MCP-mediated agent consumers, which are the newest class of downstream reader and the one most likely to appear without an architecture review. An agent that queries mastered data is a consumer with an entitlement, a latency expectation and a merge-handling obligation, exactly like any other.

One governance habit makes all of this durable: maintain a consumer register alongside the source register, and require that any change to the model, the survivorship configuration or the match rules names the consumers it affects. It takes a few minutes per change and it converts the most dangerous class of MDM incident — a correct change that surprises someone — into a notification.

13. The non-functional track most plans skip

In a SaaS platform you do not tune the runtime; you design within its limits. That is a good trade and it has one sharp edge: the limits are discovered either during design or during user acceptance testing, and the second is much more expensive. Give this a dedicated track with its own owner from the first sprint rather than a paragraph in the design document.

Start with the limit that is documented precisely: any HTTP POST body over 50 MB is rejected with a 413, platform-wide, regardless of tenant or subscription, and the published recommendation is to split payloads into batches of roughly 10 to 20 MB for best performance. Combine that with the batch sizing in Table 4 and you have a concrete design envelope. Rate and concurrency limits are less precisely published, which means you must establish them empirically in your own tenant: drive load until you see 429 or 503, record the throughput at which they begin, and design your loaders to run comfortably below it with backoff rather than at the edge of it. A loader tuned to the exact ceiling will fail on the first day the platform is also serving a rebuild.

The erasure rehearsal is the row teams most want to defer and least can afford to. Reltio's retain-everything model is exactly what makes lineage and unmerge possible, and it is also what makes erasure a genuine engineering exercise rather than a delete statement. Work out, on paper and then in the test tenant, what happens to a crosswalk's history, to the profiles it was merged into, to the event stream that already published it, and to the lakehouse tables and downstream caches that consumed it. Do this while the programme still has design capacity, not in the fortnight after a request arrives with a statutory clock attached.

14. Sequencing, cutover, and the first ninety days

The sequencing that works is boring and it is boring for a reason. Two sources, one domain, one downstream consumer, in production, with measurement, beats six sources and three domains in a test tenant that nobody depends on. A narrow first release forces every hard decision to be made for real: the source register gets signed, the survivorship arguments get resolved, the consumer contract gets tested, and the steward capacity gets measured against actual arrivals. Every subsequent source is then an increment against a working system rather than another variable in an unfinished one.

Cutover deserves one structural decision, made early: run the legacy system and Reltio in parallel with a reconciliation report, rather than switching consumers over on a weekend. The reconciliation is what converts “we believe the new platform is right” into a number a data owner can sign, and it will find things. Expect the first reconciliation run to surface differences that are Reltio being correct and the legacy system having been wrong for years, and budget the time to adjudicate those rather than assuming every difference is a defect.

The first ninety days after go-live are where an implementation becomes an operating capability or becomes a system people work around, and the difference is almost entirely about whether anyone is watching. Four things need a named owner and a weekly review from day one: the match scorecard from Table 5, the queue arrival-versus-clearance ratio, the reject reason codes, and the unmerge log. Those four together tell you whether the configuration you shipped matches the data you actually have, and they will disagree with your test tenant within the first fortnight, because production data always contains a distribution your sample did not.

Plan for a deliberate tuning release at roughly day thirty and another at day seventy-five, scheduled in advance with the rebuild window already agreed. Programmes that do not schedule these end up making the same changes anyway, as unplanned interventions, without the measurement to know whether they helped.

15. The six things we would insist on

If a programme adopted nothing else from this paper, six practices would still change its trajectory, and each one is cheap relative to what it prevents. Put the L3 in Git with reviewed diffs and an exported rollback artefact before the first real change. Sign a source register before the first load. Load with matching disabled, then rebuild, and measure how long the rebuild takes on full volume before promising anyone a tuning cadence. Build the labelled golden set in the first quarter and publish the scorecard where data owners see it. Assign a survivorship strategy to every attribute deliberately, so that nothing sits on last-update-wins by accident. And write a contract per downstream consumer that names its attributes, its latency and its merge-handling obligation.

None of that is exotic and none of it depends on which release you are on. It is also, in our experience, the difference between an MDM platform that becomes the reference point for enterprise data and one that becomes a system of record for arguments. The agentic capabilities arriving through the 2026 release line, and the SAP-adjacent consumption paths that will follow the acquisition, both raise the value of getting these fundamentals right rather than lowering it: an agent reasoning over your mastered data inherits every survivorship decision you made carelessly, and it inherits them at a speed and volume no steward can review.

A closing caveat that this paper has tried to earn the right to make. Platform specifics move. Batch sizing guidance, the exact set of agentic features and their availability stage, the boundaries of what configuration promotes cleanly between tenants, and the published request limits are all things to verify against the current Reltio documentation and your own tenant rather than against an article. What does not move is the sequence: understand the sources, agree the model, load before you match, measure before you tune, and tell the consumers before you change what they read.

Apptad is an SAP partner with a deep Reltio and multidomain MDM practice, and we spend most of our time on the unglamorous parts of this blueprint: source registers, golden sets, survivorship arguments and reconciliation reports. If you are scoping a Reltio implementation, mid-flight and unsure whether your match quality is measurable, or working out what the SAP acquisition means for a roadmap you have already committed to, talk to a specialist.