Profisee Decides What. Other Systems Decide How. (original)

A customer 360 rarely fails on the platform. It fails on a boundary nobody drew — and drawing it is a day of work every programme postpones.

The disclosure first, because it should change how you weigh everything after it. The practice behind this publication is a Profisee implementation partner: we are paid when Profisee implementations happen. The main argument below is a rule that makes those implementations smaller — it takes work out of the tool we configure and pushes it back into systems we are usually not hired to touch. The last section argues the other way, for a custom build over an accelerator, and that conclusion happens to suit us; I have flagged it where it sits. One disclosure is all you get. I would rather spend the words on the rule.

The situation this is written for: somebody senior has said the words customer 360, a digital transformation programme now has master data management (MDM) in its critical path, and you have been handed a platform and a date. We have argued elsewhere in this thread about what that costs and how long it takes. This piece is the question underneath both — what actually belongs in the master record, and who decides — because getting it wrong is not rescued by configuration skill. You will have built the wrong thing correctly.

What this piece will not give you

The honest version of the advice is narrower than the one you were probably promised. No click paths — no open this screen, set that toggle. A plausible-sounding configuration step nobody has run is the worst thing I could hand you: it is checkable, you will check it, and so will the vendor. What you get instead is the layer above the click path and below the strategy deck — the decisions, named in the product's own documented vocabulary, with the page that says the capability exists. That is the layer people get wrong, and the only one that survives a release note.

Step one: lay the schemas side by side before you model anything

The first thing to build is not a model. It is a picture of what you already have. Ask my co-author where he would start and the answer is boring on purpose:

Ideally, I'd like to start by reviewing, classifying and compartmentalizing the customer-related information from the various systems we're planning to integrate. Extracting the schema metadata and lining it up next to one another gives a good picture of where there are redundancies and where there are single sources of truth.

That is not a preliminary. It is the deliverable every later argument gets settled against, and the published reference architecture agrees about the order: Microsoft's Purview-and-Profisee architecture puts cataloguing first — connectors scan the source applications and populate the catalog, and only then is the master data model published back into it — naming the challenge it solves as determining what constitutes master data and which sources should populate the model [5].

Three columns per candidate field, and the third is the one nobody fills in:

• Where it lives. Every system holding something that claims to be this attribute, in that system's own spelling. Mechanical, mostly extractable.
• Redundant or authoritative. Two systems holding a customer name is redundancy. One system holding the tax identifier because it is the only one that ever files anything is a single source of truth. Opposite treatment, identical appearance in a schema dump.
• What the value means there. Not the data type — the meaning. Two fields called Status that mean credit status and marketing subscription status are not a conflict to be resolved; they are two attributes with one name, and that distinction currently exists only in somebody's head.

Budget for the third column to take longer than the other two combined. It is not extractable. It is interviews.

And the worst place to start, which is where you will probably be

The green-field version above is the one that fits on a slide. Here is the one that shows up:

The worst place to start is with a single 'unified' table fed by all the sources and handed over by the previous "MDM" (read: ETL/DW) team without documentation beyond 'the code.' Now there's an 'operational' system that needs to be monitored, maintained and bug-fixed alongside the new build and the first ask is going to be a straight-line lift and shift from the current implementation to the new one while preserving the current undocumented logic. Good luck!

Two things do damage there. The parenthetical is a reclassification and it is the criticism: what was sold as master data management was extract, transform and load (ETL) feeding a data warehouse (DW). A denormalised table assembled from several sources is a reporting artefact — no survivorship policy you can inspect, no record of which source won which field, no way to tell a genuine merge from a coalesce that fired in a particular order. It looks like a golden record from the outside, which is the problem.

The second is the ask. Preserve the current undocumented logic sounds conservative and is the most expensive sentence in a transformation programme. Martin Fowler's account of why has not needed updating in twenty years: replacements seem easy to specify, but it is hard to figure out the details of existing behaviour — and worse, much of that behaviour is not really wanted, so building it is a waste [6].

So ask this in the first week, out loud, of whoever wants the lift and shift: which consumers read the current unified table, and what would break for each of them if a field arrived with a different value? Not a request to justify the logic — a request to enumerate the dependants, which tells you which parts of the undocumented behaviour anybody actually relies on, and whether you inherited a system to replace or a report to retire.

The rule that settles most of the arguments

Now the part I would put on the wall. Everything above produces candidate attributes; this decides each one:

As a rule: Profisee decides what, other systems decide how. Profisee, or MDM, decides what wins while other systems decide how they pick what to present. SalesForce decides how to classify a Customer—Top 50, Premiere, Custom, Bulk, Grey, Peer, whatever—Profisee decides what to include in the 'Customer' record—SF.Classification -> SalesForce_Classification, or IF(SAP.Classification is not null, SAP.Classification, SF.Classification) -> Customer_Classification. The logic of how to populate a field belongs in the providing system, the logic of how to populate a Master field belongs in the MDM system.

