The Business Case, Priced in Days

Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary

There is always a number in a business case for a master data platform, and I will argue with anyone who treats it as the only thing the case decides. It is often the figure the room looks at first. It is rarely the whole reason a case is funded or refused, and a sheet that pretends otherwise is built to be read once.

This build produces one document: a costing sheet for a Profisee business case. Four parts, about two pages. Part one carries the field's published numbers with their provenance attached. Part two carries the ingestion estimate. Part three carries the operating lines a licence quote does not include. Part four carries the lines nobody has numbered, each with a name beside it. The sheet is finished when a finance reviewer can tell the four parts apart without asking which is which.

One decision governs the whole build: what you refuse to put a number on. A zero and a named unknown look identical in a spreadsheet and behave nothing alike. A zero is never revisited. A named unknown comes back every quarter, because a person's name sits next to it. Whether the discipline is worth funding at all is a separate argument, and it is settled before this document starts.

Part one: the numbers that buy the meeting

The traditional case opened large. Bad data costs the United States about three trillion dollars a year, a figure Thomas Redman reported in the Harvard Business Review in 2016 [1]. Gartner prices poor data quality at 12.9 million dollars a year for the average organisation [2]. Under both sits the 1:10:100 rule from Labovitz, Chang and Rosansky: a dollar to prevent a quality problem, ten to inspect and correct it, a hundred once it has reached the customer [3]. The version you will meet in a data-management deck is denominated per bad record. The book is not, and it is worth noticing that slippage this early, because the rest of this piece is about exactly that.

All three belong in part one, and so does what they are. The trillion is IBM's estimate and Redman was reporting it [1]. The Gartner page self-dates its figure to 2020 and publishes no sample [2]. The ratio comes from a 1992 management book, and it is a rule of thumb rather than a measurement of your firm [3]. Provenance goes on the same line as the number. A reviewer who finds a bare figure and traces it himself stops trusting the whole sheet. A large number buys the meeting; buying the meeting is worth roughly one slide.

The newest line in part one is AI readiness. Gartner predicts that through 2026 organisations will abandon 60 percent of AI projects unsupported by AI-ready data [5]. That prediction has a mechanism under it. A model pointed at a customer base holding one customer five times under four spellings answers confidently and wrong, and reconciling those five records is the work master data does. Take the sample with the prediction. The same page states 248 data management leaders in its meta description and 1,203 in its body [5]. It is worth checking because it is the figure a room is most likely to swallow whole. Taken together, the numbers in part one price the problem, not the product.

Part two: the ingestion line, built wrong on purpose

Part two is a single line: what it costs to get your data into the platform. It is worth building that line the way most sheets build it, because the failure arrives quickly and it teaches the rest of the document. Asked what a vendor demonstration actually tells a buyer, I gave it its due and no more:

Demos are happy-path, basic-functionality demonstrations — nothing more, but also nothing less. What a demo shows is the capability of the product. It is up to the client or the implementor to match those capabilities to the needs of the business.

Both halves of "nothing more, but also nothing less" matter. A demonstration is honest about being what it is: capability, shown over data somebody prepared. The fit between that capability and your business does not exist yet, and my answer puts the building of it on the client or the implementer, not on the vendor. Building the fit is the engagement.

A disclosure belongs here, before I assess the platform. The practice behind this publication is a Profisee partner. Clients pay us for deployment work, and a licence sale we refer earns us a referral fee from the vendor. Our services revenue depends on this category of software being bought at all, and in this part the interest is specific: the staging layer I am about to recommend is work clients pay us to build. Weigh my criticisms above any praise.

