Lowcode Governance Standards

Low-code / no-code governance standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Governance of development platforms with little or no code: who can build, where, with what data, with what credentials, who answers for it afterwards and what it costs once you depend on it.

Triggers: Power Platform (Power Apps, Power Automate, Dataverse, Copilot Studio, Power Pages), default environment, environments and environment groups, managed environments, data policies / DLP and their connector groups, premium and custom connectors, connection references, orphaned flows, solutions and ALM, CoE Starter Kit, Get-AdminFlow/Set-AdminFlowOwnerRole, OutSystems, Mendix, Appian, Retool, n8n, Zapier, Airtable, citizen developer, shadow IT.

The thesis of this skill, and everything else derives from it: the low-code problem is not technical, it is a governance problem. The platform works; what fails is that nobody knows what exists, whose identity it runs under, who maintains it and what it will cost next year. A coding error produces an exception; a governance error produces a critical application with no owner, a connector holding the credentials of someone who no longer works here and a bill discovered at renewal time.

Falsifiable corollary, applicable to any citizen development programme anyone presents to you: show me the inventory. If there is no list of applications and automations with a named owner, criticality and last review date, there is no low-code programme: there is shadow IT with a corporate logo. Second corollary, an uncomfortable one: banning it is not a governance strategy — it only moves the activity into spreadsheets with macros and personal SaaS accounts, where you see nothing.

Not applicable: see ai-governance-standards (critical and heavily travelled boundary: theirs are the AI system inventory, AI Act risk classification, the provider/deployer split, human oversight, transparency and serious incident reporting. Mine, when that agent lives inside a low-code platform: where it is deployed, under what identity it runs, which connectors it reaches, who owns it and what it consumes. Arbitration rule: if the question is whether that agent may exist and under what obligations, it is theirs; if it is which environment it lives in, which credential it runs under and who maintains it, it belongs here. The two inventories reference each other, they do not duplicate each other), enterprise-architecture-standards (hard reciprocal: the corporate application inventory with owner, criticality and lifecycle is theirs, and it is the natural destination of whatever gets promoted from here. A low-code app that becomes critical enters their inventory; the catalogue of those that remain a personal tool stays here), itsm-itil-standards (the service, the SLA and the change process once the app is already a supported service), identity-access-management-standards (identity, SSO, service accounts and the joiner-mover-leaver cycle — here the concrete effect of an employee leaving on a connection, §3.3), secrets-management-standards (custody and rotation of credentials), privacy-engineering-standards (personal data, minimisation, retention and deletion in citizen apps), accessibility-standards (WCAG technical criteria and their verification; here only the obligation that it apply to what the business builds too), grc-compliance-standards (control framework, risk and audit evidence), finops-standards (cost-per-economic-unit method; here the licensing model and its jumps), crm-salesforce-standards (Salesforce as a configurable platform has its own document: Flow, permissions, governor limits and packages), erp-sap-standards (relevant reciprocal warning: a low-code flow that creates documents in SAP triggers indirect access and gets billed — it is assessed there before being built here), opensource-licensing-standards (method boundary: there SPDX, copyleft and the gate in the PR; here commercial platform licences. Real point of contact: n8n is not OSI open source —Sustainable Use License, fair-code— and that distinction is resolved with their method, §3.6), cicd-standards (the pipeline; here what gets promoted and from where), refactoring-tech-debt-standards (general technical debt; here the rewrite criteria, §3.7).

2. Default decisions

Verify on the web before pinning it (§8): licences, quotas and product names of these platforms change several times a year, and prices for the enterprise-grade ones are not published.

3. Structure and conventions

3.1 What makes this domain different

Three properties change the problem relative to normal software, and they are worth making explicit:

1. The builder is not from IT and does not have to be. Any control that requires them to be fails: they route around it or stop using the platform.
2. The artifact is not a file. There is no repository by default, no PR, no grep. If you do not inventory it with the admin API, it does not exist for you even though it exists for 200 people.
3. The execution identity is a person's by default. That is the domain's original sin and the origin of nearly every incident (§3.3).

3.2 The default environment: open by design

Data verified verbatim in Microsoft's documentation (Aug 2026, §8), because it is the point that gets misread the most:

• "Each tenant has a default environment that's created automatically." — it already exists, whether you look at it or not.
• "All licensed users have the environment maker role" — and the list of "licensed" includes Microsoft 365 users and free or trial licences. In practice: your whole company is a maker there.
• "Whenever a new user signs up for Power Apps, they're automatically added to the Maker role of the default environment. No users are automatically added to the Environment Admin role" — nobody administers it by default.
• "This is a predefined type of environment intended for experimentation, exploration, and lightweight, app trial development. The default environment doesn't provide any backup guarantees and shouldn't be used for production workloads." — the vendor says so. Even so it is where half of what is critical shows up, because it is where the button takes you by default.
• "You can't delete the default environment. You can't manually back up the default environment" — you cannot make it go away: you can only govern it.
• Included capacity: 3 GB of Dataverse database, 3 GB of files, 1 GB of logs, capped at 1 TB of storage in the environment.

Minimum actions, and they are day one of the programme:

1. Rename it to something that says what it is (Microsoft literally suggests something like Personal Productivity Environment). The name is a control: it communicates that this is not production.
2. Assign named administrators —Microsoft warns of the risk of administrative lockout if nobody holds the system administrator role—, and do it with a few trusted users.
3. Apply the tenant's strictest data policy there (§3.4).
4. Restrict environment creation to administrators, and give every maker their own development environment: you are not asking them to stop building, you are giving them a better place.
5. Inventory what is already inside (§3.5) before touching anything: that is where the surprises are.
6. Design the environment architecture —development / test / production per domain, with environment groups and rules— for what gets promoted (§3.7).

3.3 Execution identity: the connector with the credentials of whoever leaves

The mechanism, verified (Microsoft documentation, verbatim): "When a maker first adds a connector to an app, they establish a connection by using the authentication protocols that the connector supports. These connections represent a saved credential and are stored within the environment that hosts the app or flow." Translated: the automation stores a person's credential and acts as that person, with all of their permissions, indefinitely.

The two faces of the same failure:

• While the person is there: the flow has a human's permissions, not the ones it needs. An administrator with broad access builds a flow that, in effect, exposes that broad access to anyone they share the app with. It is privilege escalation without an exploit.
• When the person leaves: the flow is left orphaned. Microsoft documents it under that name — "An orphaned flow is a flow that no longer has a valid owner. These flows can fail if they use connections tied to that user account." The operational consequence nobody rehearses: payroll, reconciliation or the customer notification stops running the day HR disables the account, and diagnosis takes weeks because nobody knew that process was a flow.

Controls, in order of effectiveness:

1. Any automation that someone other than its author depends on runs under a service account or a service principal. This is not a recommendation: it is the condition for classifying it above "personal" (§3.5).
2. Mandatory co-owner —at least two— on everything shared. It is the cheap minimum.
3. The employee offboarding process includes a sweep of the platform. It is detected with the admin API: in Power Platform, Get-AdminFlow + Get-AdminFlowOwnerRole against the directory, and Set-AdminFlowOwnerRole to reassign. Automated and run before the offboarding, not after. A leaver discovered through a broken flow is a failure of the identity process (identity-access-management-standards), and this is its most expensive manifestation.
4. Reassigning the owner does not fix the connection: the credential belongs to the user and the connection has to be rebuilt. Account for it in the runbook.
5. Custom connectors and credentials: never secrets embedded in the definition; custody per secrets-management-standards.

3.4 Data policies (DLP): a real control, with real limits

How they work (Microsoft documentation, Aug 2026): the policies classify connectors into groups —business, non-business and blocked— and an artifact cannot combine connectors from different groups. It is a surface control, and it is effective: it prevents building the bridge between the corporate system and the personal destination.

What you need to know so as not to overestimate it — and this decides the design of the control:

• It classifies connectors, not data. It does not inspect content: if two connectors are in the same group, moving data between them is legitimate for the policy even if it is a leak.
• Design time and run time are two different moments. At design time the maker cannot save; at run time, what was already built moves to suspended/quarantine and blocked connections to disabled. That is: a new policy breaks existing automations. It is introduced by measuring impact first, with notice and a window — or it produces a self-inflicted outage.
• Enforcement is not immediate: verbatim, "For the most extreme cases, the latency for full enforcement is 24 hours. In most cases, it's within an hour." It is not a real-time control and it is no use as an incident response.
• There are connectors that cannot be blocked (nonblockable), and there are "virtual" connectors that govern functions rather than APIs, with their own evolving rules. Verify which ones before assuming your policy covers everything.
• The custom connector is the side door: it lets you reach any API. Its publication at tenant level is reviewed as a security change, not as a configuration.

