Simple Is a Trade: What Profisee's Lower Complexity Buys, and Who Pays for It

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

I keep a list of what Profisee does badly. It is not a long list, and little on it is a secret to anyone who has implemented the platform: it is bound to Windows and SQL Server, it wants its own copy of the data, the screen for building match clusters is poor, it has no source control of its own, its job system is hard to see into, and its integration engine, Connect, reloads and compares the whole source every time it runs. The question worth asking about a list like that is not whether it is true. It is whether those are the defects of a product, or the price of a decision.

A disclosure first, because everything after this paragraph assesses Profisee. The practice behind this publication is a Profisee partner. Clients pay us for deployment work, a licence sale we refer earns us a referral fee from the vendor, and our services revenue depends on master data management being bought at all. That interest runs toward praise of Profisee and of the category, so weigh what I say in Profisee's favour below what I say against it. Profisee positions itself inside Microsoft's platform, so the same interest runs toward Microsoft; weigh my praise of Microsoft's approach with that in mind. And one interest runs the other way: Shabel Enterprises is building tooling for the integration gap this piece describes, which gives us a reason to make that gap sound larger than it is, and so does our deployment work, which is paid to build what the platform does not carry. Discount my account of the gap accordingly.

Asked which items on the list were the price of Profisee's lower complexity and which bought nothing at all, I answered:

Almost all of them are byproducts of the lowered complexity. Microsoft is traditionally known for its ‘simplified’ user experience and its focus on Business Productivity over capability. That’s the main reason they have become so dominant in the business market.

That is the claim this piece defends, and it is narrower than it sounds. It does not say Profisee is weak. It says the weaknesses and the strength are one decision seen from two sides, and that a buyer who wants the strength should know which side of that decision their own estate sits on. "Lower-complexity alternative" is an accurate description of the product. It is also an incomplete one, because complexity is not something a vendor can delete. It can only decide who carries it.

What the older platforms made you carry

The platforms Profisee is usually sold against grew up when master data management was assembled from parts: a hub, a matching engine, a data-quality engine, a workflow engine, a hierarchy manager and an integration layer, each with its own console, its own specialists and, often, its own licence line. Gartner described the field in 2011 by saying that vendor capability had "focused on specialization across data domain, industry, use case, organization and implementation style" [1], and the specialisation was the complexity. A buyer chose not just a product but an architecture: a registry that left the data where it was and federated every query, a repository that every application was rewritten to use, or one of the hybrids in between. Roger Wolter's 2007 description of those styles for Microsoft is still a fair map, and his verdict on the repository model is still the one buyers fear: it "can be extremely expensive and take a long time because it requires changes to the applications that maintain and consume the master data" [2].

Profisee made the opposite bet. It is one product with one database, built on the Microsoft stack, and most of what the older suites sold as separate modules arrives configured from one portal. When I am asked where it genuinely leads rather than keeps up, my answer is the same as it was when this publication started: the web screens and user interface, the low-code application builder it calls FastApps, its direct integration with Microsoft Fabric and Purview, and Connect as a no-code integration pipeline with a framework that lets an integrator write the connectors it lacks. Its own pages put the bet plainly. The software-as-a-service edition is "built on 100% native Azure infrastructure like AKS and the SQL Elastic Pool" [3], and the vendor describes itself as "The Only Native MDM Workload in Microsoft Fabric" [4].

What that bet removes is real, and I have said so before. Profisee has taken the install and the infrastructure and reduced them to a template, so that standing up an environment is no longer the project; I made that argument in Time-to-Value Is Not Your Date, and I will not repeat it here beyond its conclusion, which is that the time saved goes to the configuration and testing, where the work always was.

What no tool removes