So the line comes back from the vendor at one number, and the sheet records it, and the sheet is now wrong. It is wrong in a specific place. Connect is Profisee's codeless integration layer, built on open standards and pre-built connectors [6]. It saves real money for a team that would rather buy connectors than write them, and it sets a ceiling on how much shaping it will do. The vendor's own FAQ is worth reading before the line is costed, all of it. One entry scopes the capability to master data and says it is "not intended to replace commercial ETL tools for bulk transformations or migrations." Two questions later, asked whether it handles complex transformations and mappings, the page answers yes, with custom business logic, rules and algorithms [6]. Read as a pair those look irreconcilable, and an earlier version of this piece said so. They are not; the first answer's own next sentence reconciles them: "However, Azure Data Factory ships with native pipeline templates to move data in and out of Profisee to simplify integration efforts, and Profisee supports open standards to move data in and out of the Profisee Platform" [6].

That sentence matters more than any contradiction. The page is consistent, and what it consistently tells you is that bulk transformation happens in a second tool, and it names one. That is the same shape as the architecture I am about to recommend. The vendor and I do not disagree about part two needing a second tool. We disagree about which one, and about who pays to wire it up.

So price the vendor's path first, because it is cheaper than mine and it may be enough. The templates are real and you can read them before you buy anything. There are four, contributed by Profisee to the Azure Data Factory gallery: CSV to Profisee, JSON to Profisee, and the same two in reverse [15]. Three things about them decide whether they close your part two. They are community-contributed rather than Microsoft-maintained, which the gallery manifest states in a field named contributorType [15]. They were published in 2022 and the repository has not been touched since; check the commit history yourself before you plan around them, because it is one click, and it is exactly the kind of check this sheet asks you to make of everything else. And, deciding it: every one of them is a copy. They move records between a file and Profisee's REST endpoint. None of them transforms anything. The templates do the half of part two that was never the expensive half.

Cost the runtime anyway, since it is knowable and most sheets never carry it. Data Factory bills orchestration by activity run and activity execution by integration-runtime hour; adding a mapping data flow to do the shaping the templates omit is a separate meter, billed per vCore-hour against an eight-vCore floor [16]. For a nightly master-data load, that is unlikely to survive rounding on a sheet that carries a platform licence. The number that will hurt you is days, and I cannot hand it to you from outside. Nobody publishes what it costs to build and maintain a transformation layer for your sources, in either tool, and I am not going to manufacture one here when the figure would flatter my own recommendation. It is a part-four line, unpriced, with a name beside it, whichever path you take.

Mine comes from operating it, and it is a claim rather than a citation. I put the ceiling and what I do about it in the same breath:

Demos always run the happy path and start from well-formulated or structured data. Real life is never that clean, and Connect transformations and filters are not nearly as robust as they need to be to make ETL and data ingestion as easy as the demos suggest. I frequently use external tables in a SQL server as the base for transformational views, doing the pre-processing there before passing the load into Connect for Profisee to ingest.

The first half is the ceiling: on real source data the transformation and filter surface gives out before the requirements do. An advocate reads the vendor's page and calls my staging a preference rather than a ceiling, and that reading stays open, because reaching for the workaround as often as I do is not the same as having measured where the wall is. Nothing here is settled by a citation, and it should not be.

The second half is the workaround, and it is worth saying why it holds. Heavy transformation happens in views over external tables, where the tooling is old and thoroughly understood. Connect receives a load that is already clean. A data engineer reads the logic a year later without opening the MDM tool. The precondition is a SQL Server instance you control, which most customer-hosted deployments will have and the managed service will not; where the platform's database is Azure SQL Database rather than a SQL Server instance, check how external tables work there before you cost the line.

That leaves the reader on the managed service. You do not have that instance, and the pattern above is not available to you as written. Your part two is the vendor's path for movement plus somewhere to do the shaping: the four templates to load, and Data Factory's own transformation surface, or whatever your estate already stages in, for the work the templates don't do. The templates never touch a database; they authenticate against a REST endpoint [15], so nothing in them needs an instance you control. That is precisely why they are your line and not mine. What you give up is the thing I said I valued in the first place, a data engineer reading the logic a year later in SQL they already know. What you should not do is take my staging design, put it on a managed-service sheet where it cannot be built, and call that a costed line.

