The Council Signs, the Release Ships

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

A governance council approves a change to the master data model, or to a match rule. How does that approval reach Profisee? The natural guesses are a workflow inside Profisee that holds the change until the council signs it, a permission that lets only approved people touch the model, or, failing both, the minutes. Put to me that way, the question gets the order wrong:

I think you’re putting the cart before the horse with your question. Councils normally approve proposals. They’re rarely the ones making the proposals. In those cases, the Data Governance Group is the one that’s going to be tasked with the implementation.

That is the whole article in four sentences, and the rest is what follows from it. The Data Governance Group, in my usage, is the working team that builds what a council approves; who deploys it is a separate question, and it comes up below. The question pictured the council's approval as a signal travelling into the product: a yes in a meeting room that some mechanism inside Profisee has to catch and act on. In the councils I have described before, the yes does not travel anywhere by itself. A proposal arrives in front of the council already written, the council rules on it, and the Data Governance Group goes and builds it. The council's yes is an input to someone else's work, and the work runs on rails the enterprise laid long before anyone stood up a council.

That changes what it can mean for Profisee's dashboards and workflows to support a council. Profisee does not carry the council's decision. It is the thing the decision changes, at one end, and the thing whose numbers the council reads, at the other. The road between the two ends belongs to the enterprise's release process, and in my answer it does not run through Profisee's workflow engine at all. So the useful questions are narrower than "how does Profisee support a council": who brings the council something to sign, how the signed change gets into production without the council or anyone else bending the rules on the way, how the council finds out it happened, and what it reads in the meantime.

Who proposes, who approves, who builds

I have said before that councils earn their place signing off proposed changes and are the wrong body for setting standards or direction, where a room full of decision makers runs into every group project's problem of too many cooks (Keep the Policy, Keep the Score, Move the Council). That view comes from having stood up every part of the traditional governance package at one time or another, not from having skipped one. The answer above is the same view seen from the other side of the table: if the council's useful act is the sign-off, then someone else has to bring it something to sign, and someone else has to carry the signed thing into the systems.

The governance literature mostly agrees on the second half and splits on the first. The Data Governance Institute's description of governance structures puts it plainly: "A Data Governance Council (or Committee) makes high-level decisions," and alongside it sit "one or more tactical teams involved in daily, data-related decisions about how best to turn policy into practice" [5]. That is my division of labour, in a framework's words: the council decides, and the working teams, under whatever name, build. Where the sources part company is on who originates. A study summary of the DAMA framework lists among the steering committee's duties "Approving data policies, standards, and metrics" and also "Setting the strategic priorities for data management projects" [6]. Setting priorities is an originating act. A council that tells the enterprise which entity gets mastered first has proposed something, in a real sense.

I would concede that and hold the line one step down. A priority is not a proposal in the sense my answer means. "Get the customer master right before the item master" is a direction, and a council can reasonably be asked to bless one; I would still rather the direction came from whoever holds the authority to enforce it, with the council ratifying. "Tighten matching on customer names: add a postal-code tie-breaker, and expect fewer false merges" is a proposal, and no council I would build drafts that in the room. The narrower rule still rules something out: a council session that designs a match rule, a survivorship order or a new attribute across the table is doing the Data Governance Group's job badly and its own job not at all. What the council gets is a written change, with its reason and its expected effect, and the decision it is asked to make about it.

Note what that does to the question's three options. A workflow inside Profisee that holds a change until the council signs it presumes the change is already sitting in Profisee waiting for permission. In the order I described, it is not: the council signs a proposal, and only then does anyone make the change, in an environment the council will never open. I did not take up permissions when I answered, so what follows is my view rather than something I have watched: whatever permission scheme a team uses in Profisee, it serves the release process, not the council. Nobody on a council needs a Profisee role to approve anything, and the minutes, far from being the only route, are where the decision is recorded before any of the real route begins.

The road from yes to production

A disclosure, because what follows 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, and our services revenue depends on master data management being bought at all. Those interests run toward praise of Profisee, the category and Microsoft, whose Power BI appears below, so weigh what I say in their favour below what I say against them. Two run the other way: we build our own tooling to integrate Profisee with enterprise systems, which gives us reasons to say the product does less on its own than it does and to understate other firms' deployment offerings, one of which I describe below. Discount those judgements too.

Once the council has signed, my answer hands the change to a process the enterprise already runs:

When tasked, they’ll follow the standard development and deployment process within the Enterprise. In many cases, with Profisee, there will be changes made and tested in the Development environment that will then be exported and moved, via the export, up to the ‘higher’ environments. This process normally involves sign-offs and, in SOX-compliant organizations, requires different people doing the deployment than did the development.

Three things in that paragraph are doing work. The first is that the process is the enterprise's, not the council's and not Profisee's: whatever release discipline governs every other system governs this one. The second is the shape of the Profisee leg, which is develop and test in a lower environment, export, and move the export up. The third is the separation at the end: in SOX-compliant organisations, as I have seen it done, the person who deploys is not the person who built.

The middle step is where Profisee's own shape matters, and I have written about it before (Simple Is a Trade): versioning and source control are not integrated into the product, so moving configuration from one environment to the next means command-line tools or separate tools that talk to the web service interface, and wiring that into continuous integration and delivery needs still more tooling written for the purpose. Profisee's own public material confirms the tool exists without documenting the promotion path. Its partner repository on GitHub names the "Profisee Command Line Utility or CLU" and shows it importing a whole solution, then forms, then matching strategies as a separate step ("/IMPORT /TYPE:MATCHING") [8]. That is a pre-sales demo installer, not a release procedure, but it shows the shape: matching configuration can be moved on its own, which is exactly the unit a council approves when it signs off a match-rule change. Profisee's product documentation sits behind its customer login, and I did not read it for this piece.

The market has filled the gap the way my answer implies it would. One consultancy sells templates on Microsoft's marketplace that "automatically execute the Profisee import and export routines to move configuration, code and data between environments", exporting from development, checking the export into a Git repository, and letting users "raise Pull requests to promote all the latest changes"; it "uses Azure DevOps pipelines functionality to allow deployments to be approved prior to execution" [9]. I cite it for its description, not its quality. What it shows is where the sign-offs in my answer live once the work is automated: in the pull request and in the pipeline's approval step, inside the enterprise's own development tooling, not in Profisee.

What Sarbanes-Oxley actually asks

The "different people" clause is the one a reader in a regulated company will test first. On whether it is the law or the practice, I can only answer from what I watched:

w/r/t SOX compliance. I was there when SOX was first passed and the way companies treated it at that time--and in my experience since--was by having 'Release Administrators' whose job it was to release the changes into Production that were developed by someone else. I can't speak to how other companies have done it or what the legal requirements are--I'm not a business lawyer--but I can speak to how I've seen it implemented and complied with by Fortune 50-sized firms.

That is a witness's account, and the disclaimer in the middle of it is worth taking at its word, because the text of the rules is looser than the practice. The standard that governs auditors of internal control over financial reporting, the PCAOB's AS 2201, refers to "general controls over program changes, access to programs, and computer operations" as controls the auditor tests and relies on [4]. I could not find in it a sentence that says the developer may not deploy; the phrase "segregation of duties" does not appear on the standard's page, and the one place it discusses segregating duties at all is a note about smaller companies' accounting staff, where it has the auditor evaluate "alternative controls" when duties are hard to split [4]. The auditors' standard is the wrong place to look for the expectation, though. On management's side, the internal-control framework many companies use for their own SOX assessment, COSO's 2013 Internal Control — Integrated Framework, does carry segregation of duties, in general terms; its description of control activities, as quoted in KPMG's guide to the framework, says that "Segregation of duties is typically built into the selection and development of control activities," and goes straight on: "Where segregation of duties is not practical, management selects and develops alternative control activities" [13]. Neither document names a Release Administrator. That is how the firms I watched chose to comply, and it is how the separation is now taught, at least in the study guides. A certification study guide for accountants puts it as flatly as I did: developers "must never have administrative, write, or deployment access to production environments," and "A separate individual or automated service account must perform the migration" [7].

That last clause is the one addition I would make to what I watched. The Release Administrator, a person whose whole job is putting other people's changes into production, is how the very large firms I saw met the control, and it is a separation anyone can see on an organisation chart. The same control can also be met by a pipeline running under a service account that no developer controls, which is what an approved Azure DevOps stage amounts to. The study guide accepts either [7]; what neither form allows is the developer who changed the match rule in development also pushing it into production with their own hands.

The case against a gate at all

