Skip to content
Updated: 6 min read

Citizen Developers: Governing Low-Code Growth in Your Company

How to govern citizen development on low-code platforms: a Center of Excellence, roles mapped in a RACI matrix, an environment strategy, data policies for connectors, Managed Environments and application lifecycle management.

Łukasz Szymański Author: Łukasz Szymański

A citizen developer is someone in a business team who builds apps and automations on a low-code platform without a programming background. Governing that work is not about shutting it down. It is about setting the boundaries: who can build, in which environment, with which data, and how an app gets from prototype to production.

Quick Overview

What you will learn:

  • Who citizen developers are and where the risks of unmanaged growth come from
  • Which roles you need for low-code governance to work
  • How to set up environments, data policies and application lifecycle management
  • Where to start when apps are already being built without IT knowing

Who this article is for:

  • IT managers and architects responsible for low-code platforms
  • Power Platform administrators and security teams
  • Business managers whose teams build their own apps

Reading time: 7 minutes

Who Citizen Developers Are

AWS (aws.amazon.com) describes low code as a way of building software with minimal hand-written code, using ready-made tools, components and templates. Business users with little or no coding experience who build applications themselves are, in the same text, called citizen developers. Microsoft’s Power Platform documentation on learn.microsoft.com uses a broader term, makers, which covers everyone from citizen developers to professional developers.

What makes the model powerful also makes it risky. A procurement specialist who builds an order-approval app understands the process better than anyone in IT. What they may not see is that the app moves HR data to an outside service, or that nobody will be able to fix it once they leave. Microsoft’s guidance on adoption roles spells out the cost of weak governance: security gaps, data breaches, regulatory non-compliance, duplicated effort and projects that drift away from business goals.

Who Owns What

Microsoft recommends capturing responsibilities in a RACI matrix (Responsible, Accountable, Consulted, Informed). The Power Platform adoption guidance lists roles such as these:

  • Center of Excellence (CoE): the team that sets standards, runs training and supports makers. The guidance also calls it a Center of Enablement, because its job is to help people build, not only to police them. A CoE lead runs it.
  • Executive sponsor: sets direction, secures resources and communicates the vision.
  • Power Platform product owner: owns the platform’s direction, roadmap and governance framework.
  • Platform and environment admins: configure security, monitor the platform and put guardrails in place.
  • Information security and compliance team: checks the platform against internal policy and regulation.
  • Makers: build solutions within the agreed guardrails.
  • Champions: enthusiasts in business teams who tell the CoE what works and where makers need more support.

Early on, one person may wear several of these hats. As adoption matures, the guidance says, roles should be refined and split.

Three Governance Levers

Environment strategy. According to Microsoft, many organizations start with a single shared default environment where everyone builds and shares apps. Microsoft advises moving away from that. Default environment routing sends makers to their own personal developer environments. Sandbox environments are meant for testing and release builds, and production environments for work the business depends on. Environment groups let you apply the same rules to many environments at once.

Data policies. Connectors are how an app reaches data, from email to the ERP system. Data policies in the Power Platform admin center can block a whole connector or individual actions. A maker then cannot save an app or flow that uses the blocked connector, and existing resources that rely on it are suspended. It pays to check the impact on running apps before changing a policy.

Managed Environments. Microsoft packages many of these controls as Managed Environments, a set of premium admin capabilities that includes environment groups, sharing limits, weekly usage insights, data policies, pipelines and maker welcome content. Microsoft has announced the deprecation of unmanaged developer environments, so this is where governance in Power Platform is heading.

Application lifecycle management (ALM). An app that a process depends on needs versions, testing and controlled deployment. In Power Platform that means solutions, moved between environments by export and import, and pipelines that promote assets from development to test and production. The documentation recommends source control as the source of truth for components and a Dataverse database in every environment that takes part in ALM.

Where to Start

  • Take stock. Find out who is already building apps and which connectors they use. The CoE Starter Kit is no longer actively maintained and its core capabilities now live in the Power Platform admin center, so the built-in reports are the place to begin.
  • Roles before rules. Name a platform owner and a CoE lead before the first policy is written.
  • Lock down the default environment. Cover it with data policies and route makers to developer environments.
  • Define the path to production. Agree how an app moves from prototype to test to production once a business process depends on it.
  • Grow a maker community. Microsoft’s guidance lists training and documentation for makers, a library of assets such as custom connectors, and an internal community of champions.

Read Also

Build Your Skills

Two trainings cover this topic: Citizen Development: Building Applications Without Coding and Low-Code/No-Code: Power Platform, Mendix, OutSystems. The first covers the principles of citizen development, data and permission management and the application lifecycle; the second compares platforms and walks through designing a governance model and a Center of Excellence. Get in touch to tailor the scope to your team.

Frequently Asked Questions (FAQ)

What Is Low-Code?

According to aws.amazon.com, low code is a way of building applications with minimal hand-written code, using ready-made tools, components and templates. That lets specialists in business teams build apps too, and, as the same page notes, professional developers also use these tools for repetitive tasks.

What Does a Low-Code Platform Include?

A low-code platform combines an app builder, workflow automation, connectors to business systems and admin tooling. Microsoft Power Platform, with Power Apps, Power Automate and Copilot Studio, is one example. When you compare platforms, look past the editor at the governance features: environments, data policies and support for the application lifecycle.

Is Low-Code the Same as No-Code?

AWS notes that low code is sometimes referred to as “low code or no code” and describes the phrase as a general label for tools that help business users design and build applications. In the author’s view, the practical difference is whether the platform expects you to add your own code when the ready-made pieces run out. From a governance point of view, both need the same rules.

How Do You Start Rolling Out Power Platform?

Start with goals and roles: who owns the platform, who administers it and who supports makers. Then protect the default environment with data policies, set up developer, test and production environments, and send the first production apps through a deployment pipeline. Microsoft walks through these steps in its Power Platform adoption guidance.

Request a quote

Develop Your Competencies

Check out our training and workshop offerings.

Request Training
Call us +48 22 487 84 90