Part two now reads in full, and it reads two ways depending on where the platform runs. On an instance you control: staging tables in SQL Server, transformational views over them for each source domain, the Connect load, and a re-test of all of it the first time an upstream system changes shape. On the managed service: the vendor's templates for movement, a transformation surface somewhere else in your estate, and the same re-test. Both carry a build nobody has priced. Naming a ceiling, its workaround and the vendor's cheaper alternative in the same passage is the job, not disloyalty to a partner's product, which is why the cheaper alternative had to be here and not left in the FAQ for a reviewer to find.

What It Costs on a Tuesday

Up to here the warrant has mostly been what anyone can look up; from here it is mostly what operating the platform has shown me, offered as pattern rather than law.

Start with the defaults. In my experience configuration and setup get hard where any developer would expect: at the point where a specific requirement stops meshing with what the product assumed. Every hour inside the defaults is cheap. The estimate that goes wrong goes wrong in the hours outside them, and a sheet costed from a demonstration has, by construction, costed only the hours inside.

Then the pairing that runs through part two. Asked whether naming a partner's limitations in public was a problem, I said no, and said why:

Pointing out the limitations of a tool and the workarounds is not a disclosure problem — there is nothing proprietary in it. Designing around limitations and figuring out ways to make up for tool gaps is a basic, fundamental part of architecture. That is why we make the medium-sized dollars.

The pair is the product. A limitation on its own reads as complaining about a product you recommended. A workaround on its own looks like enthusiasm for building things nobody asked for. Together they are architecture. Published as neither, the next implementer pays again to find the same ceiling.

My own record deserves the same scrutiny I give the vendor's. The two operating costs it supplies to part three, the weekend and the change orders, are both blameless toward the platform: one is triggered upstream, the other is caused by the client succeeding. The cost line that is adverse to the platform came out of a public review corpus, not out of me. An omission with a direction is worth noticing in anyone's list, and in a partner's list first.

I cannot size the weekend or the change orders. Anyone handing you a multiplier without showing a sample is guessing at you, and a guess presented as a figure is worse in a business case than a blank.

Part three: the operating lines

Forrester's Total Economic Impact model earns its place here, because it forces benefits, costs, flexibility and risk into one frame instead of three separate arguments [4]. Part three fills that frame. It holds the capabilities genuinely worth funding, each with what it costs to operate, and then the costs the frame still leaves out.

Three capabilities, priced at first mention

FastApps are curated, task-specific screens that business users design and configure into role- and task-based views [10]. Together with web integration and the screens generally, this is where I would say the platform leads rather than merely keeps up: it takes a front-end project out of the plan and puts a design conversation with the steward into it. That trade is worth taking. The workflow behind the screen is a separate line at a different rate. Profisee documents registering a workflow by importing the .XAML file that defines it [11], and an operator reviewing the platform this May reports that building task workflows and notifications "requires an understanding of Visual Studio coding, which can be a barrier for non-technical users" [13]. Screens are configuration; workflow is development. Two lines at two rates, and the sheet should show both.

Profisee runs as a native workload inside the Microsoft Fabric interface, beside first-party items such as Azure Data Factory and Power BI [8]. With Purview, Microsoft publishes a bidirectional architecture in which the master data model is pushed into the catalog and Purview's definitions come back in front of the stewards in real time [9]. That is why I count the platform a natural addition to a Microsoft estate: the integration is there and nobody has to fund it. It is also the same fact as an exit nobody has costed. A competitor will read it the second way in the bake-off. Read it both ways first, in your own document.

Profisee publishes webhook templates in .NET, Azure Functions and Node.js for integrators writing their own [7], which is the reason the staging pattern in part two counts as a design choice rather than a defeat. Aisey, the platform's assistant, is embedded across every section of the product, with tasks running from entity modelling to data quality rules, and agent templates that parse unstructured text [12]. Any reader can take that from the datasheet, so it earns nothing in the sheet. Where I have found it useful is narrower: building Connect connectors, pulling data out of unstructured fields, reporting on the data and answering questions about it. It also carries the limit every assistant carries. It is excellent where the requirement sits close to what it already does, and it wants working over where the requirement is exact. The requirement is always exact. Exactness is the reason an MDM platform is being bought at all. Accelerated development goes into the sheet as effort saved. A percentage does not go in.