The strongest objection to everything above comes from software delivery research, and it is aimed squarely at approval bodies. DORA, the research programme behind the State of DevOps reports, says that change approval by "a change advisory board (CAB) or a senior manager" has "a negative impact on software delivery performance," and that "no evidence was found to support the hypothesis that a more formal, external review process was associated with lower change fail rates" [3]. Its alternative is that "change approvals are best implemented through peer review during the development process, supplemented by automation," and it reads segregation of duties as the requirement "that changes must be approved by someone other than the author" [3], which peer review satisfies.

I think DORA is right about the thing it measured, and that thing is not the council in my answer. A change advisory board approves each change on its way to production; the more often it meets and the more it sees, the more it slows. By DORA's definition, which turns on who approves rather than when, the council's sign-off is an external approval, and I concede that. What it approves is different: a business rule, decided once, upstream, where a product owner's requirement sits, before anyone builds it. No deployment waits on the council, and the change ships through peer review and the pipeline without coming back to it. Because a match rule is re-tuned once it meets real data, the line has to be drawn before tuning starts: a council I would build signs the intent and the effect it expects, re-tuning thresholds inside that intent stays with the Data Governance Group's peer review, and only a change to the intent comes back to the room. The cost that remains is real but small: for that one rule, the council's meeting schedule adds lead time. The releases themselves go through whatever approval the enterprise uses for everything else, which may well be peer review and an automated pipeline of exactly the kind DORA recommends. Where DORA's evidence does cut is against the council that wants to see every deployment before it ships. That council has turned itself into a CAB for one system, it will slow the work it governs, and nothing in DORA's data suggests it will make the releases safer. The council signs the what and the why. The how and the when belong to the people DORA is talking about.

Not in Profisee's workflow engine

The question offered a workflow that holds the change as the first option, and Profisee has a workflow engine, so it is fair to ask why my answer reached past it:

This development and deployment process is, itself a workflow, however it’s unlikely the workflow will be implemented via Profisee’s workflow engine.

The release is a workflow: a request, a build, a review, a test, an approval, a deployment, a record. Profisee's workflow is a different kind of workflow, and its own description says so. Profisee defines a data workflow as "a structured, often long-running process that manages how data moves through various stages of validation, correction, and approval," whose tasks "may involve resolving duplicate records, correcting issues identified by verification services or approving updates to data records" [10]. The unit is a record. The 2026 R3 release makes that engine considerably richer, with a visual designer whose toolbox includes "contribute and approval tasks, control flow, data nodes, notifications and calls to Profisee Connect integration strategies," and Profisee frames it in terms that sound like a council's: "Trust also depends on who can change data, what rules govern it and who signs off" [1]. The sentence is about data, and the sign-off it means is a steward approving a change to a record.

My own reading goes one step further. A determined team could model change requests as records in a governance entity inside Profisee and route them through an approval task, and the R3 designer would make that easier than it was. I would not: the change the council approves does not live in Profisee's records. It lives in an export, in a repository, in a pipeline run and in a deployment to an environment, and those span systems that Profisee's workflow cannot see. An approval recorded inside Profisee would sit beside the real evidence rather than being part of it, and the auditor reading the change record for a SOX control will read the enterprise's release tooling, not a stewardship task.

That is a different point from one I have made before. I have called most of Profisee's accountability layer a workflow add-on rather than native (The Queue Nobody Worked), which is a claim about how much Profisee does out of the box. This one is about where change control belongs, and it would hold if Profisee's workflow were perfect. The same split shows in Profisee's audit trail. Microsoft's documentation of the Profisee integration says "The Profisee MDM history and audit tracking subsystem tracks changes that users make" and "also tracks changes that system processes like survivorship make" [11]. Those are changes to data. The same page says model and matching-strategy changes are published to Purview as they occur, which records what the model is, not who changed it or who approved the change. I found no public Profisee page describing an audit of changes to the model or the match configuration, which is one more reason the release record, not the product, has to carry the evidence that the council's change went in as approved.

How the council finds out

The second half of the question asked how the council later sees that the change was made as approved. My answer was candid about how little ceremony there usually is:

The Council will then see the results and, if they’re curious or on an appropriate distribution list, they might also be sent the deployment results and/or the release notes pertaining to the release that included the approved changes.

