When organizations adopt Power Platform at scale, the first environment strategy question they ask is usually: how many environments do we need? The correct answer is almost never "just dev, test, and prod."

A well-designed ALM strategy for Power Platform in 2026 accounts for the full lifecycle of a solution — from developer sandbox to production deployment — and builds in the governance, security, and automation required to sustain it over time.

Why "dev-test-prod" is not enough

The classic three-environment model breaks down for several reasons:

• Developers need isolated sandboxes. Shared dev environments lead to conflicts, broken flows, and shared credentials. Every developer — or at minimum every stream of work — should have an isolated environment.
• Makers and citizen developers need a separate space. Power Platform's low-code promise means business users will build things. They need a managed environment that is governed but not blocked.
• Testing needs to be realistic. Your test environment should mirror production data structures, connection references, and environment variables — otherwise what you're testing is not what you're deploying.
• Production is not the finish line. Hotfix environments, DR environments, and training environments all have legitimate places in a mature ALM strategy.

The environment types you should plan for

Here is the environment inventory we recommend for most enterprise Power Platform tenants:

• Developer sandboxes — one per developer or work stream, provisioned on demand, automatically expired after 30 days of inactivity using Power Platform admin APIs.
• Managed maker environment — for approved citizen developers, governed by DLP policies, with Dataverse access scoped to non-production data only.
• Build / integration environment — used by your CI/CD pipeline to assemble and validate solutions before promotion. No humans work here directly.
• Test / UAT environment — mirrors production configuration. Connection references, environment variables, and security roles are all production-equivalent.
• Pre-production / staging — final gate before production. Used for load testing, security review, and stakeholder sign-off.
• Production — only deployments from the CI/CD pipeline are accepted. No manual imports.
• Hotfix environment — a production copy used for emergency patches. Changes flow back into the main branch before being re-deployed to production.

Solution segmentation strategy

One of the most impactful — and most overlooked — ALM decisions is how you segment your solutions. Putting everything in one solution creates a monolith that is slow to deploy, risky to change, and impossible to test in isolation.

The pattern we recommend is a three-layer solution architecture:

1. Core / shared solution — contains Dataverse tables, columns, relationships, security roles, and business rules that are shared across multiple apps. This solution is versioned independently and changes less frequently.
2. App solution(s) — contains the canvas or model-driven app, its components, and any flows or cloud connections that are specific to that application.
3. Configuration solution — contains environment variables, connection references, and any configuration entities. This is what changes between environments at deployment time.

Deploy-from-Git in 2026

Microsoft's deploy-from-Git capability, now generally available in 2026, allows solution source files to be stored directly in a GitHub or Azure DevOps repository and deployed using pipeline triggers. This changes the ALM workflow in a fundamental way:

• Developers unpack solutions to source control as part of their normal workflow using the Power Platform CLI (pac solution unpack).
• Pull requests trigger automated validation pipelines — solution checker, connection reference validation, and environment variable verification.
• Merges to the main branch trigger automated deployments through the environment chain.
• Every deployment is traceable to a commit, a PR, and an approver.

The Power Platform Pipelines feature vs. custom Azure DevOps pipelines

Microsoft's built-in Power Platform Pipelines feature (available from the CoE Starter Kit and now natively in Managed Environments) provides a low-code deployment mechanism that works well for smaller teams and simpler solution structures. For enterprise-grade deployments with complex approval workflows, automated testing, and multi-stage environments, a custom Azure DevOps or GitHub Actions pipeline gives you the flexibility you need.

Our recommendation: use Power Platform Pipelines as the approval and deployment UI for non-technical stakeholders, backed by a custom pipeline that handles the actual packaging, validation, and deployment automation.

Getting started

If you are starting from scratch, the most important first steps are:

1. Define your environment inventory and naming convention before creating anything.
2. Implement DLP policies on every environment from day one — retrofitting them later is painful.
3. Set up your solution architecture with the three-layer pattern before writing your first app.
4. Configure connection references and environment variables in your first solution — this forces good habits early.
5. Automate environment provisioning using the Power Platform admin connectors so developer sandboxes are never manually created.