The forty-two public operator reviews on G2 are the cheapest independent instrument a buyer has, and they name performance at large volumes, weak real-time SAP connectors, no multi-language portal, and difficulty promoting workflow between environments [13]. One director-level operator writes that data quality is heavily reliant on Melissa, and adds: "The rules are also not customizable—if customization could be added for merge, match, and survivorship, that would be a big improvement" [13]. That lands on the function I would have called table stakes. Informatica documents match rules as a surface the customer builds, against columns the customer nominates, with selectable rule types [14]. That is the knob the reviewer wanted and could not reach. On the Melissa half I can add something from operating the platform: address standardization and geocoding through Melissa ship in Connect out of the box, and the assistant can build custom service connections for Connect against any documented third-party interface, so for addresses at least the dependency is a default rather than a wall. On the other half, the merge, match and survivorship rules, I have no operating answer, so I cannot adjudicate it from here. If unusual matching logic is a requirement, this list is not the market, and there is now somewhere specific to look.

What the frame leaves out

Every model carries a support line, priced for business hours. The line I would add first is the weekend:

Emergency support is the line item nobody prices. "Product support" normally means business-hours support and TCO prices that in. What it does not price in is the Sunday night call that runs into Monday morning because the weekend bulk load failed and somebody has to come in and make emergency code changes — because an upstream vendor changed their data profile without communicating it through the monitored channels.

In that answer the trigger is not the platform at all, which is part of why the line is so easy to leave off. Pricing it reads as conceding the implementation is fragile. It isn't fragile. It's connected, and connected systems have a Sunday night. The support contract covers a vendor. What that night wants is a person with commit rights and a working knowledge of your transformation layer, awake.

The second line is caused by the project working. As the business learns the product, its questions sharpen and its requests diversify. That is adoption seen from the inside, and it reaches finance as change orders, which in my experience no total-cost calculation carries. No status report has a polite section for a project going well and therefore costing more, so the sharper questions from your best users land looking like overrun.

The third line is licensing, and it is not mine. An operator reviewing the platform this July writes that "data modeling decisions can have a significant impact on record volumes and, therefore, licensing costs," and that the implementation produced substantially more records than anticipated [13]. He attributes it to his own design choices and limited modelling experience rather than to the software, and he is probably right, which is precisely why it belongs in a cost model instead of a complaint. Read it for the timing. Record counts follow from how the model is built, and the model is built after signature. Ask in writing what the licensed unit is, and what the invoice looks like at two and three times the estimate.

The adoption line

The traditional case counted licences and seats. It did not count use, and use decides whether any of the rest of the sheet happens. Asked what actually gets a steward into the tool, I did not hedge:

The only thing that will guarantee stewards open the tool is making it an essential part of their daily activities. Transition their performance and reporting metrics and tie them to tool usage, and adoption spikes.

The emphasis on "only" is the argument. Training is not on the list, and neither is a launch note or a sponsor's enthusiasm. The lever is the measures, and it has a precondition that the answer does not state: a manager has to agree to have their own team's numbers rewritten. Where no such person exists, the lever is absent rather than weak, and what is left is the tactics that do not work.

The shape of the work matters as much as the mandate. In my experience the core difficulty is that stewardship has to fit inside a day that is mostly about something else, and Profisee's own documentation says stewardship can be one responsibility among several rather than a full-time job [10]. So the decision has to arrive where the steward already is. Notifications are sent automatically to whoever is assigned a workflow task [11], and stewardship can be shared, edited and worked on inside Outlook and Teams [10]. That is where email-driven workflow and FastApps fit together: an inline Approve, Reject or Pick, and back to the other job, rather than a context switch into a system somebody opens weekly and relearns each time.