Default posture: default-deny — new connector, blocked until someone classifies it; strict policy in the default environment and in the development ones; per-environment/group policies for production, with named, justified and time-limited exceptions.

3.5 Inventory, owner and criticality: the core of governance

Without an inventory there is no governance, and the inventory has to be automatic. It is built from the platform's admin API (in Power Platform, the CoE Starter Kit is the usual and Microsoft-provided route, but it is an open source solution that you operate and maintain, not a supported product: treat it as an internal application with an owner). Minimum fields per artifact: named owner and deputy, purpose in one sentence, environment, connectors and systems it touches, number of real users, personal data yes/no, criticality, last review date.

Classification, with written criteria and different consequences:

The trigger nobody watches and must be watched: growth. The app someone in finance built for themselves and that 200 people depend on today changed category without anyone deciding it. Hard rule: the number of users and the criticality are reviewed periodically and automatically, and crossing a threshold opens a ticket, not an email. The question "who maintains this?" has to be asked before the answer is "nobody, they left".

Full lifecycle, or the inventory rots: registration with an owner → measured usage → periodic review (is it still used? does it still have an owner?) → retirement. Whatever nobody uses in a quarter gets disabled after notice; whatever is disabled and nobody claims gets deleted. Without retirement, an inventory is a list that grows until it is useless.

3.6 The cost that shows up later

The pattern of the domain: cheap to start, expensive once you already depend on it. The honest decision point is before building, modelling the success scenario (what if 500 people use it?), not the pilot with ten.

Microsoft prices verified verbatim on microsoft.com (Aug 2026, §8):

• Power Apps Premium: "$20.00 user/month, paid yearly", with 250 MB of database and 2 GB of file in Dataverse. With a minimum of 2,000 seats, "$12.00 user/month, paid yearly".
• Power Apps Developer Plan: "Free", 2 GB of database, 750 flows per month — it is a development plan, not a production one.
• Power Automate Premium: "$15.00 user/month, paid yearly", includes attended RPA. Power Automate Process: "$150.00 bot/month", unattended RPA. Hosted Process: "$215.00 bot/month", with a managed virtual machine.
• Copilot Studio: "sold as tenant-wide license which includes Copilot Credit capacity packs of 25,000 Copilot Credits each, priced at $200.00/pack/month", and "Whenever an action or response is completed by an agent, a varying number of Copilot Credits will be billed depending on the specific usage". Governance translation: consumption per interaction is variable and it is not controlled by the budget, it is controlled by the agent's design. A badly designed agent multiplies the cost without changing functionality — budgeting by number of users is a methodological error.

The jump you discover late, and it deserves its own name: premium connectors. Whatever gets built with standard connectors comes out under the licence you already have; the moment the app touches a premium connector —databases, many SaaS, generic HTTP, custom connectors— every user of that app needs a paid licence. The operational rule that avoids disaster: the decision to use a premium connector is taken with the end-user count done, not as a technical detail of the maker. It is exactly the same error, under another name, on every platform.

