BOLT — Guardrails & Trusted Enablement¶
Guardrails are not obstacles to speed. They are the condition that makes speed safe and sustainable.
TL;DR
Five guardrails make citizen development safe: dedicated workspaces, pre-approved connector library, data classification boundaries, Platform Team monitoring, and platform-native-only development at Tier 1–2. Security pre-approvals cover the risk profile — no per-solution review needed for Tier 1 and Tier 2.
Applies To
Audience: Platform Lead · CoE Lead · Security / Compliance Function BOLT Tiers: Tier 1 · Tier 2 (primary), Tier 3–4 (ALM references) Frameworks: BOLT · SHIELD (pre-approval model)
BOLT Guardrails and SHIELD
BOLT Guardrails define the operating boundaries for citizen development — what business teams can build and how. SHIELD defines the security controls those boundaries are built on. BOLT's pre-approval model depends on SHIELD's Enforce and Inspect pillars maintaining those controls.
What Guardrails Are in BOLT¶
The Trusted Enablement (T) pillar is where BOLT's governance lives. Guardrails are the set of controls, boundaries, and structures that allow business teams to build rapidly and autonomously — because the risk has been managed at the platform level, not at the solution level.
Well-designed guardrails are invisible to builders working within them. They only become visible when a builder approaches or crosses a boundary — at which point they serve their purpose, signalling that escalation or additional process is required.
Poorly designed guardrails are visible to everyone, all the time — creating friction, slowing delivery, and incentivising workarounds. The goal of BOLT guardrail design is the former, not the latter.
The Five Citizen Development Guardrails¶
These five guardrails form the core of the Tier 1 and Tier 2 trusted enablement model. Together they define the safe operating space within which business teams can build without individual IT review.
Guardrail 1 — Dedicated Workspaces¶
Each business team is provisioned a dedicated Power Platform workspace upon onboarding to Tier 2. Personal productivity (Tier 1) uses the default workspace. Neither tier has access to production enterprise systems directly.
What workspaces provide: - Isolation — business-led solution development is isolated from enterprise production systems. A mistake in a Tier 2 workspace cannot directly affect a Tier 4 production environment. - Classification boundary enforcement — workspace configuration ensures that the data classification boundary for the tier is enforced at the environment level, not just by policy - Ownership clarity — a dedicated workspace has a named owner (the business team lead) whose accountability is clear - Promotion path — solutions that grow from Tier 2 toward Tier 3 have a defined path to a more controlled environment, rather than being rebuilt from scratch
Workspace types:
| Workspace Type | Tier | Purpose |
|---|---|---|
| Default productivity workspace | Tier 1 | Shared personal productivity space — no dedicated provisioning required |
| Business workspace — Development | Tier 2 | Business team's build and test environment |
| Solution workspace — Dev/Test/Production | Tier 3–4 | Full environment promotion path with pipeline governance |
What workspaces do not do: Workspaces isolate environments but do not replace security controls. A workspace does not automatically prevent a connector from accessing data it is configured to access — DLP policies and security roles do that. Workspaces provide structural isolation; the other guardrails provide data and access control.
Guardrail 2 — Pre-Approved Connector Library¶
Citizen developers and business teams can only use connectors from the approved library. No connector outside the approved library can be used in a Tier 1 or Tier 2 solution without going through the connector approval process.
What the connector library provides: - Speed without risk — business teams do not need to wait for connector approval before building. The library is pre-approved; use is immediate. - DLP enforcement — DLP policies ensure that only approved connectors are available in each workspace tier. Unapproved connectors are blocked at the platform level, not by individual review. - Clarity — business teams know exactly which connectors they can use before they begin building
Connector library structure:
| Library Tier | Available To | Examples |
|---|---|---|
| Productivity connectors | Tier 1 — default workspace | Microsoft 365, SharePoint, Teams, Outlook, OneDrive, Planner |
| Business connectors | Tier 2 — dedicated workspace | All productivity connectors + approved enterprise connectors (CRM read, HR read, approved line-of-business systems) |
| Extended connectors | Tier 3+ only — case by case | High-sensitivity or write-enabled enterprise system connectors, assessed per solution |
Requesting a new connector: When a business team needs a connector not in the approved library, they submit a connector approval request through the Platform Team. The Platform Team assesses the connector against the security / compliance function's approval criteria — typically covering data residency, authentication method, data classification compatibility, and vendor security posture. Approved connectors are added to the library for all eligible teams; rejected connectors are documented with rationale.
Guardrail 3 — Data Classification Boundary¶
The data classification boundary defines the highest sensitivity level of data that solutions in each tier can access, process, or store. It is enforced through workspace configuration, DLP policies, and connector library design.
Classification tiers and BOLT tier mapping:
| Data Classification | Tier 1 Permitted | Tier 2 Permitted | Tier 3 Permitted | Tier 4 Permitted |
|---|---|---|---|---|
| Public | Yes | Yes | Yes | Yes |
| Internal Use | Yes | Yes | Yes | Yes |
| Confidential | No | Yes (limited use cases, pre-approved) | Yes | Yes |
| Regulated / Sensitive | No | No | Yes (with mandatory security sign-off) | Yes (with mandatory security sign-off throughout) |
How the classification boundary is enforced: - Tier 1 workspaces are configured to prevent access to systems above Internal Use classification - Tier 2 workspaces are configured for the Confidential boundary — connectors providing access to higher-classification systems are not in the Tier 2 connector library - When a business team identifies that their solution needs to access data above their tier's boundary, this triggers escalation — not workaround
The pre-approval model: The platform-level security pre-approvals that make Tier 1 and Tier 2 self-service possible are tied to the data classification boundary. The pre-approval covers solutions operating within the defined classification boundary. Solutions that access data above the boundary are outside the pre-approval scope and require individual security review — which is why they belong in Tier 3 or above.
Guardrail 4 — Platform Team as Safety Net¶
The Platform Team monitors the platform continuously using CoE Starter Kit telemetry, usage analytics, and DLP violation alerts. It acts as the safety net — identifying issues that the other guardrails did not catch before they become incidents.
What the Platform Team monitors: - New solutions created — particularly those approaching tier boundary criteria - Connector usage patterns — unusual connector combinations or high-volume data access - DLP policy violations or attempts — connectors blocked by policy, indicating a business team may need guidance or escalation - Workspace growth — environments approaching capacity or accumulating ungoverned solutions - Solutions without documented owners — orphaned resources flagged for remediation - Data classification anomalies — solutions accessing data above their workspace boundary
The intervention model: The Platform Team's monitoring is not a surveillance programme — it is an early warning system. When the telemetry surfaces a signal, the first response is guidance, not enforcement. A business team using a connector in an unexpected way is more likely to need guidance than a compliance sanction. The Platform Team's goal is to keep business teams building correctly, not to catch them building incorrectly.
Guardrail 5 — Platform-Native Only at Tier 1 and Tier 2¶
Tier 1 is strictly no-code. Tier 2 is low-code — using Power Platform's built-in capabilities (Power Fx formulas, flow expressions, Dataverse business rules and security roles) without custom connectors built from scratch, injected JavaScript, or external code libraries. "Platform-native" means using what the platform provides natively, not bringing code from outside it.
Why this guardrail exists: External code introduces complexity that escapes the platform's native governance surface. A canvas app that calls a custom API introduces a data flow that DLP policies cannot evaluate. A flow that executes arbitrary JavaScript introduces security risk that the platform's security model was not designed to address.
The platform-native guardrail at Tier 1 and Tier 2 ensures that the platform's native security controls — DLP policies, workspace isolation, data classification enforcement — remain effective. Solutions that genuinely require external code, custom connectors, or pro-code components belong in Tier 3, where Line of Business IT can apply the appropriate architecture and security review.
What falls outside platform-native for this purpose: - Custom connectors built by the business team - PCF (Power Apps Component Framework) controls embedded in solutions - JavaScript injected into canvas apps or model-driven apps - Azure Functions or external APIs called via HTTP connector without IT review
Security Pre-Approvals — The Foundation of Self-Service¶
The pre-approval model is what makes Tier 1 and Tier 2 self-service possible at enterprise scale. Without pre-approvals, every solution would require individual security review — recreating the bottleneck that BOLT is designed to eliminate.
What Pre-Approval Covers¶
The security / compliance function's platform-level pre-approval covers:
- The platform itself — Power Platform is accredited as an enterprise platform. Its security architecture, data handling, and vendor compliance have been assessed and approved. Building on the platform does not require a new platform assessment for each solution.
- The approved connector library — each connector in the approved library has been assessed for data residency, authentication, data classification compatibility, and vendor security. Using an approved connector does not require a new connector assessment.
- The Tier 1 and Tier 2 data classification boundary — solutions that stay within the approved classification boundary (Internal Use for Tier 1, Confidential limited use cases for Tier 2) are pre-approved. No individual solution security review is required.
- The workspace configuration — the structural isolation provided by the workspace model has been assessed and approved as appropriate for the risk profile of each tier.
What Pre-Approval Does Not Cover¶
- Solutions accessing data above the pre-approved classification boundary
- Custom connectors not in the approved library
- Integrations with enterprise core systems not in the approved connector library
- Solutions with unusual architectures or data flows not assessed as part of the platform pre-approval
- Any solution that a reasonable security professional would assess as presenting a risk profile above what the platform-level pre-approval assumed
Maintaining the Pre-Approval¶
Pre-approvals are not permanent. They must be reviewed: - Annually — to confirm the platform, connector library, and classification boundaries remain appropriate - When the platform changes significantly — new capabilities, new data processing, changes to Microsoft's security model - When the regulatory environment changes — new compliance requirements that affect the pre-approved boundary - When significant incidents occur — incidents that reveal risks not anticipated in the original pre-approval
The Platform Team is responsible for managing the pre-approval renewal cycle in partnership with the security / compliance function.
The Workspace and ALM Strategy¶
Tier 1 — Default Workspace¶
The default workspace is a shared productivity environment. All licensed users have access. It is not intended for solutions with shared users beyond the immediate team, for solutions handling Confidential data, or for solutions that integrate with enterprise systems.
The Platform Team applies a restrictive DLP policy to the default workspace — blocking premium connectors and all connectors not in the productivity tier of the approved library.
Tier 2 — Dedicated Business Workspace¶
Each business team onboarded to Tier 2 receives a dedicated workspace provisioned by the Platform Team. This workspace: - Has the business tier DLP policy applied — providing access to the full approved connector library at the appropriate classification level - Is named and documented with the business team owner - Is monitored by the Platform Team via CoE telemetry - Does not have a full Dev/Test/Production environment promotion path — Tier 2 solutions are built and deployed within the business workspace
When a Tier 2 solution grows toward Tier 3 complexity, the workspace transition is part of the escalation process — the solution moves to a dedicated Tier 3 solution workspace with full environment promotion.
Tier 3 and Tier 4 — Solution Workspaces¶
Tier 3 and Tier 4 solutions use dedicated solution workspaces with a full environment promotion path: - Development — where building and initial testing occurs - Test / UAT — where user acceptance testing occurs in a production-equivalent configuration - Production — where live users access the solution, with Managed Environments enabled
Solution promotion follows the ALM pipeline — Power Platform Pipelines or Azure DevOps, with Solution Checker enforcement, UAT sign-off, and security / compliance function approval gates before production deployment. This is the full DIALOGE Go-Live discipline applied to the most complex BOLT solutions.
Enablement — Making Guardrails Work¶
Guardrails without enablement are bureaucracy. Business teams that do not understand the guardrails cannot work within them effectively — they either stop building (losing the B and O value) or build around them (creating shadow IT).
Training Paths¶
Citizen Developer Path (Tier 1): - Platform orientation — what is Power Platform, what is available, what is the default workspace - BOLT principles — what the model is, who the roles are, when to escalate - Data classification — what can and cannot be built in the default workspace - Productivity connector basics — SharePoint, Teams, Power Automate fundamentals - When to call for help — routing to the Tech Solution Team and Platform Team
Power User Path (Tier 2): - All Citizen Developer content plus: - Low-code development fundamentals — canvas apps, cloud flows, Dataverse basics - Approved connector library — what is available, how to use it, how to request new connectors - Data modelling basics — Dataverse tables, security roles, basic relationships - Solution design principles — DIALOGE as the architectural framework for building well - When to escalate to Tier 3 — the criteria and the process
Fusion Team Path (Tier 3): - All Power User content plus: - Enterprise ALM — solution packaging, environment promotion, pipeline deployment - Integration patterns — connecting to enterprise systems within the approved library - Security role design — row-level security, column-level security, business units - Working with Line of Business IT — the collaboration model, architecture review process - SHIELD Inspect — the security review gate for Tier 3 solutions
Community and Support¶
Beyond formal training, BOLT's enablement model includes: - A maker community — a Teams channel or SharePoint site where business teams share solutions, ask questions, and learn from each other - Office hours — regular Platform Team drop-in sessions for business teams with questions - Solution templates — pre-built starter solutions that demonstrate correct patterns for common use cases, reducing the distance between "starting from scratch" and "starting correctly" - Exception request process — a clear, fast process for requesting connector approvals, classification boundary exceptions, or DLP policy adjustments — with documented rationale and timelines
Common Guardrail Failures — and How to Prevent Them¶
Guardrails designed to be maximally restrictive: Guardrails calibrated to the worst-case risk scenario create so much friction that business teams route around them. Design guardrails to be as permissive as the actual risk profile allows — not as restrictive as theoretically possible.
Connector library not published or hard to find: Business teams that do not know what connectors are available cannot build with confidence. The approved connector library must be prominently published, easy to navigate, and kept current. If teams discover connectors are approved by trying them rather than by reading a list, the library is not doing its job.
Exception process too slow: A connector approval request that takes four weeks to process creates a guardrail that business teams treat as "wait four weeks or use a workaround." Exception processes must be responsive — within days for routine requests, not weeks.
Training treated as optional: Citizen developers who build without completing onboarding training create solutions outside the guardrails unintentionally — because they did not know the guardrails existed. Training completion should be a prerequisite for workspace provisioning, not a recommendation.
Pre-approvals never renewed: Pre-approvals that were granted two years ago and never reviewed may no longer cover the platform as it exists today. The renewal cycle must be managed actively — expiry should trigger review, not silent continuation.
Part of the BOLT Framework — powerplatform.wiki Last updated: March 2026 Last reviewed: March 2026