Run a proof of concept against your own records before signature. It will tell you more about this line than every figure in part one.

Part four, and the handoff

Part four is the shortest part of the sheet and it is the crux of the build. Everything above it can be estimated by somebody who has read the documentation carefully. Part four cannot be estimated at all, which is why it holds four questions and no numbers.

Who stewards this in year three, by name, with time a manager has agreed to protect. Who defends the line when the sponsor moves to another job. What this work displaces, given that the same six people are also doing the migration. Whether the money exists at all, which is a different question from whether the return justifies it.

Asked whether a better number would settle a case like this, I refused the premise:

While there's always a number, I'll fight about the number ever being the only factor. It's always one of a bunch of factors, even if it's the 'leading' one. Even in situations where companies establish 'thresholds,' those thresholds are established for other reasons than pure monetary figures--not the least of which might be they don't have that kind of money in the first place. Obviously if someone needs a trillion dollars to implement something, anyone other than Governments or Musk are going to reject it out of hand, but that's not because of the dollar figure--it's because of the infeasibility for them being the ones to do it in the first place.

The trillion in that answer is a reductio, and the logic holds for any figure too large for the organisation in front of it: the refusal is about who could carry it, not about the digits. The rest of the answer is part four in other words. A threshold encodes capacity, mandate, risk appetite and what the budget is already promised to, and sometimes simply that the money is not there. The number is how a refusal becomes visible, and it is rarely the reason for one. A refusal that looks irrational from the vendor's side of the table is usually part four answering. A sheet presenting the money as the decision is repeating the mistake part two was built to expose: it shows a capability and calls it a fit.

The test for any platform claim in the sheet: could this sentence have been written after watching a demonstration? If it could, it is a capability claim, and every competitor on the shortlist has one. The claims worth funding are the ones only operating the thing produces.

One line belongs in part three that I have not costed yet, and it is the one I would defend hardest. Documentation written while the work happens, as a by-product rather than as a phase, is what a handoff runs on. The next owner might be another firm, a new hire, or eventually an agent. My answer to what I change on a job I expect to hand over was: nothing. Done properly, the policies and procedures pile up as the work goes, so the handoff can happen on any day of the project. Then I went one step further:

Perhaps one day we hand it off entirely to an AI agent and just monitor the reports as they come in.

An agent inherits what was written down. It cannot inherit what stayed in the heads of the engineers, the architects and the stewards. Which makes the documentation line the real AI-readiness line in this sheet, and it is a great deal cheaper than the one in part one.

The sheet is yours. Four parts, two pages, and a finance reviewer who can tell them apart without asking. The next artifact is built the same way, and it is the bake-off script: one page for each requirement, the person who owns the answer named on it, and matching tested first.

About this version. Published August 18, 2026 and rewritten September 4 and September 26, 2026. The 2026-08-18 text is preserved unedited at the original, beside the case study at The Voice Problem.

References

[1] Thomas C. Redman, "Bad Data Costs the U.S. $3 Trillion Per Year," Harvard Business Review, 22 September 2016. The piece reports IBM's estimate of the yearly cost of poor quality data in the US; the figure is IBM's, not the author's own measurement. Re-checked 2026-09-26: hbr.org returned only the page shell to a rendering fetch, so the sentence was read in the article as reproduced in a vendor-hosted PDF ("$3.1 trillion, IBM's estimate of the yearly cost of poor quality data, in the US alone, in 2016"). https://hbr.org/2016/09/bad-data-costs-the-u-s-3-trillion-per-year

[2] Gartner, "Data Quality: Why It Matters and How to Achieve It." "Poor data quality costs organizations at least $12.9 million a year on average, according to Gartner research from 2020"; the page self-dates the figure and publishes no underlying sample. Re-read 2026-09-26. https://www.gartner.com/en/data-analytics/topics/data-quality

