Reusing Microsoft products in UK government, from repeated build to shared public value

Government organisations continue to pay to solve the same Microsoft platform problems. A council builds a desk-booking app. An NHS trust automates a clinical administration process. A department develops a Power BI template, a SharePoint site, a Power Automate flow, a Dynamics-style casework tool or a Copilot agent. Elsewhere in the public sector, another team faces the same requirement and starts again from a blank page.

This is wasteful. It duplicates discovery, procurement, build effort, assurance activity and, often, mistakes. It also hides successes. When one public body has already proven a Microsoft pattern, another can learn from that experience rather than rediscovering it through trial and error. Reuse gives government a practical way to reduce waste, protect public money and make better-informed decisions using evidence that has already been generated.

Microsoft reuse creates a significant opportunity for UK government, turning scattered public sector ingenuity into shared public value. A model that genuinely works helps teams discover what already exists, understand which elements can be applied elsewhere, package those elements effectively, and start from a stronger position than zero. Done well, it can shorten discovery, de-risk delivery, reduce duplicated spending, improve quality, and help smaller teams benefit from work that has already been proven elsewhere.

Reuse is already happening, it just needs to get more systematic

The strongest evidence sits in health. The NHSmail Solution Store is a working example of a shared repository for Power Platform solutions. It lets users on the central NHS tenant upload and download Power Apps and Power Automate flows for common digital health problems, including annual leave calculators, desk booking apps, document management tools and vaccination booking apps. The supporting guidance explains prerequisites, licensing, tenant constraints and support boundaries. That’s what makes the reuse proposition properly operational and practical. 

There are promising examples beyond health too. The GOV Reuse Library gives government a broader model for helping teams find reusable components, patterns, guidance and tools. The xGov low code community has created a shared GitHub repository to encourage collaboration and reuse. Local government has examples like BCP Council’s Power Apps work and Colchester’s Task Smart app. Scotland’s Digital Office has built national communities around Microsoft 365 and Power Platform capability. 

The GOV Reuse Library is a useful case study in what this takes. Launched in September 2025, it’s run by a two person team and a small network of volunteer contributors from across government. Early signs suggest it’s already changing behaviour, with people report checking the library before starting a piece of work, instead of assuming they’re starting from scratch. Its current content stays deliberately formal and design heavy, service standard manuals, guidance and design systems, because that’s what a small team can currently vouch for. The ambition is broader, including more informal assets, like the Miro boards teams already use to run retros, and eventually more technical assets once organisations feel more comfortable sharing their build and the site has a way to validate what it hosts instead of simply publishing whatever gets submitted. 

The Re-Use library example also shows that even a well designed catalogue struggles to get discovered. Most of the Library’s traffic still comes from active outreach, presentations and word of mouth, rather than people finding it organically, and awareness stays patchy even inside the department that hosts it. As content grows beyond a single long page, the team is now working on the site’s information architecture so it can handle the volume of contributions coming in. They’re also moving past simple click counts, testing lightweight prompts that ask returning users whether they actually used what they found, because clicking a resource and using it are genuinely different things, and a team funded on a shoestring needs solid evidence of impact to make the case for investment. 

The lesson is encouraging. Reuse happens where the right conditions exist: a visible catalogue, a packaged asset, clear installation guidance, an active community, explicit ownership and enough evidence to give adopters confidence. Government can make those conditions the norm, moving reuse from occasional success story to routine delivery practice. 

Start with the problem and process

The starting point should be someone with a need they understand well enough to describe, including the user problem, the process affected, the pain point and the outcome they want to improve. From there, the natural question should be whether anyone else in government has encountered the same challenge before. A reuse model only creates value if that person knows they can find the answer, see who has solved something similar, understand what they learned, and judge whether the pattern, component or solution is worth adapting.

That’s harder than it sounds because visibility itself is scarce. People working within a single department often struggle to know everything happening even within their own organisation, let alone across government. Anyone who’s moved between departments, or between government and industry, tends to notice this gap first. Freed from a single organisational vantage point, they can see the same problem being solved several times over in different places. A shared reuse exchange needs to recreate that cross-pollinating perspective deliberately, rather than leaving it to chance career moves.

