BOLT — Foundation¶
BOLT formalises and scales what most mature Power Platform deployments have already built.
TL;DR
BOLT requires six foundation elements: platform accreditation, security pre-approvals, approved connector library, terms of use, ownership model, and active solution delivery. Most mature Power Platform deployments already have the majority of these in place — BOLT formalises and scales what is already working.
Applies To
Audience: CIO/CTO · Platform Lead · Enterprise evaluators BOLT Tiers: All — foundation supports all tiers Frameworks: BOLT
What the Foundation Is¶
The most common objection to a business-led delivery model is that it requires significant upfront investment before the first solution can be built. Platform accreditation takes months. Security pre-approvals require dedicated resource. Connector libraries need assessment and governance.
This objection is valid — for organisations starting from scratch. For organisations that have already invested in enterprise Power Platform, the foundation is often largely in place. BOLT formalises and scales what is already working, rather than building from nothing. The checklist below helps assess what is in place and what remains.
This section documents the foundation that BOLT requires — and confirms which elements are already operational. It is both a reference for organisations implementing BOLT and a readiness checklist for those assessing where they stand.
The Six Foundation Elements¶
1. Platform Accreditation¶
What it is: Platform accreditation is the enterprise security approval for the low-code platform itself — confirming that the platform's architecture, data handling, vendor compliance, and security controls meet the organisation's enterprise security requirements. It is the prerequisite for everything else in BOLT.
What accreditation enables: Once the platform is accredited, individual solutions built within the platform's approved boundaries do not require new platform-level security reviews. The accreditation covers the platform; the pre-approval model covers the solutions.
What accreditation covers: - The platform vendor's security architecture and compliance certifications (ISO 27001, SOC 2, etc.) - Data residency and sovereignty — where data is stored and processed - The platform's encryption model — data at rest and in transit - The platform's identity and access model — how authentication and authorisation work - The platform's DLP capability — how data movement is controlled - The platform's audit and logging capability — what is logged and for how long - The organisation's own security controls layered on top — DLP policies, Managed Environments, workspace strategy
Maintaining accreditation: Accreditation must be maintained — reviewed annually and whenever the platform changes significantly. The Platform Team is responsible for managing the accreditation renewal cycle in partnership with the security / compliance function.
2. Security Pre-Approvals¶
What they are: Security pre-approvals are formal approvals from the security / compliance function covering specific solution profiles — confirming that solutions within the approved boundaries can be built and deployed without individual security review.
What pre-approvals enable: Tier 1 and Tier 2 self-service. Without pre-approvals, every solution requires individual security review — recreating the bottleneck that BOLT is designed to eliminate.
Current pre-approval scope: - Solutions up to Internal Use classification (Tier 1 — default workspace) - Solutions up to Confidential classification in limited use cases (Tier 2 — dedicated business workspace) - Solutions using only the approved connector library - Solutions deployed within the approved workspace model
What remains outside pre-approval: - Solutions accessing Regulated or sensitive personal data above the approved boundary - Solutions requiring connectors not in the approved library - Solutions integrating with enterprise core systems beyond the approved connector scope - Tier 3 and Tier 4 solutions — individual assessment required regardless of classification
3. Approved Connector Library¶
What it is: The approved connector library is the published list of connectors that business teams can use in Tier 1 and Tier 2 solutions without requesting individual connector approval. Each connector in the library has been assessed and approved by the security / compliance function.
What approval covers for each connector: - Data residency — where the connector's data is processed and stored - Authentication model — how credentials are managed and what access is granted - Data classification compatibility — which classification levels are appropriate for this connector - Vendor security posture — whether the connector's provider meets enterprise security standards - DLP classification — how the connector is classified in the platform's DLP policy
Current library: A mature BOLT implementation typically maintains an approved connector library of 20–40+ enterprise connectors — providing business teams with meaningful integration capability across Microsoft 365 services, productivity tools, and core line-of-business systems within the approved classification boundary.
Requesting new connectors: New connector requests are submitted to the Platform Team. Assessment typically covers the same criteria as the initial library assessment. Approved connectors are added to the library and become available to all eligible teams immediately.
Library governance: The connector library requires ongoing governance: - Quarterly review — confirming existing connectors remain within approved parameters - Annual full assessment — re-evaluating the library against current security requirements - Ad hoc review — when a connector provider changes their security model, data handling, or terms
4. Terms of Use and Developer Guidelines¶
What they are: The terms of use define the acceptable use policies, data handling obligations, and developer responsibilities for everyone building on the BOLT platform. They are the documented agreement that citizen developers and power users enter into when they onboard to the platform.
What terms of use cover: - Acceptable use — what the platform is for, what it is not for - Data handling obligations — how data must be treated based on its classification - Developer responsibilities — ownership, maintenance, and decommissioning obligations - Compliance requirements — the regulatory and policy obligations that apply to solution development - Escalation obligations — when and how to escalate to the Platform Team or Line of Business IT - Consequences of non-compliance — what happens when the terms are violated
Developer guidelines: Alongside the formal terms of use, developer guidelines provide practical, actionable guidance for building within the BOLT model: - Which workspace to use for which type of solution - How to request a new connector - How to escalate a solution to a higher tier - How to document solution ownership - How to decommission a solution that is no longer needed
Publishing and accessibility: Terms of use and developer guidelines must be easy to find, easy to read, and kept current. Documents buried in SharePoint sites that nobody visits do not serve their purpose. The Platform Team should ensure these materials are surfaced at the point they are relevant — during onboarding, in the workspace welcome content, and in the training programme.
5. Ownership Model¶
What it is: The ownership model defines who owns what at every level of the BOLT framework — from the platform itself to individual solutions. It eliminates the ownership ambiguity that is the primary cause of ungoverned citizen development.
What the ownership model defines: - Which roles own which tier of solutions (covered in full in the Roles & Accountability section) - How ownership is documented at solution creation - What happens when an owner leaves the organisation — the orphaned resource process - How ownership transitions when solutions move between tiers - The escalation path when ownership disputes arise
Ownership documentation at go-live: Every solution that goes live within BOLT has documented ownership before production deployment. This documentation feeds into the CoE Starter Kit's solution inventory — providing the visibility that compliance reviews, audits, and operational oversight require.
6. Active Solution Delivery¶
What it means: BOLT is designed to be proven through production delivery. The operating model is validated when real solutions have been built and delivered across multiple business teams — tested against real business requirements, real delivery challenges, and real compliance constraints.
What active delivery demonstrates: - The guardrails work — solutions are being built correctly within the approved boundaries - The roles work — business teams are owning and maintaining solutions effectively - The pre-approval model works — business teams are delivering without waiting for individual security reviews - The platform is capable — the connector library and platform features are meeting real business needs
The value of the delivery track record: For organisations making the case for BOLT to leadership, the delivery track record is the most powerful argument. Abstract operating model descriptions are less convincing than concrete examples: this team built this solution in this timeframe, and here is the business outcome it delivered.
Power Platform Capability Status¶
The following capabilities are operational in the current Power Platform implementation of BOLT:
| Capability | Description | Status |
|---|---|---|
| Power Apps — Canvas Apps | Flexible app development for Tier 1–3 business solutions | Operational |
| Power Apps — Model-Driven Apps | Data-centric apps for structured business processes | Operational |
| Power Automate — Cloud Flows | Process automation and integration for all tiers | Operational |
| Copilot Studio | AI agent development for intelligent automation and conversational experiences | Operational |
| DLP Policies | Data Loss Prevention — connector usage controlled per workspace tier | Configured |
| Dataverse and Workspace Strategy | Workspace structure defined — Development, Test, and Production environments established | Operational |
| CoE Starter Kit | Platform visibility, telemetry, and usage monitoring across the tenant | Deployed |
| AI and Copilot Features | AI capabilities enabled within approved classification boundaries | Operational |
| Training and Learning Paths | Structured learning paths for citizen developers, power users, and fusion team members | Published |
| Approved Connector Library | 30+ enterprise connectors assessed and approved | Active |
| Terms of Use and Guidelines | Acceptable use policies and developer guidelines documented | Published |
| Ownership Model | Four-tier RACI model defined, documented, and communicated | Active |
The Path to Scale¶
Once BOLT is established, the path forward is scale — extending the model to more business teams, more use cases, and potentially more platforms.
Near-term priorities:
Formalise BOLT as the enterprise operating model: Ensure that BOLT is recognised organisation-wide as the governance framework for low-code delivery — not just within the teams that are already using it. This requires executive sponsorship, formal communication to business leaders, and integration with IT governance processes.
Align all delivery roles on their BOLT responsibilities: Line of Business IT teams, business teams, and the security / compliance function all need to understand their role within the model — particularly the escalation criteria between tiers and the pre-approval boundary. Role clarity reduces friction at tier transitions.
Scale enablement: The training programme, the connector library, and the support model are the supply side of BOLT. Demand will grow as business teams discover what is possible. Ensuring the enablement infrastructure can keep pace with demand — without the Platform Team becoming a bottleneck — is the primary scaling challenge.
Measure and report: BOLT's value is demonstrated through metrics: solutions delivered, time from idea to go-live, reduction in IT backlog, business outcomes achieved. Establishing a regular reporting cadence — for the Platform Team, for leadership, and for the security / compliance function — creates the visibility that sustains organisational confidence in the model.
Extend to new capabilities: Power Platform continues to evolve. New AI capabilities, new connectors, new platform features — each represents an opportunity to expand what BOLT can deliver. The Platform Team's capability assessment and pre-approval process is the mechanism for bringing new capabilities into the model safely.
BOLT Readiness Assessment¶
For organisations assessing their readiness to implement BOLT, the following checklist identifies the foundation elements required:
Platform Foundation - [ ] Low-code platform identified — Power Platform or equivalent enterprise low-code platform - [ ] Platform accreditation obtained or in progress — enterprise security approval for the platform itself - [ ] Workspace strategy defined — default, business, and solution workspace tiers established - [ ] DLP policies configured — per workspace tier with appropriate connector restrictions
Security Pre-Approvals - [ ] Classification boundary defined for Tier 1 and Tier 2 pre-approval - [ ] Security / compliance function engaged on pre-approval model — formal approval obtained or in progress - [ ] Pre-approval scope documented — what is covered, what is not, what triggers individual review - [ ] Pre-approval renewal cycle defined
Connector Library - [ ] Connector assessment process defined — criteria for approval documented - [ ] Initial connector library assessed and published — minimum viable library for Tier 1 and Tier 2 use cases - [ ] Request process defined — how business teams request new connectors - [ ] Library governance cycle established — quarterly review and annual full assessment
Governance Documentation - [ ] Terms of use drafted and published - [ ] Developer guidelines drafted and published - [ ] Tier criteria documented — objective criteria for each tier assignment - [ ] Escalation process documented — how solutions move between tiers
Roles and Ownership - [ ] Six BOLT roles identified and named — specific individuals or teams assigned to each role - [ ] RACI communicated to all relevant parties - [ ] Ownership documentation process defined — how solution ownership is captured at go-live - [ ] Orphaned resource process defined — what happens when owners leave
Enablement - [ ] Citizen developer training path designed and published - [ ] Power user training path designed and published - [ ] Support routing defined — Tech Solution Team scope and Platform Team escalation criteria - [ ] Community channel established — Teams or SharePoint for maker community
Part of the BOLT Framework — powerplatform.wiki Last updated: March 2026 Last reviewed: March 2026