Scenario: Enable Citizen Development¶
Citizen development at scale is not a technology decision. It is a governance decision that technology enables.
TL;DR
Enabling citizen development safely follows a deliberate sequence: define the tier model and who qualifies as a maker (BOLT), pre-approve connectors and set DLP guardrails (SHIELD), provision maker workspaces (SCALE-OPS Containment), train and enable (SCALE-OPS Enablement), then give makers the solution patterns they need (DIALOGE Experience). Speed without this sequence produces shadow IT inside the governed platform.
Applies To
Audience: CoE Lead · Business Unit Lead · Platform Admin · CIO Situation: Enabling business teams to build on Power Platform safely and at scale Frameworks: BOLT · SHIELD · SCALE-OPS · DIALOGE
The Situation¶
The platform is available. Licences exist. Business teams want to build. The question is not whether to enable citizen development — it is how to do it in a way that is fast for makers, safe for the organisation, and sustainable as adoption grows.
Without a deliberate model, citizen development produces ungoverned solutions: apps connected to regulated data without security review, flows running under personal credentials that leave when people do, and solutions that cannot be supported because nobody documented what they do.
This scenario sets the sequence that avoids those outcomes.
The Sequence¶
Step 1 — Define the tier model and maker eligibility (BOLT)¶
Start by defining exactly what "citizen development" means in your organisation. BOLT's four-tier model provides the structure. Citizen developers operate primarily in Tier 1 (personal productivity) and Tier 2 (business-led solutions). The tier determines what they can build, what oversight applies, and when IT involvement is required.
Key decisions at this step:
- Which tiers will you open? (Tier 1 only, or Tier 1 and 2?)
- What qualifies someone as a recognised maker?
- What is the escalation path when a solution exceeds its tier?
- Who is the Fusion Team Lead for each business unit?
→ BOLT: Delivery Tiers · BOLT: Roles & Accountability
Step 2 — Pre-approve connectors and data guardrails (SHIELD: Harden + BOLT: Guardrails)¶
Before makers build, define what they can connect to. Pre-approved connectors remove the need for case-by-case security reviews — and mean makers don't get blocked waiting for approval.
Key decisions at this step:
- Which connectors are pre-approved for Tier 1 and Tier 2?
- What data classifications can citizen developers access?
- What DLP policies apply to maker workspaces?
Critical: Guardrails must be pre-approved, not retroactively applied. Approving connectors after solutions are already built creates a compliance backlog.
→ BOLT: Guardrails · SHIELD: Harden · DLP Policy Decision Guide
Step 3 — Provision maker workspaces (SCALE-OPS: Containment)¶
Makers need their own environments — separate from production and from each other. The SCALE-OPS Containment model defines how maker workspaces are structured, isolated, and managed.
Key decisions at this step:
- Do makers share a Maker sandbox or get individual environments?
- What is the environment lifecycle for maker workspaces?
- How are solutions promoted from maker workspace to business production?
→ SCALE-OPS: Containment · Environment Tier Decision Guide
Step 4 — Train and enable the maker community (SCALE-OPS: Enablement)¶
Governance without enablement produces compliance without adoption. Makers need to know the guardrails, understand the tools, and have a community to learn from.
Key decisions at this step:
- What is the minimum training requirement before a maker can build in Tier 2?
- Is there a maker certification or recognition programme?
- What is the office hours / community of practice structure?
Step 5 — Provide solution patterns (DIALOGE: Experience)¶
Give makers the building blocks to build well — approved UI patterns, component libraries, data models they can reuse, and canvas app templates. This is DIALOGE Experience: reducing the gap between what makers can imagine and what they can safely build.
→ DIALOGE: Experience · DIALOGE: Logic
Common Mistakes¶
| Mistake | Consequence | How to Avoid |
|---|---|---|
| Opening all connectors by default | Sensitive data exposed through unreviewed connections | Pre-approve a curated connector set; require review for others |
| No escalation path from Tier 1 to Tier 2 | Solutions grow beyond their tier without oversight | Define tier escalation criteria explicitly |
| Training without governance | Makers know how to build but not what they're allowed to build | Combine platform training with guardrails training |
| Maker workspace same as production | Test solutions affect live data and users | Always provision separate maker environments |