The most valuable reuse is often not the whole application. Complete application reuse can work where the problem is genuinely standard, but many government services differ too much in policy, process, data, security and operating model for a simple copy-and-paste approach to succeed. In those cases, the real value lies in the proven pattern and the artefacts that surround it: the architecture, data model, user journey, accessibility approach, security assumptions, backlog, design documentation, testing approach, deployment pattern and lessons learned from a real implementation.

These artefacts travel well because they do not assume every organisation is the same. They give the next team a tested starting point while leaving room for differences in policy, process, data, security and operating model. That helps teams avoid known mistakes, reuse decisions that have already been proven, challenge unnecessary complexity, and make faster decisions based on better evidence. Where this reduces repeated discovery, design and build effort, it also helps protect public money.

A portfolio of reuse 

We want to build a Microsoft reuse library for government, giving teams a curated place to find proven patterns, components, starter solutions and deployable assets. Its purpose would be to help them see what already exists, understand whether it fits their needs, and reuse it safely.

The library would need to organise assets according to the level of support they provide, ranging from something a team can learn from to something they can deploy.

First, proven patterns: the architecture, service pattern, accessibility approach, security model and implementation lessons behind a real Microsoft delivery. These are highly portable and often the easiest place to start.

Second, reusable building blocks and configurable patterns: Power Platform components, PCF controls, Power Automate flows, custom connectors, Power BI visuals, Dataverse schema fragments, Copilot Studio topics, prompt libraries, deployment scripts and test harnesses. These save significant build and testing effort because they solve bounded problems and have a clearer dependency footprint.

Third, starter solutions. This may be the sweet spot for government. A correspondence management starter solution, for example, could provide the core Dataverse model, queue pattern, SLA logic, audit approach, accessibility components and deployment pipeline. The adopting department would still add its own categories, permissions, integrations, policy rules and reporting requirements. It would gain a substantial head start and avoid a significant amount of repeatable work.

Fourth, deployable solutions. These work where the problem is genuinely standardised: desk booking, asset requests, basic approvals, internal events, action tracking, onboarding, simple reporting packs or repeatable back-office workflows. They become much harder to apply to complex frontline services that incorporate local legislation, operating models, data definitions, integrations, accessibility requirements, risk appetites and accountability arrangements.

Partial reuse can still be valuable even when the entire solution cannot be reused. If an adopting team can reuse the baseline configuration, design documentation, backlog structure, training materials and deployment approach, it is already materially ahead of starting from a blank page. A solution can be worth reusing even when only part of it travels.

Why Microsoft reuse is technically possible 

The Microsoft stack already includes the mechanisms needed to make reuse possible, although they require careful design to work across organisations. Power Platform solutions can package apps, flows, Dataverse components and related assets so that they can be exported from one environment and imported into another. Managed solutions support controlled distribution, while unmanaged solutions allow greater local adaptation. Environment variables and connection references then handle the elements that need to change locally, such as URLs, keys, list names and authenticated connections, rather than carrying those details across from the originating tenant.

That is why cross-government reuse needs to be designed in from the outset. A reusable Power App should avoid hard-coded SharePoint URLs, personal connections and hidden dependencies on a maker’s account, because those choices make it difficult for another organisation to import and run the solution safely. The same principle applies to Copilot agents and Power BI patterns. The agent needs to be clear about the knowledge sources, permissions and channels it expects, while the report needs to explain its data model, refresh schedule and access model.

That portability still requires disciplined engineering. Source control, GitHub, Azure DevOps, Power Platform pipelines and deployment settings files can help keep reusable assets versioned, testable and easier to update. They also give the originating team a way to publish fixes and improvements without leaving adopters dependent on a one-off export. Without that lifecycle discipline, a technically shareable asset can quickly become outdated, difficult to support and unsafe to adopt.

What needs to be in place for reuse to work? 

Technical portability is only the first step. For reuse to work in practice, the adopting organisation needs sufficient confidence to assess the asset before importing it, adapt it safely afterwards, and operate it responsibly within its own tenant.

The first condition is security transparency. Each organisation has its own tenant, identity model, Data Loss Prevention (DLP) policies, security groups, roles and administrative controls. An adopter therefore needs to understand an asset’s connector requirements, permissions, data assumptions and expected DLP posture before deciding whether to proceed.