[3] George H. Labovitz, Yu Sang Chang and Victor Rosansky, Making Quality Work: A Leadership Guide for the Results-Driven Manager (Omneo, 1992; HarperBusiness, 1993, ISBN 0-88730-582-2). The authors write the rule as the "1-10-100 Rule" at pp. 182–183 of the 1993 HarperBusiness edition, verified 4 September 2026 against the digitised copy held by the Internet Archive (archive.org/details/makingqualitywor00labo); not re-read 2026-09-26, and the pagination of the 1992 printings was not checked. The book states the rule as general cost of quality, a dollar to prevent "a quality problem," ten "to inspect and correct the mistake," a hundred once "your customer has taken delivery," with no per-record denominator; the per-record reading common in data-management writing is a later gloss, which this article carried until 4 September 2026. Library of Congress record LCCN 92053330. https://lccn.loc.gov/92053330

[4] Forrester, "Total Economic Impact Methodology." Cited for the framework's four components, "cost, benefits, flexibility, and risk," in "a financial model framework" that "illustrates the ROI of products and services." Re-read 2026-09-26. https://www.forrester.com/policies/tei/

[5] Gartner, "Lack of AI-Ready Data Puts AI Projects at Risk," press release, 26 February 2025: "through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data." The page states its survey sample two ways: "a third quarter 2024 Gartner, Inc survey of 248 data management leaders" in the meta description, and "A survey of 1,203 data management leaders in July 2024" in the rendered body. Both still present when re-read 2026-09-26. https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk

[6] Profisee, "Integration | Profisee Platform." Product documentation for the codeless integration layer ("Profisee's codeless approach to integration leverages your preferred, pre-existing tools and open standards"; webhooks and REST APIs) and pre-built connectors. The FAQ answer quoted in part two reads, in full: "Profisee's integration capabilities are limited to integrating and publishing trusted master data back to source systems — where it can be analyzed alongside transactional data to help organizations drive trusted analytics, operational efficiency and more — but it is not intended to replace commercial ETL tools for bulk transformations or migrations. However, Azure Data Factory ships with native pipeline templates to move data in and out of Profisee to simplify integration efforts, and Profisee supports open standards to move data in and out of the Profisee Platform." Two questions later: "Yes, integration within the Profisee MDM platform includes advanced capabilities for handling complex data transformations and mappings. Organizations can define custom business logic, rules and algorithms to automate data processing and ensure consistency across systems." From 18 August to 4 September 2026 this article quoted the first answer only as far as "migrations." Page modified 10 August 2026; re-read 2026-09-26. https://profisee.com/platform/integration/

[7] Profisee, "Profisee .NET Webhook Templates." Vendor-published developer repository: "This repository contains Profisee Webhook templates and describes how to utilize them," with Azure Functions, web app, Node.js and workflow activity library projects. README stored locally 2026-09-26. https://github.com/Profisee/webhooktemplate

[8] Profisee, "Profisee Adaptive MDM for Microsoft Fabric." Product documentation: "Profisee's MDM workload is embedded directly into the Microsoft Fabric interface, just like first-party applications such as Azure Data Factory or Power BI." Re-read 2026-09-26. https://profisee.com/solutions/microsoft-enterprise/microsoft-fabric/

[9] Microsoft, "Microsoft Purview and Profisee Master Data Management (MDM)," Microsoft Learn, last updated 3 April 2025. The published bidirectional architecture: "The master data model is published to Microsoft Purview," and "Any definitions and metadata that are available in Microsoft Purview are visible in real time in Profisee as guidance for the MDM data stewards." Re-read 2026-09-26. https://learn.microsoft.com/en-us/purview/data-governance-master-data-management-profisee

[10] Profisee, "Data Stewardship | Profisee Platform." Product documentation for FastApps ("highly curated experiences for specific tasks"; business users "design and configure role- and task-based views"), for sharing, editing and collaborating on stewardship "directly in Outlook and Teams," and, in its FAQ, that master data stewardship "can either be their full-time job or just one of their responsibilities." Page modified 11 September 2026; re-read 2026-09-26. https://profisee.com/platform/stewardship/