"Might" is the word to sit with. In my answer the council's confirmation is something it receives if it is curious or on the right list, not something anyone owes it. That is an accurate description of how it usually goes, and it sits uneasily beside the other thing I have said about councils, which is that they persist only while they have required reports to read and decisions to make, and that a council starved of work gets re-absorbed (Give the Council Something to Decide). A decision that leaves the agenda the day it is made, and comes back only to members who go looking, is work the council has been quietly relieved of.

Here I am going past my answer. The cheapest way to close that loop is already in the release process. Change-control practice names a stage after deployment for something close to this: the study guide above calls it "Post-Implementation Verification" [7]. Give each council decision an identifier in the minutes, require the proposal that reaches the Data Governance Group to carry it, and require the release notes, and the change ticket the auditors sample in whatever system the enterprise tracks changes, to cite it. Then put a standing item on the council's agenda, decisions shipped since the last meeting, and read it from the release notes rather than from anyone's memory. That turns my "might" into a required report of exactly the kind that keeps a council alive, and it costs nothing Profisee has to provide. What it rules out is the decision that drops off the agenda before its release does, and the council that learns its match-rule change went in only when someone notices the match rate moved.

What the council reads

The question's second part asked which reports the council looks at every meeting. My answer gave the history and a forecast:

Previously, Councils generally reviewed mastering reports that consolidated throughput, mastered records and other information that were generated off of the records processed through and within Profisee, but the reports themselves were almost always generated in other systems—PowerBI, Tableau, etc. With the advent of the new homepage metrics, I would expect to see that report become a central health report for the Profisee system that would be broadly distributed—including to the Council.

The history matches the measures I use to tell whether the platform is delivering at all: source records in, broken down by source; the count of mastered records; and the completeness of those mastered records as a measure of their value, cut by entity, for the whole system, and for the few entities the business cares most about (Proving the Platform Is Delivering). Councils saw those numbers, or numbers like them, in Power BI or Tableau, built off Profisee's data rather than inside it. Profisee's own integrations point the same way. Microsoft's documentation describes "A dedicated Power BI connector" that "recognizes and enforces role-based security" [11], and the Power Query connector it documents supports import only and leaves relationships between entities to be rebuilt in the Power BI model [12]. The reporting was always going to be built somewhere else, by somebody, and somebody had to keep it running.

The forecast is where 2026 R3 comes in. Profisee's announcement says the release adds "A set of visual charts on the Profisee home page" including "an overall data health score, active data quality issues and a breakdown of match status, so teams no longer need to build and maintain separate reports just to see where things stand" [1]. The release notes describe the KPI strip itself: five key performance indicators, "Total Records, Data Quality Score, Active Data Quality Issues, Golden Records, and Total Entities," each opening onto the changes behind it over a period, and "Accessing this feature requires the new Analytics Viewer role" [2]. When the release came out, those were about the only native reporting I noticed in it. I have not worked with 2026 R3 yet, so what follows tests my expectation against Profisee's description, not against a council that has read the strip.

Against my own measures, the homepage covers more than a single health score and less than a council needs on its own. Total Records may stand in for source records in, and Golden Records for the mastered count; between them they give inflow against output. Data Quality Score is not necessarily my completeness score, and the release notes do not say how it is computed, but in a well-governed model the two should move together, and Active Data Quality Issues adds something my measures never carried: the count of open problems the council's own rules are flagging. What I cannot see in Profisee's description is the by-source cut, or the targeted view of the few entities the business cares about, so I would expect those to stay in Power BI for some time.

The harder question is the one in my phrase "broadly distributed". The release notes put the strip behind a role. A council member who is a business decision maker does not usually hold a Profisee login, and I found nothing in Profisee's announcement or release notes saying the metrics can be exported, scheduled or mailed. So the near-term form of my forecast is modest: the homepage becomes the system's own health report, read first by the people who run it, and reaches the council as whatever the Data Governance Group brings to the meeting, a screen in the room or a page in the pre-read. That is still a real change. The report everyone used to rebuild in another tool becomes the vendor's to maintain, and the custom reports that remain can be the ones that answer the council's own decisions.

What the homepage does not show is the council's own work. A health score tells the council whether the data is getting better. It does not tell the council whether the three changes it approved last quarter shipped, or whether the match-rule change moved the match rate the way the proposal said it would. Those two come from the release notes and from comparing the health report before and after the release, which is why I would put both on the same agenda.

Something to sign, something to read