The older suites were not complex only because their vendors were careless. A good part of master data management's difficulty is in the organisation, not the software. Gartner's line from the same 2011 release is blunt: "MDM is complex; rarely do two organizations' MDM programs look alike" [1]. A peer-reviewed study that followed two master data projects in one public organisation for 32 months found fifteen separate organisational challenges and concluded that "incorporating data management practices into an organization is not a simple task" [5]. Wolter, writing for the vendor whose stack Profisee now stands on, made the same point from the other end: "It's not unusual for the meetings to settle on a data model to take as much time as the actual implementation of the project" [2]. No product shortens that meeting.

Complexity moves; it does not leave

Fred Brooks split the difficulty of software into two kinds forty years ago: "essence, the difficulties inherent in the nature of the software, and accidents, those difficulties which today attend its production but which are not inherent" [6]. A better tool can remove accidents. It cannot remove essence, and Brooks gave the warning that matters for any product sold on simplicity: "descriptions of a software entity that abstract away its complexity often abstract away its essence" [6].

Larry Tesler put the same idea as a question of ownership. "Every application has an inherent amount of irreducible complexity," he wrote; "The only question is: Who will have to deal with it—the user, the application developer, or the platform developer?" [7] That is the question I would put to any claim of lower complexity, Profisee's included. Some of the complexity the older suites exposed was accidental, and Profisee genuinely removed it. The rest was essential. Profisee did not remove that part; it chose not to carry it in the product, and it handed it back to whoever builds the implementation.

The research on low-code platforms, which is the family Profisee's portal belongs to, describes the mechanism precisely. Ulrich Frank, Pierre Maier and Alexander Bock, comparing ten such platforms, put it as a trade in the design of every reusable component: the meaning built into it "promotes reuse productivity, but is an obstacle to the range of reuse" [8]. The more a component already knows about the job, the faster it does that job and the fewer other jobs it can be bent to. Gartner, forecasting the growth of the same market, added the qualification its enthusiasts tend to drop: "many complex tooling configuration tasks are no code but still require specialist skills" [9]. No code is not no complexity. It is complexity with a friendlier front door.

Where the Microsoft habit comes from

My own explanation for why Profisee made this trade is that it inherited it. In my answer I credited Microsoft with a long habit of simplifying the experience and putting business productivity ahead of capability, and I said that habit is why Microsoft dominates business software. I went and checked how far Microsoft's own accounts bear that out. Its largest reporting segment is literally named Productivity and Business Processes, and its annual report files its low-code tools there, describing Dynamics as including "our low code development platforms, such as Power Apps and Power Automate" [10]. That is consistent with the claim, though a segment's name is not proof of the trade. The same report shows the Intelligent Cloud segment, which holds Azure, SQL Server, Windows Server and Visual Studio, at about $106 billion of revenue against about $121 billion for productivity [10]. A company that earns more than a third of its revenue, about $106 billion of $282 billion, selling deep infrastructure and professional developer tools is not one that trades capability away across the board. The narrower version is the one I will defend: Microsoft's business applications are built for productivity over reach, and that is the habit Profisee adopted, along with the infrastructure underneath it.

Where the bill lands

That is what the sources and the vendor's own documents show. What follows puts my own list against those documents. Where it rests on my experience rather than on a source, I say so, and it should be read as one practitioner's account, not as a law about the product.

Put the list against Tesler's question and almost every item has the same shape: a choice that made the product simpler for the people who configure and use it, and left a specific piece of complexity with the people who integrate and operate it. The "almost" in my answer was deliberate. It leaves the reader room to draw the line somewhere else, and I am not trying to rule on it for anyone. Pressed for my own reading, though, I would put each of these on the simplicity side of the ledger, the user-interface shortcomings included: the local copy, the single back end and the single platform, the missing delta processing, the limited control over the job system, and the screens.

One stack underneath

The first item on my list is the foundation. When I restated the list in my own words, I put the first item this way:

It's tied to Windows and MS SQL Server, not Azure, but that doesn't mean it's easily portable or installable on other clouds, just that those clouds need to implement Windows and MS SQL.