[11] Profisee, "Data Workflow Management Tool | Profisee Platform." Product documentation for workflow configuration: "Register the Workflow: Import the .XAML file that defines your workflow into the Profisee platform"; and "Notifications are automatically sent to users who are assigned a workflow task." Page modified 11 September 2026; re-read 2026-09-26. https://profisee.com/platform/workflow/

[12] Profisee, "Aisey: The AI Assistant Redefining Enterprise MDM." Product documentation: "Aisey is embedded across every section of the Profisee Platform"; tasks including building an entity model, suggesting attribute mappings, importing a file and creating a data quality rule; agent templates including "Parse Unstructured Data," "Data Enrichment," "Propose Matches" and "Apply Match Survivorship." Page modified 11 September 2026; re-read 2026-09-26. https://profisee.com/platform/ai-assistant-aisey/

[13] G2, "Profisee Reviews." The public corpus of independent verified-operator reviews: 42 reviews, 4.3/5 average, re-read 2026-09-26. Quotations and paraphrases are from a Verified User in Banking (Mid-Market, 27 May 2026) on Visual Studio and task workflows; Ryan K., VP of IT Enterprise Architecture (Enterprise, 12 November 2025), Rachael F., Data Analyst (Enterprise, 4 June 2026) and Prasanna P., Director – Data & Digital (Enterprise, 12 July 2026) on performance at volume; Prasanna P. also on real-time SAP connectors, on the Melissa dependency and on non-customizable merge, match and survivorship rules; a Verified User in Manufacturing (Enterprise, 2 October 2024) on the multi-language portal; Courtney M., Data Governance Lead (Mid-Market, 9 July 2026) on promoting workflow between environments; and a Verified User in Manufacturing (Enterprise, 31 July 2026) on record volumes and licensing costs, which the reviewer attributes to "our design choices and limited experience with MDM modeling" rather than to the software. Self-selected reviews, not a survey. https://www.g2.com/products/profisee/reviews

[14] Informatica, "Match Rules," Multidomain MDM 10.4 Configuration Guide. Cited for documented product behaviour only: match column rules operate on "columns you have defined as match columns," and rule types (exact, fuzzy, filtered) are selectable, with fuzzy matching described as dependent on the population. A competitor's own documentation, cited against this publication's commercial interest rather than for it; nothing here compares total cost, implementation effort or fit. Re-read 2026-09-26. https://docs.informatica.com/master-data-management/multidomain-mdm/10-4/configuration-guide/part-4--configuring-the-data-flow/mdm-hub-processes/match-process/match-rules.html

[15] Microsoft and Profisee, "Azure Data Factory community templates: CSVToProfisee, JSONToProfisee, ProfiseeToCSV, ProfiseeToJSON," in the repository Microsoft deploys the gallery from. Each template's manifest.json declares "contributorType": "Community" and "author": "Profisee," distinguishing them from templates Microsoft publishes and maintains itself; each requires two linked services, Azure Data Lake Storage Gen2 and a RestService endpoint for the Profisee REST API, with no SQL linked service in any of the four; each description is a copy of records in one direction. Manifests re-read and stored locally 2026-09-26. Contributed August 2022; Profisee's companion repository, which carries the exported templates and their setup documentation, last committed September 2022 (commit histories read 4 September 2026; not re-read 2026-09-26). https://github.com/Azure/Azure-DataFactory/tree/main/community%20templates and https://github.com/Profisee/azuredatafactory

[16] Microsoft, "Data Pipeline Pricing — Azure Data Factory." The published billing model: "You pay for data pipeline orchestration by activity run and activity execution by integration runtime hours," data flows billed per vCore-hour, and "The minimum cluster size to run a Data Flow is 8 vCores." Cited for the billing units only; the page renders its rates by region through a calculator, and no rate or total is stated here. Re-read 2026-09-26. https://azure.microsoft.com/en-us/pricing/details/data-factory/data-pipeline/