The other metering models, to recognise the pattern (via web search; apart from Microsoft and n8n, none of these figures is verified against the vendor's source — OutSystems and Appian do not publish prices: "not published" is the datum):

And the licence, not just the price: n8n is not open source according to the OSI. Its LICENSE.md (verified raw) is the Sustainable Use License —fair-code—: it grants use "for your own internal business purposes or for non-commercial or personal use", forbids commercial distribution and segregates the enterprise features (files and directories with .ee) under a separate licence. Self-hosting it does not free you from conditions. If someone puts it in the catalogue as "open source", correct it: the analysis of the clause belongs to opensource-licensing-standards.

Cross-cutting cost rule, and it is the only one that works: the licensing model is documented in the artifact's inventory record (§3.5), with the marginal cost of one more user. Renewal is prepared six months ahead with measured consumption, seats actually used and a list of what nobody uses.

3.7 Real ALM, and when to stop using low-code

For anything classified as critical, real ALM and no exceptions: separate development, test and production environments; the artifact packaged (in Power Platform, solutions with connection references and environment variables, so that promotion does not drag credentials or development URLs along); export to version control; automated deployment; and production with no manual editing. "Editing in production" is the practice that makes no lower environment represent reality, and from that point on no test means anything. The pipeline mechanics belong to cicd-standards; the rule that one must exist belongs here.

What is almost never done and must be done: backup and restore testing of the artifact and its data, and tests —even if they are a signed manual checklist— for anything critical. Careful: the default environment offers no backup guarantees, and the vendor says so (§3.2).

Criteria for rewriting it as real software. It is not "low-code is worse": it is that there are signals indicating that the cost of staying already exceeds the cost of leaving. Two or more of these → the rewrite gets planned:

• The logic no longer fits: dozens of steps, nested conditions and nobody can reason about the flow.
• It cannot be tested automatically and its failure has real consequences.
• Performance or volume hit the platform's limits recurrently.
• The licensing cost per user exceeds building and operating it (do the maths in years, not months).
• People outside the organisation need it, or it is customer-facing.
• Vendor risk: you are locked into a proprietary engine with no documented way out.
• IT already maintains it in practice, so the saving that justified low-code no longer exists.

And the symmetrical criterion, which gets forgotten: if none of them holds, rewriting destroys value. The three-screen application that solves a real problem for a department does not need to become a microservice. The right answer is often to adopt it as it is: give it an owner, a service account, a backup and a line in the inventory.

3.8 Personal data and accessibility in citizen apps

• The maker does not decide about personal data. Any artifact that processes personal data goes through prior review: legal basis, minimisation, retention and deletion (privacy-engineering-standards). The typical and forbidden case: extracting a listing with employee or customer data to a personal file "to work with it".
• Retention and deletion also apply to the run history of the automations and to the data left behind on the platform. It is defined at registration, not when the DSAR arrives.
• Accessibility: if the app is used by your own staff or by the public, accessibility obligations apply just the same — the fact that someone in finance built it with an assistant does not change the rule. The corporate template and a minimum checklist are the cheap control; the technical criteria belong to accessibility-standards.
• Agents and copilots inside the platform: they go into the AI inventory and the risk classification of ai-governance-standards. What is required here: environment, execution identity, reachable connectors, owner and consumption (§3.3, §3.6).

4. Controls and verification

In increasing order of cost. The first three are the baseline of any programme:

1. Automated and up-to-date inventory of every artifact, environment, custom connector and connection, with an owner (§3.5). Without this, no subsequent control has an enumerable scope.
2. Scheduled orphan sweep, cross-checking owners against the directory (§3.3), integrated with the employee offboarding process.
3. Data policy applied with a prior impact inventory and a notice window (§3.4).
4. Review of critical artifacts: that they have a service account, a co-owner, a backup, their own production environment and a documented test.
5. Review of custom connectors published at tenant level, as a security change.
6. Consumption and cost measurement per environment and per artifact, with an alert before the threshold (§3.6).
7. Quarterly audit: artifacts with no usage, no owner, with broad permissions or shared with "the whole organisation" — this last one is the local equivalent of a public bucket.

5. Security

• Sharing with "everyone in the organisation" is a security decision and is treated as such: it is recorded, reviewed and discouraged by default.
• The maker's permissions are the artifact's permissions (§3.3). A flow cannot access less than its credential accesses: least privilege is implemented in the service account, not in the design of the flow.
• Exfiltration via connector: the canonical scenario is personal mail or storage in the same group as a corporate system. It is exactly what the policies in §3.4 exist to cut off, and that is why their classification cannot be lax.
• Platform audit log enabled and retained, with who created, shared and ran what. Check whether your licence includes it: on several platforms fine-grained auditing is a higher price tier — and discovering that during an incident is too late.
• Portals and public sites built with these platforms are applications exposed to the Internet: threat modelling and prior review are mandatory (appsec-standards). That they were built with a mouse does not change their attack surface.
• Secrets: never in visible variables, in the body of the flow or in the definition of a custom connector.

6. Operability

• Anything critical needs alerting and on-call. A flow that fails silently and nobody looks at is a deferred incident. Minimum: failure notification to a team mailbox (not to a person) and a reviewed panel of failed runs.
• Minimum runbook per critical artifact: what it does, what it depends on, what to do if it fails, who to notify. It fits on one page; its absence is what turns an outage into three days of archaeology.
• Retries and volume: an automation retrying in a loop against a corporate system is both an outage and a bill (of tasks, of credits or of indirect access).
• Platform service limits (requests per connection, size, concurrency): they are verified before designing anything high-volume. If the design depends on sitting just below a limit, the design is wrong.

7. Sustainability and prohibitions

• ❌ FORBIDDEN for an automation that more than one person depends on to run under someone's personal credential.
• ❌ FORBIDDEN a shared artifact with no named owner, deputy and inventory entry. With no owner, it gets disabled after notice.
• ❌ FORBIDDEN to use the default environment as production. The vendor says so and it offers no backup guarantees.
• ❌ FORBIDDEN to leave the default environment with no strict data policy and no named administrators.
• ❌ FORBIDDEN to deploy a data policy without measuring beforehand which artifacts it breaks: it suspends what exists, and with up to 24 h of latency.
• ❌ FORBIDDEN to edit in production an artifact classified as critical.
• ❌ FORBIDDEN to process personal data in a citizen app without prior review, and forbidden to copy production data into a test environment without masking.
• ❌ FORBIDDEN to use a premium or custom connector without the end-user cost count done and without a security review of the connector.
• ❌ FORBIDDEN to publish a custom connector at tenant level without review.
• ❌ FORBIDDEN to ban low-code without offering an alternative: it pushes the activity to where you cannot see it.
• ❌ FORBIDDEN to cite low-code productivity figures ("X times faster", "10× less code") as a decision argument. They are vendor marketing figures, with no published methodology or sample, and they compare a pilot against a full development. What is defensible is measured at home: time to first real use and total cost over three years, including licence, maintenance and the rewrite if it comes (§3.7). The catalogue has already dismantled the same pattern with the CHAOS Report (project-management-standards) and with ERP failure rates (erp-sap-standards).
• ❌ FORBIDDEN to declare "we have low-code governance" without being able to show the inventory with owners and the date of the last review.
• Cadence: continuous inventory, orphan sweep on every employee offboarding, criticality and usage review quarterly, review of data policies and new connectors quarterly (the platforms add connectors constantly, and an unclassified new connector is a hole by omission), and contract review six months before renewal.

8. Mandatory web verification

Before pinning any datum from this document:

1. Default environment and environment types: verified verbatim at learn.microsoft.com/power-platform/admin/environments-overview (Aug 2026). Check included capacities and roles, which Microsoft changes without notice.
2. Data policies: verified verbatim at learn.microsoft.com/power-platform/admin/wp-data-loss-prevention. Check in particular the list of nonblockable connectors and the status of virtual connectors and of the advanced connector policies, which were in transition as of Aug 2026.
3. Orphaned flows: procedure and cmdlets verified in the raw source of the Microsoft support article (SupportArticles-docs, manage-orphan-flow-when-owner-leaves-org.md, document date 11 Jun 2026). Warning: the official example uses the AzureAD module, which is deprecated — rewrite it against Microsoft Graph before using it.
4. Microsoft prices: verified verbatim on microsoft.com (Power Apps, Power Automate, Copilot Studio) as of Aug 2026. They change, and the Copilot Studio model migrated from "messages" to "credits": verify the current name and unit before budgeting.
5. Prices of the other platforms: declared gap. The figures for OutSystems, Mendix, Appian, Retool, Zapier and Airtable in §3.6 come from web search and third-party pages, not from the vendor's source; OutSystems and Appian do not publish prices and only quote. Use them to recognise the metering model, never as a figure in a budget.
6. n8n licence: verified raw (LICENSE.md from the repository). Re-read it before deploying: it is fair-code, not OSI, and the terms have changed in the past.
7. Product status: retirements, renames and packaging changes. In this domain the names change every few quarters and the service limits with them.

If the web contradicts this document, the web wins — flag the discrepancy.