The vendor's own documents agree with that correction: the tie is to Windows and SQL Server, not to Azure. Profisee's compatibility matrix lists one family of database for the repository: SQL Server 2017, 2019 or 2022, or Azure SQL Database [11]. Its public deployment repository runs the application as a Windows container, pinned to Windows nodes, and it carries scripts for Amazon's and Google's Kubernetes services as well as Azure's [12]. On Amazon, the database is still Microsoft SQL Server, provisioned through Amazon's managed service [13]. So the self-managed platform is not an Azure product; it is a Windows and SQL Server product that runs best where Windows and SQL Server are native. One thing in the repository's history is worth a buyer's attention, and I offer it as an observation rather than a conclusion: the Azure deployment path was updated for the current release on 6 October 2026, while the Amazon script was last touched in 2023 and the Google one in 2021 [12].

This is the clearest case of a limitation that is the decision itself. One database engine is why there is one product to install, one backup to restore and one skill set to hire. It goes with the platform wanting its own copy of the data, loaded from the source into its SQL Server, and it is why a buyer whose estate is built on something else has to bring Windows and SQL Server along. My own account is that the vendor has been working on portability to other platforms for years without arriving; that is my reading, not something Profisee has published.

Promotion without source control

The second cluster is about change. On my list: Profisee does not integrate versioning or source control; moving a configuration from one environment to the next goes through a command-line utility or through separate tools written against its web service interface, and continuous integration needs more custom tooling on top of that. The vendor's partner repository shows what the native path looks like. It is a Windows installer, "ProfiseePlatformTools_20****.msi", "also known as the Profisee Command Line Utility or CLU", which imports the exported objects in one pass and then imports forms and matching strategies a second time [14]. Each object travels as its own XML file, and the instructions give the reason for the second pass: "There are circular dependencies between some object types" [14]. That is a perfectly workable mechanism for a team of three promoting a model by hand. It is not a release pipeline, and at the scale where a model changes weekly across several environments, the pipeline is something the implementer builds. What leaving source control out buys is smaller than what the other items buy: one product with no repository of its own to integrate, and promotion a single administrator can run from one utility.

A job system that is hard to see into

Asked for examples of where the simplicity stops, I named two:

For example, Connect is a very serviceable and capable integration tool for low volume data sets, but it is woefully inadequate for dealing with data sources having millions or tens of millions—let alone billions—of source records. Hangfire, Profisee’s internal scheduling and job management system, is substantially opaque and challenging to work with and debug.

Connect gets its own section below. The second half of that answer can be checked, so I checked it in Profisee's documentation. The platform does run its background work on Hangfire. Its help pages describe Hangfire as "an external platform that allows you additional insight into the monitoring process by displaying detailed information on running processes", reached from the Monitor screen, and only for users with Super Administrator rights [15]. Its own database maintenance "is implemented as a recurring job within Hangfire" [16]. Hangfire itself is an open-source library for running background jobs in .NET applications, with a dashboard that supports "retry, delete, trigger" [17].

The opacity is in the seams between the two. The same help page warns that when a service is restarted, "all web browsers with Hangfire windows open must be closed to allow for the service to start in a healthy state", and that a job detail may show "<VALUE IS TOO BIG>", which "does not indicate an error and can be ignored" [15]. A customer's request in Profisee's own ideas forum makes the point from the operator's chair: Connect jobs can only be cleared "1 at a time", or "in the backend", and the request asks for a fix "via the hangfire dashboard" [18]. That is one customer's experience, and I would not rest anything on it alone. It is consistent with what I described above.

An integration engine sized for the middle

Connect is where the trade is easiest to see, because it is where volume arrives. The last item on my list was the one I had learned most recently:

Something I just recently found out: Profisee Connect does not have any way to do change detection in the source system, so it does a full load and compare each time it executes--this takes a significant amount of time and resources when the source systems contain millions of records.