The second condition is licensing clarity. Many useful assets operate within standard Microsoft 365 licences, which is one of the reasons reuse is so attractive. Where an asset requires premium connectors, Dataverse capacity, AI Builder credits, Power Pages, unattended automation or broader Power BI sharing, the adopting organisation needs to know this upfront. Freely shared assets can still carry implementation, support, hosting, licensing and consumption costs.

The third condition is reusable assurance evidence. Security assessments, DPIAs, accessibility statements, clinical safety cases and operational risk reviews rarely transfer wholesale because accountability remains local. However, they can still save considerable time by providing adopters with a tested starting point, known risks, mitigation examples and language that can be adapted for local approval processes.

The fourth condition is a clear boundary between the reusable core and local configuration. Public bodies have different delegations, processes, data models and integrations. Successful reuse acknowledges that reality by making it clear what can travel unchanged, what must be configured locally, and where local accountability begins.

What government needs next 

This would be particularly valuable for organisations facing familiar operational challenges with limited budgets, time or delivery capacity. Regulators, arm’s-length bodies, agencies, local authorities, smaller public bodies and teams within larger departments often need a faster, safer way to move forward without commissioning another bespoke solution.

The next step should be a connected route to reusable Microsoft assets, with sufficient governance to make adoption safe and a strong enough community around it to make adoption a reality. Local teams would remain accountable for their own tenants and services while gaining greater visibility of useful work already undertaken elsewhere.

The register should connect formal catalogues with the places Microsoft practitioners already collaborate, including Teams-based maker networks, departmental communities, supplier networks and practitioner forums. A single shared route would also help teams avoid creating separate registers, standards and playbooks in parallel.

Every entry should provide adopters with enough information to make an informed decision. It should explain what problem the asset solves, who has used it, which Microsoft products and licences it requires, what must be configured locally, what assurance evidence exists, who maintains it, and what benefits adopters have actually achieved.

Effective curation should drive confidence. Rather than publishing every app, flow or accelerator ever built, the register should help adopters assess whether an asset is current, secure, accessible, maintained and worth the effort of adoption. Success should be measured through real-world use, the extent of local change required, effort saved and value delivered, alongside the number of assets listed.

The GOV Reuse Library gives government a starting point for discovery. The NHSmail Solution Store demonstrates how executable Microsoft assets can be shared when paired with operational guidance. Microsoft’s ALM tooling provides the packaging mechanisms. Together, these strengths can support a governed route from ‘that sounds useful’ to ‘we can safely adopt this’.

Bringing it all together 

Reusing Microsoft products across UK government presents a significant opportunity when approached deliberately. Effective reuse creates the conditions for work to travel at the right level, whether as a pattern, component, starter solution, installation pack, assurance artefact or complete application.

The prize is simple: build once where problems are genuinely common, be transparent about what can travel and what must be adapted locally, and help the next team move faster with greater confidence. With local Centres of Excellence, a shared Microsoft reuse register, robust packaging standards, active communities and clear stewardship, reuse can become practical public sector infrastructure rather than a hopeful side project.

Power Platform is the natural place to start because the need is visible, the packaging mechanisms already exist, and many public bodies already have makers solving similar problems. However, the ambition can extend far beyond Power Apps and Power Automate. The aim should be to create a one-stop shop for reusable assets, collateral and patterns across the Microsoft stack, including Dynamics and Dataverse patterns, Copilot prompts and agents, Power BI models, Azure reference architectures, governance packs, assurance evidence, delivery playbooks, Miro boards, process maps, backlog structures, training materials and implementation lessons.

Starting with Power Platform would give government a practical foundation on which to build towards a broader goal: helping every team find the reusable asset that provides the strongest possible head start, whether that is deployable technology, a proven design artefact or the delivery collateral that helps avoid solving the same problem repeatedly.

We will also be taking this conversation to the Government Transformation Summit in Manchester this November. If you are exploring similar questions, we would be delighted to speak with you beforehand or meet you there. We would welcome the opportunity to discuss where Microsoft reuse could create real value, what might prevent teams from adopting assets built elsewhere, and what sort of shared model would give organisations the confidence to start from proven work rather than a blank page.