The question I started from was how Profisee's dashboards and workflows can support a high-impact council. My answer is that Profisee supports a council at its two ends and should be kept out of the middle. At the front end, Profisee is the system the council's decisions change, and the change reaches it the way any change reaches any governed system: written before it reaches the council, signed by the council, built and tested by the Data Governance Group in a lower environment, exported, and deployed by someone, or something, other than the person who built it. At the back end, Profisee is the source of the numbers the council reads, and 2026 R3 moves the first of those numbers onto the vendor's own home page. Between the two ends, the enterprise's release process carries the decision, and the only thing the council needs from it is the release note that says its decision shipped.

That is less than the question promised and more useful than it sounds. A council that understands it approves and does not build will not try to run its sign-offs through a stewardship workflow, will not demand a seat at every deployment, and will not mistake a health score for a record of its own decisions. Give it something to sign, and something to read that tells it whether what it signed made any difference.

References

[1] Eric Melcher, "Profisee 2026 R3: Smarter. More Connected. Built on Trust.," Profisee blog, 12 October 2026. Read in Chrome 2026-11-01; quoted passages copied from the page text. Vendor page (the vendor we partner with). https://profisee.com/blog/profisee-2026-r3-smarter-more-connected-built-on-trust/

[2] Profisee, "New Features and Enhancements for 2026 R3," Profisee release notes, support.profisee.com. Login required; the Homepage Metrics entry re-read in Chrome with a Profisee Community account 2026-11-01. Vendor documentation (the vendor we partner with). https://support.profisee.com/wikis/release_notes/New_Features_and_Enhancements_for_2026-R3

[3] DORA, "Capabilities: Streamlining change approval," dora.dev. Read in Chrome 2026-11-01. https://dora.dev/capabilities/streamlining-change-approval/

[4] Public Company Accounting Oversight Board, "AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements," pcaobus.org. Searched in Chrome 2026-11-01 for program changes and segregation of duties; .B29 and the note to .42 read. https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201

[5] The Data Governance Institute, "Defining Organizational Structures," datagovernance.com. Read in Chrome 2026-11-01. https://datagovernance.com/defining-organizational-structures/

[6] OpenExamPrep, "Data Management Organization & Roles," CDMP study guide, open-exam-prep.com. Read 2026-11-01; a secondary summary of DAMA-DMBOK, which was not read. https://open-exam-prep.com/study-guides/cdmp/exam-overview-dmbok/data-management-organization

[7] OpenExamPrep, "Program Change Management & Release Controls," CPA ISC study guide, open-exam-prep.com. Read in Chrome 2026-11-01; a study guide, cited for how the control is taught, not as an authority. https://open-exam-prep.com/study-guides/cpa-isc/ch-3-itgc-sdlc-application-controls/change-management

[8] Profisee, "partners" repository ("Repository to help the Profisee partners deploy a pre-sales solution"), GitHub. Read in Chrome 2026-11-01. Vendor page (the vendor we partner with). https://github.com/Profisee/partners

[9] "Profisee DevOps," Microsoft Marketplace listing. Read in Chrome 2026-11-01. A consultancy's Profisee deployment offering, competing with the practice's own tooling. https://marketplace.microsoft.com/en-za/product/valcon1679492209912.profiseedevops

[10] Profisee, "Data Workflow Management Tool," Profisee platform page (Workflow FAQs). Read in Chrome 2026-11-01. Vendor page (the vendor we partner with). https://profisee.com/platform/workflow/

[11] Microsoft, "Microsoft Purview and Profisee Master Data Management (MDM)," Microsoft Learn. Read in Chrome 2026-11-01. https://learn.microsoft.com/en-us/purview/data-governance-master-data-management-profisee

[12] Microsoft, "Power Query Profisee connector," Microsoft Learn. Read in Chrome 2026-11-01. https://learn.microsoft.com/en-us/power-query/connectors/profisee

[13] KPMG LLP (Canada), "COSO Internal Control – Integrated Framework (2013)" (KPMG's guide to the framework, © 2013 KPMG LLP), hosted by KPMG. Read 2026-11-01 in Chrome, partial: the Control Activities discussion (p. 4), where the quoted sentence sits inside KPMG's quotation of the framework's own description of control activities; the COSO framework itself, which is sold, was not read. https://assets.kpmg.com/content/dam/kpmg/pdf/2016/05/2750-New-COSO-2013-Framework-WHITEPAPER-V4.pdf