The obvious objection is in Profisee's own documentation. Its Connect FAQ says that "strategies can be triggered by data changes" [19], and the public page for its Snowflake connector says runs can launch "on demand, on a schedule or via CDC" [20], change data capture being the standard technique for loading only what has changed. If either meant the source, my item would be wrong. I had looked at the configuration screen myself, and read it this way:

Profisee can trigger a job based upon changes to the data in the associated entity: updated records, added records, deleted records. However, my read of the screen is it's tracking the Profisee entity, not the external system.

The help pages for the individual connectors settle it, and they agree with what I saw. For both the SQL Server and the Snowflake connectors, a strategy with an import flow is "limited to On-Demand asynchronous execution and Scheduled execution"; the continuous options, "when records are added, updated, or deleted", belong to the export flow, which watches Profisee's own records [21][22]. The same marketing page describes "full, scheduled or on-demand loads and continuous, scheduled or on-demand exports" [20], so its "via CDC" most likely refers to the export side; neither page says so outright. Nothing I could find in the public material or the help pages describes source-side change detection for imports, and I will put it in exactly those terms: not documented, rather than impossible. There is one qualification from the product itself. On later releases a scheduled import can carry a record filter; I think 2026 R3 allows one on a manual run too, and on 2026 R2, where I was told it was present, I found no place to set it. Whether that filter can say "changed since the last run" I have not established; I believe there is a way to make it work, and I do not know it for sure. If it can, a scheduled import can be set to take only what changed, and the implementer configures it; if it cannot, each run reads whatever the source table or view holds, which is why the preparation layer described below is where change detection lives. Most of the companies I have worked with never had to find out, because they load through a dedicated ETL platform.

Why that matters at volume is not a Profisee question; it is arithmetic. Change data capture reads changes from the database's transaction log so that "An ETL application incrementally loads change data" [23]. Microsoft's own guidance for Power BI says what happens without it: "If the table is large, say with tens of millions of rows or more, a refresh for that table can take a long time and consume an excessive amount of resources" [24]. A load that reads and compares the whole source costs in proportion to the source. A load that reads only the changes costs in proportion to the changes. At small volumes the difference disappears inside an overnight window. At the volumes Microsoft names, it can decide whether the load fits the window.

Asked for one load at volume, I would rather not give the details. What I will say is that a multi-million-record load through Connect takes significantly longer than the same records through a dedicated ETL platform, and that the load is where the time goes. In current releases the matching, merging and survivorship are not the bottleneck; Profisee has made significant progress in speeding them up in its later releases, and older releases are still slow on complicated matching strategies, which is why I push clients to upgrade as soon as they can. For the loads themselves, my answer was:

To solve the data load times--and to incorporate proper delta detection and incremental loads--"real," full-featured ETL products are the standard. That does require Data Engineers and Data Architects with experience to design and build the ingestion systems as a project, unlike Connect which is much more intuitive--and limited.

The last words of that answer are the whole trade. Connect is intuitive and limited for the same reason, and the complexity it spared the configurer comes back, at volume, as an ingestion project with its own engineers.

There is a lighter step short of that project, and it starts from something I already do for a different reason. I frequently put external tables in a SQL Server underneath transformational views and do the preparation there, so that what Connect ingests is already shaped. The same layer is where change detection can live: compare against the previous load in SQL, hand Connect only what changed, and let Profisee's matching do the rest. That is not a defect report. Designing around what a tool does not do is ordinary architecture, and it is most of what an implementer is paid for. But it is complexity, and it is now on the implementer's side of Tesler's line rather than the platform's.

What the vendor claims about scale

The strongest case against my answer comes from Profisee's own record, and it deserves a straight hearing. The vendor says it can "Quickly ingest large volumes of data via batch, on-demand or in real time" [25]. Its 2026 R2 release announcement says it now regularly benchmarks Profisee on "hundreds of millions of records" [26]. And its Australia Post case study reports mastering "approximately 25 million customer records to create about 13 million golden records" and then "about 48 million more customer records for an additional 19 million golden customer records" [27]. About seventy-three million source records is not a mid-market estate.