ALM is not glamorous work. But it is the difference between a Power Platform estate that scales reliably and one that becomes a governance nightmare. Done right, it frees your developers to move fast — because they know exactly where their changes are going and what happens when they get there.

If you have spent any time in the Power Platform community, you have heard the debate: Dataverse or SharePoint Lists? The honest answer is that both are legitimate choices — but for very different use cases, and the consequences of picking the wrong one are significant.

Here is the framework we use when advising clients on this decision.

Start with these four questions

1. Do you need row-level security? If different users need to see different rows of the same table based on their role or team, you need Dataverse. SharePoint Lists have item-level permissions, but they do not scale, they are painful to manage, and they break calculated columns and views when applied extensively.
2. Do you need relationships between tables? If your data has lookups, many-to-many relationships, or hierarchies, Dataverse's relational model is significantly better than SharePoint's column-based approach. SharePoint lookup columns work, but they do not enforce referential integrity and do not support complex relationships gracefully.
3. How many records will you have? SharePoint Lists have a hard 30-million item limit and a practical performance threshold around 5,000 items without careful indexing. Dataverse handles tens of millions of records with consistent performance.
4. Do you need offline access or mobile performance? Dataverse supports offline-first scenarios natively in model-driven apps. SharePoint does not.

When SharePoint Lists are the right answer

SharePoint Lists are genuinely excellent for a set of use cases that gets overlooked in the rush to recommend Dataverse for everything:

• Document-centric workflows. If your data is primarily about documents — approvals, reviews, metadata tagging — SharePoint is the right foundation. Dataverse has file attachment support, but it is not a document management system.
• Simple reference data with M365 integration. A department holiday calendar, a list of approved vendors, or a contacts directory that needs to surface in Teams — these are SharePoint List use cases, not Dataverse use cases.
• Rapid prototyping and light apps. If you are building a simple tracking app for a small team with no licensing budget beyond Microsoft 365, SharePoint Lists with Power Apps gives you a working solution without needing Dataverse premium licensing.
• Content that needs to be indexed by SharePoint Search. Dataverse data is not surfaced by SharePoint Search or Microsoft Search out of the box. If discoverability in the Microsoft 365 ecosystem matters, SharePoint is the right choice.

When Dataverse is the right answer

Dataverse earns its premium licensing cost in the following scenarios:

• Any enterprise application with real business logic. Business rules, calculated columns, rollup columns, duplicate detection rules, and server-side synchronization are all native Dataverse capabilities with no SharePoint equivalent.
• Applications used by external users. Power Pages (external web portals) requires Dataverse. Full stop.
• Copilot Studio agent knowledge and memory. Dataverse for Agents is the designated store for agent knowledge sources, conversation history, and action results. If you are building AI agent solutions, you are building on Dataverse.
• Anything that needs a proper audit trail. Dataverse's native auditing capability tracks every field change, including who changed it and when. SharePoint version history is a poor substitute.
• Multi-app ecosystems. If more than one app needs to read and write the same data, centralizing it in Dataverse — with proper security roles — is significantly better than trying to coordinate access to a SharePoint List.

The licensing reality

The most common reason people choose SharePoint Lists over Dataverse is licensing cost. Dataverse requires a Power Apps per-user or per-app licence (or Dynamics 365 licensing for Dynamics tables). SharePoint is included in most Microsoft 365 plans.

Our recommendation: do not let licensing drive you to the wrong architecture. If your application genuinely needs Dataverse, build it on Dataverse — the cost of re-architecting later is always higher than the licensing cost you were trying to avoid. That said, if SharePoint genuinely fits your use case, do not over-engineer it.

The hybrid approach

It is worth noting that Dataverse and SharePoint are not mutually exclusive. Dataverse has native SharePoint document storage integration — you can store files associated with Dataverse records in a SharePoint document library, combining Dataverse's relational data model with SharePoint's document management and search capabilities. For many enterprise applications, this hybrid approach is the right answer.

Power Automate has matured significantly over the last few years. The flows that organizations are building today — connecting enterprise systems, orchestrating multi-step approvals, integrating with AI agents — are a long way from the simple email notifications that introduced most people to the platform.

Here are five patterns that come up in almost every serious enterprise automation engagement, and the considerations that matter when implementing them.

1. The compensation pattern for long-running workflows