One sentence, and you can test any proposed field against it in about ten seconds. The question people bring to an MDM tool is what can it do. The question that decides the implementation is should this logic live here at all.

The pair of pseudo-mappings inside it makes it concrete — the first trivial, the customer relationship management (CRM) system's classification stored unaltered as the CRM system's classification; the second real, the master value chosen by a rule that prefers one source and falls back when it is empty. His lines, verbatim, and illustrative. Note what the second does not do: it does not compute a classification, clean one, standardise one or second-guess one. It picks between two values that arrived already decided.

Which is a survivorship rule, and Profisee documents the vocabulary

It matters that this is a named, configurable rule type rather than custom code. Profisee's documentation sets out the family — source system priority, most recent update, most complete record, data quality score, conditional if-then rules, and hybrid strategies that cascade when the preferred value is absent [1] — and the product page says the same: configurable automated survivorship set on completeness, recency, source trust or custom logic [2]. The coalesce above is that hybrid shape, a source priority with a fallback.

So the instruction is smaller than it sounds. For each mastered attribute, pick a rule type from that list and write down why. Not configure survivorship, which is a task nobody can finish.

Carry two of Profisee's own cautions while you do it, because they are the sort of thing a vendor is not obliged to tell you. Recency needs reliable timestamps across every source and an agreed definition of a meaningful update, and a nightly batch touching metadata will defeat it; completeness rules carry a high risk of error alone and want combining with something else [1]. And their first stated best practice matters most here: define rules at the attribute level, because logic that trusts a whole record from one source — trust the ERP for all customer data — leads to problems quickly [1]. That shortcut is how you publish a shipping address from a system that has never shipped anything.

The part I have to say against my own interest

Follow this rule honestly and it takes money off our invoice. Every field it pushes back into a source system is a field we do not model, do not configure, do not test and do not support. The work an implementation partner most enjoys billing — elaborate transformation and cleansing logic, built inside the tool, visible in the demo, ours to maintain — is precisely what the rule forbids. A correctly scoped customer 360 has fewer mastered attributes and thinner logic than the one you will be quoted. If your partner's proposed model is wider than your business needs, ask which attributes we are computing rather than choosing. The honest answer should be almost none.

The contestable half, and I am not going to soften it

The rule has a second clause that reasonable people fight about. My co-author's version:

MDM systems should take what other systems give them unchallenged, the expectation is the upstream system has performed appropriate transformations and logic to the data such that what they provide is, as far as that system is concerned, correct.

That is a deliberate refusal to validate on the way in, and it should make you uncomfortable, because a movement in data engineering says the opposite. The Open Data Contract Standard is its clearest expression: a machine-readable producer-consumer agreement in YAML, with sections for schema, data quality, service levels, roles and support [10] — premised on the consumer enforcing what it expects rather than discovering the failure downstream. Profisee's product carries the instinct too: a data quality score rule grades incoming values on accuracy, completeness, conformity and consistency, then picks the highest scorer [1].

Where I land is not a split-the-difference, and the reason comes from the architecture rather than either camp. Microsoft's reference document states the load-side rule plainly: ideally the line-of-business systems load into the master data model with little or no change or transformation, the goal is the data as it exists in the source with as little loss of fidelity as possible, and limiting the complexity of the load is what makes lineage simple [5].

Lineage is the reason, and it is a better reason than trust. Transform on the way in and you have destroyed the ability to say what the source actually said — every later question about a wrong value now runs through your transformation logic, which makes your logic a suspect in every investigation.

So the rule sharpens rather than blunts. Unchallenged governs the load path, where it forbids something specific and checkable: no value may be altered between the source system and its landing attribute. It does not govern the rule layer, where measuring input quality is how you earn the right to complain. The same architecture describes that loop — quality rules tied to entities and attributes, traceable back to source, establishing the root cause of poor quality originating in a line-of-business system [5]. Measure it, score it, refuse to publish it, send the root cause home; do not fix it in flight and call the problem solved. One test for whether you have crossed the line: can you still show a steward the exact value the source sent, next to the value you published?

One real boundary case, which I would rather name than let you find. Profisee's data quality page shows an address arriving incomplete and leaving verified — a street type appended, a missing city supplied, a ZIP code extended — through integrations with services such as Melissa and Loqate [11]. That is the platform altering a value, and my rule has to answer for it.