Read closely, none of that contradicts the narrower claim, and it does narrow it. The benchmarks and the case study are about the platform and its matching, not about how the records arrived, and on matching my own answer runs the same way: in current releases it is the load, not the matching, that takes the time; the case study does not say whether they were loaded through Connect, through staging tables, or through Profisee's REST interface, which its own Data Factory templates use [28]. No benchmark is published with its hardware, its database tier or its load cadence. So the claim I will stand behind is about Connect specifically and about routine, repeated loads, not about what the platform can hold: Profisee can master tens of millions of records; Connect, used as the only path from a source of that size on a regular schedule, is the wrong tool for the job, and the gap is filled by work outside it. What would prove me wrong is a documented, routine Connect import from a source of tens of millions of records, on a daily or weekly cadence, with no preparation upstream. I looked for one and did not find it.

Mid-market, and the top of the list

Which brings me back to where the price actually falls. My answer drew the line in one sentence:

None of these are issues on basic, mid-market systems, but they’re significant challenges to Fortune 50 implementations.

The line is defensible from both ends. At the bottom, Gartner's 2011 list of myths includes the idea that master data management is "for Large, Complex Enterprises Only", and rejects it: the discipline applies "whenever two or more business processes must view or share (master) data" [1]. A mid-market company needs mastering as much as a global one, and in my view the older suites were often more architecture than its problem required. A one-database, one-portal product, with low-code screens a business analyst can maintain, is the right shape. Every item on my list is still true for them, and almost none of it is felt: the volumes are small enough that a full reload fits the window, the team is small enough that hand promotion works, and Windows and SQL Server are often already in the building.

At the top, the scale is of another order. Walmart says about 280 million customers and members visit it each week [29]; JPMorganChase says it serves 80 million individuals, families and businesses [29]. Those are customer counts, not master-record counts, and I will not turn either into a figure for anyone's customer master. But they put the customer domain of a consumer-facing Fortune 50 company in the tens to hundreds of millions, which is at or past the size at which Microsoft's Power BI guidance says a full refresh can take a long time and consume an excessive amount of resources [24]. A business-to-business company at the same rank can reach that scale in other domains, products, materials and suppliers, rather than in customers.

"Fortune 50" in my answer was shorthand for volume. What drives the cost is how many records each source holds and how often it loads; the company's size matters because it almost always tracks those volumes, and at the top of the list they are expected to be orders of magnitude larger. Asked whether company size itself was the point, I answered:

The company size is almost always directly related to the data volumes that need to be mastered. It's a very rare mid-market company that has a real business need to handle millions of customer or product records. I'm not saying they don't exist, I'm saying they're rare.

So the line runs source by source, and the company's rank is the quickest way to guess which side of it you are on before you have counted. At that scale every item on the list becomes a work item: change detection to build, a promotion pipeline to build, a job system to monitor from outside, a database tier to size without public sizing guidance that I could find.

The commercial interest, in plain words

My answer ended with a sentence I will not trim, because the disclosure above was written for it:

That’s why Shabel Enterprises—shameless plug—is working to bridge the gap with additional tooling and experience that facilitates more robust integration with standardized, Enterprise-level systems.

That is the interest the disclosure at the top of this piece names. The test of whether I am inflating the gap is in the documents cited here, not in my account of it.

What "lower complexity" should mean in a proposal

Lower complexity is a true claim that becomes a misleading one when it is read as lower effort. The effort moved; the honest question for a buyer is where to.

The first place it moves is into the defaults. A product designed to be simple has good defaults, and a timeline built on its marketing will lean on them. When I am asked for my quick tell that a go-live date was set by a vendor's published timeline rather than by a scoped estimate, my answer is one word:

Shoehorning. Forcing business to adapt to defaults by shoehorning it into an ‘out of the box’ implementation is a cheap and effective way to shorten timelines. When things are implemented with nothing but default configurations, irrespective of their applicability to the current system, that’s a clear indicator that the timeline was compressed artificially and something other than meeting the needs of the business is driving the timeline.

That is the failure lower complexity invites in the mid-market, where the scale costs are small: not a platform that cannot do the job, but a project that stops configuring once the defaults run, because the defaults were what the timeline assumed. Configuration gets complicated exactly where a business's requirements do not fit the defaults, and that is where the effort goes. My own estimates do not start from the vendor's quotes, whose internal basis I do not know; they start from a reference environment in the first sprint and then one sprint per source system, held for at least the first quarter, which is slow enough to find out where the defaults stop fitting.

The second place it moves is into the integration layer, at the top of the market. There the question for a proposal is concrete: for each source, how many records, how often, and what carries the change detection. If the answer for the largest source is "Connect, nightly, the whole table", the proposal has assumed the simplicity of the middle of the market for an estate at the top of it. The honest answer at that scale is usually an ingestion layer built as its own project, by data engineers, and it belongs in the plan and the budget from the first week.

Who carries it

Profisee is a lower-complexity alternative to the platforms it is sold against, and for most buyers that is the right reason to choose it. The older suites exposed their complexity as modules, consoles and specialists; Profisee removed the accidental part of that and declined to carry the rest inside the product. Almost every limitation on my list follows from that choice, and I leave the "almost" to you: one database engine, one operating system underneath the application, an integration engine sized for the middle of the market, a job system that works and gives you limited control over it, screens built for the common case, and no release pipeline of its own.

None of that is a reason to choose something else. It is a reason to answer Tesler's question before signing, rather than after the first missed load window: of the complexity your estate actually has, which part will the platform carry, and which part will your team or your implementer carry instead? At mid-market volumes the honest answer is that the platform carries nearly all of it. At the top of the Fortune list, the answer is that someone will build the rest, and the proposal should say who.

References

[1] Gartner, "Gartner Highlights 10 Critical Myths and Realities of Master Data Management," press release, 24 January 2011 (Andrew White). Read in full 2026-10-08 in a verbatim reproduction, as the original Gartner URL could not be located; stored locally. Fifteen years old; cited for the field's structure and for the two passages quoted in the body, not for the current market. https://insurance-canada.ca/2011/01/24/gartner-highlights-10-critical-myths-and-realities-of-master-data-management/

[2] Roger Wolter, "MDM Master Data Management Hub Architecture," Microsoft (MSDN blog, Microsoft Learn archive), 3 January 2007. Read in full 2026-10-08; stored locally. Written by a Microsoft employee about the stack Profisee is built on. Cited for the three implementation styles and the two sentences quoted in the body. https://learn.microsoft.com/en-us/archive/blogs/rogerwolterblog/mdm-master-data-management-hub-architecture

[3] Profisee, "Cloud Master Data Management Architecture," profisee.com, last modified 1 October 2026. Read 2026-10-08 through a rendering fetch; stored locally. Vendor page (the vendor we partner with). Cited for the SaaS infrastructure sentence quoted in the body. https://profisee.com/platform/modern-cloud-architecture/

[4] Profisee, "The Only Native MDM Workload in Microsoft Fabric" (page title "Profisee Adaptive MDM for Microsoft Fabric"), profisee.com, modified 11 September 2026. Read 2026-10-08 through a rendering fetch; stored locally. Vendor page; a positioning claim, cited as the vendor's own words. https://profisee.com/solutions/microsoft-enterprise/microsoft-fabric/

[5] Riikka Vilminko-Heikkinen and Samuli Pekkola, "Master data management and its organizational implementation: an ethnographical study within the public sector," Journal of Enterprise Information Management 30(3), 2017, pp. 454–475, DOI 10.1108/JEIM-07-2015-0070. Abstract read 2026-10-08; full text not read; stored locally. One public organisation; the 32 months is the observation period, not a benchmark for how long master data management takes. https://researchportal.tuni.fi/en/publications/master-data-management-and-its-organizational-implementation-an-e/