Standard Power Automate flows are designed for short operations. When you build a long-running business process — a procurement workflow that might take weeks, an onboarding sequence that spans multiple systems — you need to think about what happens when something goes wrong halfway through.

The compensation pattern handles this by pairing each action with a compensating action that can undo its effects if a later step fails. In Power Automate, this is implemented using scope actions with parallel error-handling branches.

The implementation uses three nested scopes: a Try scope containing your business logic, a Catch scope that runs on failure and executes compensating actions in reverse order, and a Finally scope for cleanup that runs regardless of outcome.

2. The child flow pattern for reusable logic

As your Power Automate estate grows, you will find yourself rebuilding the same logic in multiple flows — address validation, currency formatting, error notification, or integration with a specific system. The child flow pattern solves this by extracting reusable logic into an independently maintained flow that can be called by multiple parent flows.

Child flows accept inputs (via the "Run a Child Flow" action's input schema) and return outputs, functioning as a service that other flows can consume. The key benefits are:

• A bug fix in one place propagates to all flows that use the child flow.
• The child flow can be tested independently.
• Complex logic is abstracted away from business process flows, keeping them readable.

The important constraint: child flows must be in the same environment as their parent flows. Plan your environment strategy with this in mind if you intend to share logic across solutions.

3. The circuit breaker pattern for external system integration

When Power Automate flows integrate with external systems — third-party APIs, legacy on-premises systems via data gateway, or external SaaS platforms — those systems will occasionally be unavailable. Without a circuit breaker, your flows will queue up retries, overwhelm the external system when it comes back online, and generate hundreds of failure notifications.

The circuit breaker pattern tracks failure counts using a Dataverse record or environment variable. When failures exceed a threshold, the circuit "opens" and the flow skips the external call, returning a graceful degraded response instead. After a cooldown period, the circuit "half-opens" to test whether the external system has recovered.

In Power Automate, this is implemented with a condition that checks a failure counter before attempting the external call, and a scheduled flow that resets the counter after the cooldown period.

4. The event sourcing pattern for audit-critical processes

Some business processes require a complete, immutable record of every state change — not just the current state. Financial transactions, regulatory submissions, healthcare workflows, and HR processes all fall into this category.

The event sourcing pattern records every meaningful event as an immutable record in a dedicated Dataverse table, rather than simply updating the current state. Each event record contains: the event type, the timestamp, the actor (user or system), the before and after values, and a correlation ID linking related events.

The advantages are significant: you can reconstruct the complete history of any record, you have a built-in audit trail that satisfies regulatory requirements, and you can replay events to debug issues or migrate data.

5. The saga pattern for distributed transactions

When a single business operation needs to update multiple systems — for example, creating a record in Dataverse, sending a message to an external API, updating a SharePoint List, and triggering a Teams notification — you have a distributed transaction. If any step fails, you need a coordinated rollback.

The saga pattern manages this by defining each step as a discrete transaction with a corresponding compensation transaction. The orchestrator (your Power Automate flow) executes steps in sequence. On failure, it executes compensation transactions in reverse order.

In Power Automate, the implementation uses:

• A Dataverse table to track saga state (which steps have completed successfully).
• Scope actions with configure run-after settings to implement the compensation sequence on failure.
• A separate compensation flow that can be triggered by the main flow or by a manual recovery process.

Putting it together

These five patterns are not academic — they appear in every serious enterprise automation project. The compensation pattern protects data integrity. Child flows protect your ability to maintain the estate. The circuit breaker protects your integrations. Event sourcing protects your audit trail. The saga pattern protects your distributed operations.

None of them are difficult to implement individually. The challenge is recognising which pattern applies to which problem, early enough in the design process to build it in from the start rather than retrofitting it when something breaks in production.

Microsoft's 2026 Release Wave 1 landed in April with the usual volume of updates across the full Power Platform and Microsoft 365 ecosystem. As always, the challenge is not finding the release notes — it is working out which changes actually matter for organizations building production solutions.

Here is our read on the updates that will have the most impact for Power Platform practitioners.

Copilot Studio: multi-agent orchestration is production-ready

The most significant shift in Wave 1 is that multi-agent orchestration in Copilot Studio has moved from preview to general availability. This is a meaningful milestone.

Multi-agent orchestration allows a master agent to delegate tasks to specialist sub-agents. A customer service agent can now hand off billing enquiries to a billing specialist agent, technical support cases to a technical agent, and escalations to a human handoff agent — all within a single conversation, with context preserved across the handoffs.

What has changed since preview:

• Agent-to-agent authentication is now handled natively via Managed Identity, eliminating the need for service accounts.
• Context passing between agents is now strongly typed — you define the schema of what one agent passes to another, which eliminates a class of runtime errors that plagued preview deployments.
• Orchestration audit logs now capture the full decision trail — which sub-agent was selected, why, and what it returned. This was the most-requested feature from enterprise preview customers.

Copilot Studio: AI Governance Agent

New in Wave 1 is the AI Governance Agent — an autonomous admin agent that monitors your Copilot Studio estate for policy violations, unusual consumption patterns, and misconfigured agents. It runs on a schedule, generates a report, and can be configured to automatically disable agents that breach defined thresholds.

For enterprise administrators managing a growing estate of agents across multiple environments, this addresses a real operational gap. Previously, governance relied on manual review of analytics reports. The AI Governance Agent shifts this to proactive monitoring.

Configuration is done through the Power Platform admin centre. Governance policies are defined as rules (for example: "alert if any agent is consuming more than 500 credits per day" or "disable any agent with a topic count below 3 that is receiving production traffic"). The agent checks these rules on a configurable schedule and posts its findings to a designated Teams channel or Dataverse table.

Copilot Studio: PAYG credit caps

Wave 1 introduces granular Pay-As-You-Go credit caps at the agent level. Previously, credit consumption could only be monitored at the environment level, which made it impossible to set per-agent budgets.

You can now set a daily credit cap on individual agents. When the cap is reached, the agent returns a graceful degraded response ("I'm currently unavailable — please try again later or contact support") rather than failing silently or continuing to consume credits. The cap resets at midnight UTC.

This is important for any organization running agents in production without unlimited budgets — which is most organizations.

Dataverse: deploy-from-Git is generally available

We covered this in our ALM article, but it deserves mention here as well. Dataverse's deploy-from-Git capability — which allows solution source files stored in GitHub or Azure DevOps to be deployed to Dataverse environments via pipeline triggers — is now generally available.

The GA release includes several improvements over the preview:

• Support for environment variable values stored as GitHub Secrets or Azure DevOps variable groups, eliminating the need to store credentials in pipeline variables.
• Native support for connection reference validation before deployment — the pipeline now checks that all connection references in the solution have valid connections in the target environment before proceeding.
• A deployment history view in the Power Platform admin centre that links each environment's current state to the commit that produced it.

Power Apps: generative pages

Generative pages — which allow Copilot to generate a canvas app page layout from a natural language description — have moved to general availability. In practice, this means describing what you need ("a form to capture patient intake information with fields for name, date of birth, GP name, and presenting complaint") and having Copilot generate a working page that you then refine.

The quality of generated pages has improved significantly since preview. They are still not production-ready without review and refinement, but they meaningfully accelerate initial app development for experienced developers who know what to look for and adjust.

Power Automate: agent-based flow authoring

The Copilot assistant in Power Automate has been upgraded in Wave 1 to what Microsoft calls "agent-based authoring." Rather than suggesting individual actions, Copilot now analyses your trigger and a natural language description of the desired outcome, generates a complete multi-step flow, explains its reasoning, and asks clarifying questions before finalizing.

The quality improvement over the previous Copilot is substantial. In our testing, agent-based authoring produces a first-draft flow that requires meaningful editing roughly 40% of the time — down from roughly 80% with the previous Copilot. The patterns it struggles with are still complex branching logic and non-standard connector configurations.

What does not make the list

Several Wave 1 features got significant marketing attention but are worth moderating expectations on:

• Power BI "natural language to report" in Fabric Copilot. Impressive in demos, inconsistent in practice. Useful for exploratory analysis, not yet reliable enough for production report generation.
• Autonomous agents for Microsoft 365. The M365 Copilot autonomous agent capabilities announced in Wave 1 are in preview and require the M365 Copilot licence at $30/user/month. For most of our clients, this is a watch-and-wait item for now.

Our recommendation

If you are building Copilot Studio solutions in production, the multi-agent orchestration GA and the PAYG credit cap features are both worth implementing now. If you are managing a growing Power Platform estate, the AI Governance Agent is worth configuring in the next sprint cycle. If you are building solutions using ALM pipelines, the deploy-from-Git GA is worth migrating to from whatever manual or custom pipeline approach you are currently using.

Note: client name and specific program details have been anonymized at the client's request.

The challenge

A provincial government agency was processing high volumes of citizen service requests through a combination of paper forms, email, and manual data entry into a legacy case management system. The process had three major problems:

1. High manual effort. Staff were spending 60–70% of their time on data entry and document management rather than on case assessment and citizen communication.
2. No real-time visibility. Case managers had no way to see the current status of requests across the team without asking individually or checking the legacy system, which was updated inconsistently.
3. Bilingual and accessibility gaps. The paper process was not meeting the agency's AODA and French-language service obligations consistently.

The approach

We proposed a Power Platform solution built on three components:

• A Power Pages portal for citizen-facing intake — bilingual, WCAG 2.1 AA compliant, with conditional logic that adapted the form to the citizen's situation.
• A Dataverse data model to store submissions, supporting documents, and case data — with row-level security ensuring case managers only saw their assigned files.
• A model-driven app for case managers — replacing the manual process with a structured workflow, automated task assignment, and real-time dashboard.

The 90-day target was aggressive but achievable with the right sequencing. We structured the project in three four-week sprints, with a go/no-go checkpoint at the end of each.

Sprint 1: foundation (weeks 1–4)

The first sprint focused entirely on the data model and security architecture. We spent more time here than clients typically expect, because a wrong decision at this stage is expensive to undo later.

Key deliverables:

• Dataverse schema with 14 tables, including full bilingual metadata labeling.
• Security role design with four roles: citizen applicant (portal), case worker, supervisor, and administrator.
• Environment strategy: dev, test, and production with managed solutions from day one.
• Connection references and environment variables configured for all three environments.

Sprint 2: intake portal (weeks 5–8)

Sprint 2 built the citizen-facing Power Pages portal. The intake form had 47 fields across 6 pages, with conditional branching that reduced the visible field count to 18–32 fields depending on the citizen's answers.

Key decisions made during this sprint:

• Authenticated vs. anonymous. We chose to allow anonymous intake submissions with an email-based reference number, rather than requiring citizens to create an account. This significantly reduced abandonment rates in user testing.
• Document upload. Supporting documents were uploaded directly to SharePoint via Power Pages, with metadata written to Dataverse. This avoided Dataverse file storage costs while keeping the document-record association intact.
• Bilingual implementation. Both French and English content was managed through Dataverse lookup tables rather than hardcoded in the portal — giving the agency's bilingual content team the ability to update copy without developer involvement.

Sprint 3: case management & dashboard (weeks 9–12)

The final sprint delivered the model-driven case management app and Power BI dashboard. By this sprint, case managers had been using a prototype of the data model for two weeks during testing, which meant their feedback on the app layout was specific and actionable rather than theoretical.

Results

The solution went live on day 87 — three days ahead of the 90-day target. In the first 60 days of operation:

• 68% reduction in time spent on data entry per case.
• 94% of portal submissions were fully complete on first attempt, compared to 61% of paper forms.
• 100% bilingual compliance from day one.
• Zero manual document filing — all documents are automatically associated with the correct case record in SharePoint.

What we would do differently

Two things we would adjust on a similar engagement:

1. Earlier Power BI work. We built the dashboard in sprint 3, which meant it was delivered at go-live without any real operational data to validate against. Starting the dashboard in sprint 2 with test data would have allowed more meaningful iteration before launch.
2. Training environment. We did not provision a dedicated training environment. Case managers trained on the test environment, which created confusion when test data was cleaned before go-live. A dedicated training environment — even a minimal one — is worth the cost on any solution that involves a significant change in how staff work.

Microsoft Fabric is now over two years into general availability, and the question has shifted from "what is it?" to "how do we justify migrating to it?" For many organizations, the answer is straightforward — but making that case to a leadership team that thinks in terms of business outcomes rather than technical architecture requires careful framing.

Start with the problem, not the technology

The worst way to open the Fabric migration conversation with your CFO or CIO is: "Microsoft has a new platform called Fabric and we should migrate our analytics stack to it." That framing puts you on the defensive immediately — you are asking for money and disruption to adopt something new.

The better framing is: "Our current data analytics setup has three problems that are costing us time and money. Fabric solves all three. Here's how."

The three problems that resonate with leadership in most organizations are:

1. Data duplication and pipeline complexity. Most organizations have data sitting in multiple places — Azure Data Lake, a Synapse workspace, Power BI datasets, and a warehouse — with pipelines copying data between them. Each copy is a maintenance cost, a latency risk, and a governance headache.
2. Fragmented tooling. Data engineers use different tools than data analysts, who use different tools than data scientists. Onboarding new people is slow, licensing is complex, and collaboration across disciplines is friction-heavy.
3. Slow time to insight. The cycle time from "we need a new report" to "the report is in production" is measured in weeks in most organizations. This slow cycle undermines the business's ability to respond to changing conditions.

The Fabric answer to each problem

Data duplication. Fabric's OneLake architecture means there is one copy of your data — stored in the open Delta Parquet format — that is accessed by all Fabric workloads. Your data engineering pipelines write to OneLake once. Your data warehouse, your notebooks, your Power BI reports, and your real-time intelligence all read from that same copy. No ETL between platforms. No data drift between systems.

Fragmented tooling. Fabric brings together Data Factory, Synapse Analytics, Data Engineering, Data Science, Real-Time Intelligence, and Power BI into a single SaaS workspace. A data engineer and a Power BI analyst can see the same data, in the same workspace, with the same governance policies applied. The learning curve for switching between these disciplines drops dramatically.

Slow time to insight. The combination of Copilot-assisted report creation (which generates a first-draft Power BI report from a natural language prompt and a semantic model), pre-built connectors to hundreds of data sources, and simplified data pipeline authoring means that the cycle from data to insight is measurably faster. In our client engagements, organizations moving from a traditional Azure analytics stack to Fabric typically report a 40–60% reduction in the time to create and publish a new report.

How to quantify the business case

Leadership needs numbers. Here is how we help clients build the financial case:

• License consolidation. If your organization has Power BI Premium, Azure Synapse, and Azure Data Factory, you may already be paying for much of what Fabric provides. A Fabric SKU analysis often reveals that consolidating to Fabric is cost-neutral or cost-positive at the license level.
• Engineering time saved. Count the hours your data engineering team spends on pipeline maintenance, data copy jobs, and cross-platform debugging. Multiply by fully-loaded cost. In most mid-market organizations, this is $200K–$600K per year. Fabric does not eliminate this work, but it typically reduces it by 30–50%.
• Business value of faster reporting. Estimate the value of a decision that could be made one week sooner. This is harder to quantify precisely, but even a conservative estimate tends to be significant for high-velocity decisions like pricing, inventory, or staffing.

Addressing the migration risk objection

The most common objection to a Fabric migration is risk: "We have existing pipelines, reports, and processes that work. Why break something that isn't broken?"

The answer is that a well-planned Fabric migration is incremental, not big-bang. You do not migrate everything at once. The typical approach is:

1. Stand up Fabric alongside your existing stack — not instead of it.
2. Migrate one workload (typically a non-critical analytical dataset or a new project rather than an existing pipeline) to Fabric first.
3. Build competency and confidence with Fabric on the low-risk workload.
4. Gradually migrate additional workloads, starting with new development and working backwards to legacy pipelines.
5. Decommission the legacy stack as workloads migrate — capturing the cost savings progressively.

This approach means you are never in a position where you have migrated half your analytics stack and can't go live with anything. Every migration milestone delivers value independently.

The conversation to have

In our experience, the most effective way to get leadership buy-in for a Fabric migration is a 30-minute working session with three things prepared: a one-page summary of the three problems and the Fabric answer to each, a rough financial model showing the cost case (even if conservative), and a proposed phased migration plan with a clear first milestone. The first milestone should be achievable in 6–8 weeks and should produce something visible — a new report, a migrated pipeline, a working Fabric workspace — that leadership can see and point to.

Once leadership can see Fabric delivering value on a real workload, the migration conversation shifts from a cost justification to a question of how fast to proceed.

Client name and specific product details have been anonymized at the client's request.

The challenge

A national financial services firm was experiencing client attrition during onboarding. Their new client process required 5–7 business days from application submission to account activation — a timeline driven by manual document review, compliance screening, and multi-step approvals across three departments.

Competitive analysis showed that two of their main competitors had reduced their onboarding cycle to same-day for standard applications. The firm's leadership had set a strategic objective: match the market-leading onboarding speed within 12 months without increasing compliance risk.

Root cause analysis

Before designing any solution, we spent three days mapping the existing process with the operations and compliance teams. The mapping revealed that the 5-day cycle was not a technology problem — it was a handoff problem. The actual work time across all steps was approximately 4 hours. The remaining 4+ days were waiting time caused by:

• Documents sitting in email inboxes between steps.
• Compliance screening running as a batch process once per day rather than in real time.
• Approvals requiring manual retrieval of data from multiple systems before a decision could be made.
• No visibility into where any given application was in the process, causing staff to spend time on status enquiries rather than processing.

The solution

We designed a Power Platform solution with four integrated components:

Component 1: Digital application portal (Power Pages). A branded, authenticated client portal for new application submission. The portal used conditional logic to collect only the information required for the client's specific product and risk profile, reducing form completion time from an average of 22 minutes to 8 minutes. Documents were uploaded directly and associated with the application record in Dataverse.

Component 2: Automated document processing (AI Builder + SharePoint Premium). Submitted documents were automatically classified and key fields extracted using AI Builder document processing models. Identity documents, proof of address, and financial statements were all handled by separate extraction models. Extracted data was written back to Dataverse fields and flagged for human review only when confidence scores fell below threshold.

Component 3: Compliance screening agent (Copilot Studio). A Copilot Studio agent was connected to the firm's compliance screening API and configured to trigger automatically when a new application was submitted. The agent ran screening checks, retrieved results, interpreted them against the firm's risk policy rules, and wrote a structured outcome (approve, review, escalate) to the Dataverse application record — typically within 90 seconds of submission.

Component 4: Approval workflow (Power Automate + model-driven app). The approval workflow used Power Automate to route applications based on the compliance outcome: automatic approval for low-risk profiles, reviewer queue for standard profiles, and escalation workflow for flagged applications. The model-driven app gave reviewers a single screen with all relevant application data, extracted document fields, and compliance results — eliminating the need to access multiple systems to make a decision.

Implementation timeline

The solution was delivered in 10 weeks across three sprints:

• Sprint 1 (weeks 1–4): Dataverse schema, security architecture, and AI Builder document processing model training.
• Sprint 2 (weeks 5–7): Power Pages application portal and Copilot Studio compliance agent.
• Sprint 3 (weeks 8–10): Power Automate approval workflows, model-driven reviewer app, and Power BI operations dashboard.

A parallel compliance review of the AI-assisted screening approach ran throughout the project, resulting in a formal policy update that approved the Copilot Studio agent as a first-line screening tool for standard applications, with human review retained for all escalated cases.

Results

In the 90 days following go-live:

• Same-day activation achieved for 78% of standard applications (up from 0%).
• Average onboarding cycle time reduced from 5.2 days to 6.4 hours.
• Document processing accuracy of 96.2% — above the 95% threshold required for the compliance policy approval.
• Compliance escalation rate unchanged at 8.3% — confirming that automation did not introduce compliance risk.
• Client satisfaction score during onboarding increased by 22 points (NPS methodology).

What made this work

Three factors were critical to the outcome:

1. Process mapping before solution design. Understanding that the problem was waiting time rather than work time changed the entire architectural approach. A faster system that still had the same handoff delays would not have achieved same-day activation.
2. Compliance involvement from day one. The compliance team's early involvement meant the solution was built to their requirements rather than presented to them as a fait accompli.
3. Confidence thresholds on AI extraction. Designing the document processing models with explicit confidence thresholds — and routing low-confidence extractions to human review — meant the accuracy rate was high enough to meet the compliance threshold without sacrificing automation coverage.