The documentation answers it, and from a stronger position than I expected. Address verification is configured with source attributes holding the address to be verified and separate output attributes holding what the service returns, and the guidance is explicit: Make sure that the source and output for each field item use separate attributes. If you use the same attribute for the source and output data, then Address Verification will overwrite the existing values. For legacy tracking purposes, this is not recommended. [12] So the load-path rule is not a partner's preference. It is the platform vendor's own documented guidance, for the vendor's own stated reason.

Read the limit as carefully as the permission. The product recommends the separation; it does not enforce it. Point one attribute at both ends and the verified value lands on top of the landed one — a misconfiguration rather than a default, and so something to check rather than to fear. So the check is concrete: open the strategy and read the mapping, field by field. Where source and output name the same attribute, what the source sent is already gone.

Two ways to get the boundary wrong, and they are opposites

Programmes do not fail this rule by rejecting it. They fail it by never applying it, and the model then drifts to one of two extremes. My co-author files both under one heading, which is the useful part:

Over or under generalization.

Failure one: the model that masters nothing

What a model looks like when nobody was willing to decide:

'Federated' MDM systems have a full suite of 'duplicate' fields for each system they 'master.' So they wind up with sixteen different name fields because they 'master' data from fifteen different systems and slap a 'master' name on top of it—SF_Name, SAP_Name, C365_Name, D365_Name, Mktg_Name, eMail_Name, MailGun_Name, etc.

Every one of those columns is a decision raised and deferred. The pattern is easy to laugh at and worth naming precisely instead, because the name tells you what went wrong. Storing a per-source copy of every attribute and pointing at the sources is, in the textbook, the registry implementation style: the platform acts as a central reference point for master data definitions and attributes but does not store the data itself, source systems remain the system of record, and it is easy to implement but offers little control [4]. A real architecture with real trade-offs — and there is a lovely piece of evidence on the same page that it is largely theoretical. Malcolm Hawker, described there as Profisee's Head of Data Strategy and a former Gartner analyst, says that across well over 1,500 analyst conversations he never once saw a registry-style implementation in the wild [4].

So the sixteen-name-field model is not the registry style. It is the registry table inside a consolidation hub: the duplication of a federated design without its architecture, with a master column bolted on so the thing could be called a golden record. Since the style you pick bears directly on scope, duration and the governance maturity you need [4], arriving at one by accident is expensive.

Failure two: the model that masters too much

The opposite failure carries the real business damage, and it is the one applauded in design reviews:

Alternatively, even though there are precise, specific, business critical reasons for having 'duplicate' fields, the system over-consolidates. A customer can only ever have one 'mailing address,' even though there are separate addresses necessary for billing, legal and marketing purposes, the 'master' record only contains the 'approved' mailing address.

This looks like rigour. It is a category error: two values that disagree because they answer different questions have been treated as a conflict to be resolved. The standing catalogue of address assumptions that break in production closes on exactly this — that each person has exactly one address — after a hundred entries demolishing gentler ones, and notes the version that costs somebody money daily: systems that cannot post to both of a child's divorced parents [8].

The answer is not another survivorship rule. It is the model. Profisee's documentation is explicit that relationships are created by defining domain-based attributes on entities, that such an attribute can point at another entity or recursively at its own, and that the platform carries derived hierarchies in straight-line and recursive forms [3]. What follows is ordinary and correct: Address is its own entity with a purpose, related to Customer, not a column on Customer. Billing, legal and marketing each get the address they are entitled to.

This is not a new argument from us, and I would rather say so than dress it up. It is the entity-level form of one we already make about structures — a single "correct" hierarchy is a decision to be wrong for everyone except whoever won the requirements meeting, answered by a de-duplicated core with a flexible relationship layer. One truth, many lenses. Applying it to attributes is the only new part.

Then the verdict, which inverts the premise of a customer 360 programme:

This tends to lead to more siloing instead of less as the 'master' data is either too busy to be able to be used or simply not fit for purpose.

Both failures end in the same place by the same mechanism. A model with sixteen name fields cannot be consumed, so the consumer keeps reading its own source. A model with one approved mailing address does not carry what billing needs, so billing keeps its own address table. Either way the golden record becomes one more system nobody uses, and a programme funded to remove silos has added one.

Accelerators, templates and the box somebody else's answers came in

Which brings us to the shortcut, and to the part of this article that suits my commercial interest. Read it with that in mind; the strongest opposing evidence is in it deliberately.

'Out-of-the-box' templates, consolidators or accelerators. Unless they were built specifically for companies that use SalesForce, SAP and Oracle Financials, in exactly the same way your company does, you're going to spend as much time refactoring as you would 'save' by using it. From a pure implementation perspective, plan on doing your own custom build-out because your company is functionally different from the 'standard' for which the accelerators were designed.