[6] Frederick P. Brooks, Jr., "No Silver Bullet — Essence and Accidents of Software Engineering," Technical Report TR86-020, University of North Carolina at Chapel Hill, September 1986 (later published in IEEE Computer, April 1987). The 1986 technical report read in full 2026-10-08; the journal version was not read. Stored locally. https://www.cs.unc.edu/techreports/86-020.pdf

[7] Larry Tesler, "The Law of Conservation of Complexity," nomodes.com (Tesler's own website), formulation dated on the page "ca. 1984". The formulation read 2026-10-08; the commentaries collected on the same page were not read. Stored locally. http://www.nomodes.com/Larry_Tesler_Consulting/Complexity_Law.html

[8] Ulrich Frank, Pierre Maier and Alexander Bock, "Low Code Platforms: Promises, Concepts and Prospects. A Comparative Study of Ten Systems," ICB-Research Report No. 70, University of Duisburg-Essen, December 2021. Read 2026-10-08 through section 3.2; the platform analyses and conclusions were not read, and nothing in the body relies on them. Stored locally. https://umo.ris.uni-due.de/fileadmin/fileupload/WI-UMO/ICB_Report_70.pdf

[9] Gartner, "Gartner Forecasts Worldwide Low-Code Development Technologies Market to Grow 20% in 2023," press release, 13 December 2022. Read in full 2026-10-08; stored locally. Cited for the sentence quoted in the body. https://www.gartner.com/en/newsroom/press-releases/2022-12-13-gartner-forecasts-worldwide-low-code-development-technologies-market-to-grow-20-percent-in-2023

[10] Microsoft Corporation, Annual Report 2025 (fiscal year ended 30 June 2025), segment descriptions and segment results. Read 2026-10-08 (about the first 100,000 of 122,000 characters, which include both); the fiscal 2026 report could not be retrieved, so this is the most recent annual report retrievable on 2026-10-08. Stored locally. Microsoft is aligned with our partner. https://www.microsoft.com/investor/reports/ar25/index.html

[11] Profisee, "Compatibility Matrix 2026 R1," Profisee Platform Help, support.profisee.com. Login required; read in full 2026-10-08 with a Profisee Community account; stored locally. The help's navigation lists separate R2 and R3 matrices, which were not read. Cited for the supported database repository. https://support.profisee.com/wikis/profiseeplatform/compatibility_matrix_2026_r1_2026_r3

[12] Profisee, "Profisee Kubernetes" (GitHub repository Profisee/kubernetes), repository head 6 October 2026. READMEs, deployment template, Helm chart and commit history read 2026-10-08; stored locally. Cited for the Windows container and node pinning, the three cloud scripts, and the dates each script was last changed. https://github.com/Profisee/kubernetes

[13] Profisee, "AWS Master Data Management (MDM)," profisee.com, last modified 24 July 2026. Read 2026-10-08 through a rendering fetch; stored locally. Cited for the database on Amazon being Microsoft SQL Server on Amazon RDS. https://profisee.com/solutions/aws-master-data-management/

[14] Profisee, "partners" (GitHub repository Profisee/partners), last commit 4 June 2025. README, batch file and exported artifacts read 2026-10-08; stored locally. Cited for the Platform Tools / CLU description and the circular-dependency instruction quoted in the body. https://github.com/Profisee/partners

[15] Profisee, "Additional Monitoring using Hangfire," Profisee Platform Help (2026 R3), support.profisee.com. Login required; read in full 2026-10-08 with a Profisee Community account; stored locally. https://support.profisee.com/wikis/profiseeplatform/additional_monitoring_using_hangfire

[16] Profisee, "Database Maintenance," Profisee Platform Help (2026 R3), support.profisee.com. Login required; read 2026-10-08 with a Profisee Community account; stored locally. Cited for the sentence quoted in the body. https://support.profisee.com/wikis/profiseeplatform/database_maintenance

[17] Hangfire OÜ, Hangfire documentation ("Using Dashboard" and the project home page), hangfire.io and docs.hangfire.io, read 2026-10-08 through a rendering fetch; stored locally. https://docs.hangfire.io/en/latest/configuration/using-dashboard.html

[18] "Bulk Clear of Connect Jobs," Profisee Community Ideas, submitted by a Profisee customer about a year before reading, status New, 8 votes. Login required; read 2026-10-08 with a Profisee Community account; stored locally. A customer's request, not a Profisee statement. https://support.profisee.com/00o0000000000xj00aM

[19] Profisee, "Connect FAQ," Profisee Platform Help (2026 R3), support.profisee.com. Login required; read 2026-10-08 with a Profisee Community account; stored locally. https://support.profisee.com/wikis/profiseeplatform/connect_faq

[20] Profisee, "Profisee MDM for Snowflake," profisee.com, last modified 10 September 2026. Read 2026-10-08 through a rendering fetch; stored locally. Cited for the phrases quoted in the body; the same vendor's help page for the connector [22] limits imports to on-demand and scheduled runs. https://profisee.com/platform/integration/profisee-mdm-for-snowflake/

[21] Profisee, "Using the SQL Server Service Provider," Profisee Platform Help (2026 R3), support.profisee.com. Login required; read in full 2026-10-08 with a Profisee Community account; stored locally. https://support.profisee.com/wikis/profiseeplatform/using_the_sql_server_service_provider

[22] Profisee, "Using the Snowflake Service Provider," Profisee Platform Help (2026 R3), support.profisee.com. Login required; read in full 2026-10-08 with a Profisee Community account; stored locally. https://support.profisee.com/wikis/profiseeplatform/using_the_snowflake_service_provider

[23] Microsoft, "What is change data capture (CDC)? — SQL Server," Microsoft Learn, updated 20 July 2026. Read in full 2026-10-08; stored locally. https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/about-change-data-capture-sql-server

[24] Microsoft, "Configure incremental refresh and real-time data for Power BI semantic models," Microsoft Learn, updated 24 September 2025. Read in full 2026-10-08; stored locally. About Power BI, not Profisee; cited for the general principle and the threshold Microsoft states. https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-overview

[25] Profisee, "Integration | Profisee Platform," profisee.com, last modified 10 August 2026. Read 2026-10-08 through a rendering fetch; stored locally. Cited for the sentence quoted in the body. https://profisee.com/platform/integration/

[26] Eric Melcher, "Profisee 2026 R2: Aisey Is Now the Orchestration Layer," Profisee blog, 8 July 2026. Read 2026-10-08 through a rendering fetch; stored locally. Vendor claim; no benchmark, hardware or database tier is published with it. https://profisee.com/blog/profisee-2026-r2-aisey-is-now-the-orchestration-layer/

[27] Profisee, "Australia Post: Delivering Efficiency with MDM," case study, profisee.com, last modified 26 February 2025. Read 2026-10-08 through a rendering fetch; stored locally. Vendor-reported figures; the load path, platform and cadence are not stated. https://profisee.com/case-study/australia-post

[28] Profisee, "Profisee Azure Data Factory" (GitHub repository Profisee/azuredatafactory), last commit 7 September 2022. README and template documentation read 2026-10-08; stored locally. Cited for the Data Factory templates being built on the Profisee REST Gateway API. https://github.com/Profisee/azuredatafactory

[29] Walmart Inc., "About Walmart," 24 April 2025, https://corporate.walmart.com/about; and JPMorgan Chase & Co., "About us," undated, https://www.jpmorganchase.com/about. Both read in full 2026-10-08; stored locally. Customer counts, not master-record counts.