Low-Code Governance Vocabulary — Low-Code & No-Code Exercises

1 / 5

An enterprise decides to scale low-code adoption across 12 business units. The CTO says: "We need to establish a Center of Excellence before this gets out of hand." What is a CoE in the context of low-code, and what does it do?

The Center of Excellence is the organisational structure that makes enterprise-scale low-code adoption sustainable and governable — understanding CoE vocabulary is essential for anyone involved in low-code strategy discussions.

Core CoE responsibilities:

Responsibility	What it means in practice
Standards & templates	Approved component library, naming conventions, approved connectors list
Training & enablement	Citizen developer training programmes, hackathons, office hours
Governance enforcement	DLP policies, environment strategy, capacity management
Inventory & monitoring	Dashboard of all flows/apps in tenant, orphaned resource cleanup, dependency management
Risk management	Security review of new connectors, data classification enforcement

The Microsoft CoE Starter Kit:
Microsoft provides a free open-source CoE Starter Kit (a set of Power Apps and Power Automate flows) that a CoE team can deploy to gain visibility over the entire Power Platform tenant — apps, flows, custom connectors, environments, and license consumption — without requiring manual inventory.

Key vocabulary:
• Center of Excellence (CoE) — a cross-functional team governing low-code adoption across an organisation
• DLP policy — Data Loss Prevention policy; controls which connectors can be used together in a flow
• Environment strategy — the plan for how sandbox, development, test, and production environments are structured and access-controlled
• Tenant — in Azure/Power Platform, the entire organisation's instance; all users and environments belong to one tenant

2 / 5

An IT manager discovers that a sales team has built 47 Power Automate flows that send customer data to an unapproved external CRM via a custom connector — all without IT's knowledge. This situation is described as "shadow IT". What is shadow IT and why is it a governance concern?

Shadow IT in the low-code era is particularly complex because the same platform (Power Platform, Salesforce Flow) that IT uses officially is also freely available to all licensed users — creating shadow IT at scale without any technical barriers.

Shadow IT risk taxonomy for low-code:

Risk category	Example in low-code context
Security	Customer PII sent to unapproved external SaaS via unofficial connector
Compliance	GDPR-regulated data leaving the approved data residency region
Operational	Business-critical flow with no documentation, no support SLA, single developer
Integration	Unofficial automation relies on an internal API that IT changes, breaking the flow silently
Key-person dependency	The one person who built the critical flow leaves the company

CoE shadow IT mitigation:
• DLP policy enforcement blocks unapproved connectors from being paired with sensitive data connectors
• Regular CoE inventory scans surface new apps/flows before they become entrenched
• Citizen developer training and official channels give business users approved paths to automate, reducing shadow IT incentive
• "Fusion team" approach: citizen developers work alongside IT in structured projects, eliminating the unofficial parallel track

Key vocabulary:
• Shadow IT — technology used within an organisation without IT department knowledge or approval
• Citizen developer — a business user who builds apps and automations using low-code tools
• Key-person dependency — critical knowledge or skills concentrated in one individual who could leave
• Fusion team — a mixed team of professional developers and citizen developers collaborating on a low-code project

3 / 5

An IT architect presents a governance plan: "We need to implement ALM for all Power Platform solutions — development, test, and production environments with proper solution management." What is ALM in low-code, and why is it more complex than it sounds?

ALM for low-code is consistently underestimated — organisations discover major ALM complexity only after they've already built many solutions in production without environment separation.

Power Platform ALM key concepts:

Concept	What it means
Solution	A container packaging related apps, flows, tables, and connection references into a deployable unit
Environment variable	Configuration value that differs per environment — e.g. API endpoint, SharePoint site URL
Connection reference	A named placeholder for a connector connection; resolves to different actual connections per environment
Managed solution	A solution deployed to test/production that cannot be directly edited — enforces change management
Unmanaged solution	A solution in development that can be freely edited — source of truth is in source control

Typical enterprise environment strategy:
DEV (unmanaged solutions, developer access) → TEST (managed solutions, QA access) → PROD (managed solutions, no developer access)

ALM pipeline automation options:
• Microsoft Power Platform Build Tools for Azure DevOps
• GitHub Actions for Power Platform
• Power Platform CLI (pac) for command-line deployments

Key vocabulary:
• ALM (Application Lifecycle Management) — managing a solution from development through deployment and maintenance
• Solution — a deployable container of Power Platform components
• Environment variable — a per-environment configuration value referenced by a solution
• Connection reference — a portable connector reference that resolves per environment

4 / 5

A CoE team creates a low-code app catalogue and makes it available to all business units. A manager asks: "Why do we need this? Can't people just build what they need?" What is the purpose of a low-code app catalogue?

The low-code app catalogue addresses one of the most common and costly governance failures in large organisations: the same solution being rebuilt independently by multiple teams, wasting resources and fragmenting data.

Why duplicate solutions proliferate without a catalogue:
• Low-code solutions are fast to build — a team can create an expense approval app in a day
• Without visibility, other teams don't know a solution already exists
• Over time, the same business process is automated by 5 different teams with 5 different approaches, none compatible with each other
• Time and money wasted; data is split across incompatible systems; end users get inconsistent experiences

What a mature app catalogue includes:

Catalogue field	Purpose
Solution name & owner	Who built it and who to contact for support
Business function covered	Enables search by business need; prevents duplicates
Support tier (CoE, owner, none)	Sets stakeholder expectations for reliability
Status (active, deprecated, archived)	Prevents adoption of unmaintained solutions
Data sensitivity classification	Informs access control and compliance review requirements

Key vocabulary:
• App catalogue — a central inventory of available low-code solutions with governance metadata
• Solution reuse — adopting or adapting an existing solution rather than building a new one
• Support tier — the level of official support commitment (CoE-managed, owner-managed, community, unsupported)
• App sprawl — uncontrolled proliferation of low-code solutions without governance or lifecycle management

5 / 5

A Power Platform administrator runs a CoE inventory report and finds 340 flows created by employees who have since left the company — they describe the situation as "app sprawl". What is app sprawl and what governance mechanisms prevent it?

App sprawl is an inevitable governance challenge at any organisation that has successfully scaled low-code adoption — it is the "success problem" of low-code governance.

How app sprawl accumulates:
① Citizen developer builds a flow for a specific one-time event (onboarding wave, event registration)
② Flow is never turned off after the event ends
③ Developer changes roles or leaves the organisation
④ Flow has no successor owner — IT receives support tickets for a flow nobody understands
⑤ Connection credentials expire, flow breaks, nobody notices for weeks
⑥ Multiply by hundreds of developers over several years

Governance mechanisms for sprawl prevention:

Mechanism	Description
Maker access control	License-gate production environment; only trained, approved makers can deploy to production
Ownership tracking	CoE inventory links every solution to an active employee; HR system triggers review when owner leaves
Quarterly review	CoE sends usage reports to business owners: "Is this flow still needed?"
Inactivity automation	CoE toolkit monitors flows not run in 90+ days and sends auto-notification to owner
Decommission process	Formal archival: turn off, export package for records, remove connections, document closure

Key vocabulary:
• App sprawl — the uncontrolled accumulation of low-code solutions without governance or lifecycle management
• Orphaned solution — a low-code app or flow whose owner has left the organisation or changed roles
• Maker access control — governance policy restricting who can build and deploy solutions to which environments
• Decommissioning — the formal retirement process for a low-code solution: disable, archive, remove access