The condition is stated as effectively unmeetable, and that is the argument rather than an overstatement of it. The interesting thing is who else says so. Databricks published a library of pre-built industry data models this June — they ship accelerators for a living — and opened by describing the shortcut regulated sectors have been sold for three decades, naming ACORD for insurance and FHIR and HL7 for healthcare. Their assessment: an industry data model is the average of every business in a sector, it does not know your product lines or your regulatory footprint or your legacy constraints, and most of the value of buying a template gets spent trimming, renaming and rewiring it — which is exactly the work the template was supposed to save [7]. That is my co-author's claim in a vendor's own words, on a page selling the category, and I will not pretend the corroboration is mine.

Their answer is that theirs are different: generated by a rules-driven agent, validated against more than 200 structural rules, deployable in hours [7]. Take that seriously — a template whose consistency is machine-enforced is not a committee standard from 2003. The boundary I would draw is about what is in the box. What ships there is an analytical schema: tables, keys, classification tags, metric definitions. What refactoring eats in an MDM implementation is not the table list. It is the matching strategy, the survivorship rule per attribute, the source priority ranking and the definition of what counts as the same customer — none of which an analytical model contains, and each of which encodes a decision a generic model cannot have made. Their own closing note concedes the axis: the base models are a starting point rather than a finished deliverable, and domain expertise still matters [7].

So the test is narrower than accelerators are bad, and more useful:

• A structural accelerator is usually worth taking. Entity shapes, attribute lists, naming conventions, reference-data vocabularies. Wrong in ways that are cheap to correct, and re-deriving them from scratch is vanity.
• A decision accelerator is usually not. Pre-set match rules, pre-ranked source priorities, a survivorship strategy somebody else chose. These encode which of your systems is authoritative — a fact about your organisation no template can know, which you will re-derive anyway, and re-deriving it against something already built is harder than starting from blank.
• The exception is a genuinely mandated standard. Where a regulator or an interchange format already fixes the representation, a template built on it is not a guess about your business; it is what you must emit regardless. Even there the exemption covers the shape and not the policy — a standard says what a patient record looks like, not which of your four systems wins when they disagree about one.

And since plan on a custom build is what an implementation partner would say, here is how to check us without us: take the accelerator's proposed model and count the attributes you would keep unchanged. High, and the template is doing real work — take it. Rewriting survivorship on most of them, and you have bought a table list at consulting prices, which is worth saying before the statement of work is signed rather than after.

What AI changes here, and it is not what the pitch says

One development lands directly on the failure mode above. Profisee's AI assistant now ships tasks that build an entity model, suggest attribute mappings and create data quality rules on request, plus agent templates that run without prompting — including ones that propose matches and apply match survivorship. The vendor's framing is careful and deserves the credit: automate where possible, escalate where human judgement is essential, every output explainable and every change reviewable [9].

Now put it against the two failures. Both are over-generalisation — a model carrying more than anyone decided, or less than anyone needs — and until recently there was one brake on the first: somebody had to build each attribute. Sixteen name fields cost sixteen pieces of tedious work, and tedium was a governance mechanism nobody designed and everybody relied on. Generate the model in a click and that brake is gone. The cost of adding an attribute nobody argued about has fallen far faster than the cost of arguing about it.

Assistance is genuinely good at the authoring — proposing a model, mapping a field, drafting a rule. It cannot do the adjudicating, because whether Salesforce or SAP wins the customer classification is a statement about which department's definition the business has agreed to live with. Wider models, generated faster, against the same unchanged supply of people willing to decide who owns "customer".

A second-order effect argues for the boundary rather than against the technology. The assistant is now connected to the platform's own Model Context Protocol (MCP) server, letting it retrieve data, update records and create quality rules in natural language [9]. A human analyst handed one approved mailing address knows to go and find the billing one; an agent takes the field it was given and proceeds. The over-consolidated record has always been a problem. It is a quieter one when the reader cannot tell it has been shortchanged.

The crux is a sentence, not a system

Climbers call the single hardest move on a route the crux — the one the whole climb is about, and rarely the one that looks hardest from the ground. Customer 360 programmes have one too, and it is almost never the matching engine. It is one boring sentence somebody has to say out loud: this attribute comes from that system, and here is who agreed.

Which is why the practical guide is short. Lay the schemas side by side. Decide whether what you inherited is a system or a report. Apply the rule attribute by attribute, and write the reason down. Load values unaltered so lineage survives, then measure quality and send the root cause home. Model several legitimate values as several values, related. Take a template for its shape, never for its decisions.

None of it needs a screen you have not seen. It needs somebody to make the call and put their name on it — the move you cannot buy, generate or accelerate, and the one the route turns on.