Architecture

Skill: Power Platform Solution Architecture

When to Use

Trigger when making design decisions: app type selection, solution structure, integration patterns, environment strategy, security model design.

App Type Selection Matrix

Decision rules:

• Dataverse data + standard CRUD + business process → Model-Driven App
• Custom UX + multiple data sources + mobile → Canvas App
• Complex interactive UI + pro-dev team + TypeScript expertise → Code App
• Rapid AI-generated custom page within MDA → Generative Page (GA)
• Combine: Code App for complex UI module, Model-Driven for admin/config

Solution Architecture Patterns

Single Solution (Prototypes / Small Apps)

Copy code
ContosoApp
├── Code App / Canvas App
├── Flows
├── Tables
├── Security Roles
└── Environment Variables

Use when: single team, <5 components, no cross-solution dependencies.

Layered Solutions (Enterprise)

Copy code
ContosoShared              ← Shared tables, security roles, env variables, global option sets
  ↑ depends on
ContosoCore                ← Core business logic, shared flows, custom APIs
  ↑ depends on
ContosoHR                  ← HR-specific app, flows, and components
ContosoFinance             ← Finance-specific app, flows, and components

Rules:

• Max 3-4 layers — deeper becomes unmaintainable
• Shared → Core → Domain prevents circular dependencies
• Each solution has its own publisher prefix
• Environment variables and connection references live in the Shared layer

Environment Strategy

Rules:

• NEVER import unmanaged solutions to Test, UAT, or Production
• Each environment has its own service principal for CI/CD
• DLP policies applied consistently across all environments
• Environment variables set per environment (never hardcoded)

Integration Decision Tree

Copy code
Need to integrate with external system?
├── Standard connector exists? → Use it (lowest maintenance)
├── REST API available?
│   ├── Simple, low volume → HTTP action in Power Automate
│   ├── Code App needs it → PAC CLI data source (pac code add-data-source)
│   └── Complex, reusable, high volume → Custom Connector + Azure APIM
├── No API (legacy/file-based)?
│   ├── File drop → Power Automate + Azure Blob
│   └── Database direct → Azure SQL connector or Dataflow
└── Real-time bidirectional → Azure Service Bus + Dataverse webhook

Security Architecture

Copy code
Authentication:   Entra ID (automatic for Code Apps — handled by Power Apps host)
Authorization:    Dataverse security roles (never app-level checks alone)
Secrets:          Azure Key Vault → Environment Variable (secret type)
Service accounts: Dedicated App Registration per solution (never personal accounts in pipelines)

Security Role Hierarchy:
  System Administrator    ← IT admins only
  System Customizer       ← Makers only, never end users
  [App] Admin             ← Full table access for app admins
  [App] Manager           ← Team-level access for managers
  [App] User              ← Own-record access for standard users

Custom API vs Power Automate vs Plugin

Capacity & Limits

Managed Environments

Managed Environments is a governance layer available on all paid Power Platform/Dynamics 365 licenses. Enable it per environment in the Power Platform Admin Center.

Key architectural implications:

• Required for Power Platform Pipelines (first-party ALM)
• Enables IP Firewall — restrict environment to corporate IP ranges
• Enables Customer Managed Keys — full encryption sovereignty
• Enables Lockbox — Microsoft engineer access requires explicit approval
• Enables Solution Checker enforcement — block non-compliant deployments
• Enables Conditional Access per app — Entra ID CA policies on individual apps

Recommendation: Enable Managed Environments on all non-Dev environments (Test, UAT, Production) from day one.

IMPORTANT (Feb 2026): Starting February 2026, pipeline target environments are auto-enabled as Managed Environments. Plan for this in your environment strategy.

DLP Policy Design

Data Loss Prevention (DLP) policies classify connectors as Business, Non-Business, or Blocked. Connectors in different groups cannot be used together in the same app or flow.

Design Principles

• Default posture: block everything, allow by exception
• Cannot block Microsoft-owned connectors
• Create environment-specific policies for isolated business use cases (e.g., DocuSign only in Contracts env)
• Pair DLP with your environment strategy — separate environments = separate policies

Connector Classification

Copy code
Business:     Connectors approved for business use (Dataverse, SharePoint, Teams)
Non-Business: Personal/consumer connectors (social media, personal email)
Blocked:      Never allowed in this environment (custom connectors for non-approved APIs)

Enforcement Stages

Copy code
Investigating → Learning → Notify Only → Design-time → Full Enforcement

Start with "Notify Only" to identify affected apps/flows before full enforcement.

Limits

• Max 600 DLP rules per tenant
• Policy max size: 100 KB

Observability & Monitoring

Application Insights Integration

Connect Power Platform to Azure Application Insights for end-to-end monitoring.

Copy code
Enable in Power Platform Admin Center:
  Environment → Settings → Product → Features → Export data to Application Insights
  → Enter Application Insights Connection String

What gets captured:
  - Canvas App: page loads, screen transitions, errors, custom traces
  - Model-Driven App: form load times, API call durations, JavaScript errors
  - Power Automate: flow run telemetry (requires Managed Environments)
  - Plugins: ILogger output (see plugins skill)
  - Dataverse Web API: request counts, latencies, failures

Monitoring Stack

Monitor Tool (Canvas App + Flow Diagnostics)

Copy code
Power Apps → Monitor → Open Monitor
→ Start session → Use the app → See real-time telemetry:
   - Network calls (URL, duration, status)
   - Screen navigation timing
   - Data operation duration
   - Delegation warnings (live)
   - Error details with call stack

Alerting

Copy code
Azure Application Insights → Alerts → New Alert Rule:
  - Condition: customEvents count > threshold (e.g., errors in last 15 min)
  - Action Group: Email, Teams webhook, Azure Function
  - Severity: Critical for production, Warning for test

Governance & Administration

Center of Excellence (CoE) Starter Kit

The CoE Starter Kit is a free, Microsoft-maintained solution for Power Platform governance.

Installation pattern:

Copy code
1. Dedicated environment ("CoE" or "Governance") — Managed Environment enabled
2. Install CoE Core first → run initial inventory sync (can take 24h for large tenants)
3. Configure environment variables: Admin email, Power BI workspace, excluded environments
4. Install Governance + Nurture after Core stabilizes
5. Customize: adjust thresholds, notification templates, exception lists

Important: CoE Starter Kit is NOT a managed solution from Microsoft — it ships as unmanaged. Plan for manual upgrades and potential customization drift.

Sharing & Maker Controls

Maker Onboarding Workflow

Copy code
New Maker identified (Entra ID group addition)
  └── Automated: Assign to "Maker" security group
  └── Automated: Grant Environment Maker role in Personal Productivity env
  └── Automated: Send welcome email (CoE Nurture template)
        - Training resources link
        - Governance policy summary
        - How to request a dedicated environment
  └── Gated: Request dedicated environment via approval flow
        - Business justification
        - Expected data classification
        - Sponsor approval
  └── Automated: Provision environment from template (if approved)

Environment Request & Provisioning

Admin Monitoring Checklist

• CoE inventory sync running daily without errors
• DLP violation alerts configured and routed to governance team
• Unused app cleanup flow active (e.g., archive apps not used in 90 days)
• Capacity alerts set (Dataverse storage, API calls, AI Builder credits)
• Environment creation requests reviewed weekly
• Connector consent requests reviewed within 2 business days

Architecture Decision Record (ADR) Template

markdownCopy code
## ADR-[Number]: [Decision Title]

### Status
[Proposed / Accepted / Deprecated / Superseded]

### Context
[What is the problem? What are the constraints? What requirements drive this decision?]

### Decision Drivers
- [Driver 1: e.g., "Must support 500 concurrent users"]
- [Driver 2: e.g., "Team has React/TypeScript expertise"]
- [Driver 3: e.g., "Must deploy across 3 environments via managed solutions"]

### Options Considered

| Option | Pros | Cons |
|---|---|---|
| [Option A] | [Pros] | [Cons] |
| [Option B] | [Pros] | [Cons] |
| [Option C] | [Pros] | [Cons] |

### Decision
[Which option was chosen and why]

### Consequences
**Positive:**
- [Benefit 1]

**Negative:**
- [Trade-off 1]

**Risks:**
- [Risk 1 + mitigation]

### ALM Implications
[How this decision affects solution structure, environment promotion, and CI/CD]

AI Architecture Decision Tree

Decision Tree

Copy code
Need AI capabilities in your solution?
├── Conversational AI (chat/voice)?
│   ├── Internal users (employees) → Copilot Studio agent deployed to Teams
│   ├── External users (customers) → Copilot Studio agent via Power Pages Agent API
│   └── Embedded in existing app → Copilot Studio agent embedded in MDA/Canvas
├── Autonomous AI (no user interaction)?
│   ├── Simple rule + AI → Power Automate Agent Flow
│   └── Complex multi-step → Copilot Studio autonomous agent
├── Document/image processing?
│   └── AI Builder (document processing, object detection, text recognition)
├── Custom LLM integration?
│   ├── Need standard models (GPT-4o, etc.) → Copilot Studio (built-in or BYOM)
│   ├── Need fine-tuned/custom model → Azure AI Foundry + Custom Connector
│   └── Need streaming/advanced patterns → Azure OpenAI direct from Code App
├── Multi-agent orchestration?
│   ├── Same domain → Copilot Studio embedded agents
│   └── Cross-domain/cross-tenant → Copilot Studio connected agents (A2A protocol)
└── Simple AI prompts in workflows?
    └── AI Builder GPT prompts in Power Automate

Comparison Matrix

When to Use Each

Cost Considerations

• Copilot Studio: per-tenant license + per-message beyond included allocation
• AI Builder: credits included with some licenses, pay-per-use otherwise
• Azure AI Foundry/AOAI: Azure consumption-based (token pricing)
• Evaluate: expected volume, required SLA, data residency requirements

Anti-Patterns for AI Architecture

• Using Azure AI Foundry when Copilot Studio covers the requirement (unnecessary complexity)
• Calling Azure OpenAI directly from Canvas Apps (expose API keys client-side)
• AI Builder for scenarios that need conversational context (it is stateless)
• Building custom RAG when Copilot Studio knowledge sources suffice
• No content moderation on any AI-generated output
• AI decisions without audit trail (compliance risk)

Anti-Patterns

• Monolithic single-solution architecture for anything beyond a prototype — leads to merge conflicts, deployment bottlenecks, and upgrade failures. Use solution layering (base + feature solutions) instead.
• Choosing Code Apps for simple CRUD forms — overkill for standard data entry. Use Model-Driven Apps for form-centric CRUD and reserve Code Apps for complex, custom UI.
• No publisher prefix strategy — leads to naming collisions, component ownership confusion, and blocked ALM. Define a short, unique prefix per publisher from day one.
• Security implemented only at the app layer (hiding buttons/tabs) — data is still exposed via API, Power Automate, Advanced Find. Always enforce security at the Dataverse level with security roles.
• No ALM plan at project start — results in manual deployments, environment drift, and "works on my machine" failures. Define solution structure, environment topology, and CI/CD pipeline at design time.
• Designing without data volume estimates — 100 rows and 10 million rows need fundamentally different patterns (pagination, indexing, async processing). Ask about expected volumes early.
• Over-engineering with microservice patterns — Power Platform has built-in orchestration (flows, plugins). Don't wrap simple Dataverse operations in Azure Functions unless there's a clear technical reason.
• Skipping the security model discussion — retrofitting security after go-live is expensive and error-prone. Design business units, roles, and row-level security upfront.

Related Skills

• security — Dataverse security model, roles, column-level security
• alm — CI/CD pipelines, solution lifecycle, environment promotion
• code-apps — Code Apps architecture (React + TypeScript + Vite)
• canvas-apps — Canvas App design patterns
• model-driven-apps — Model-Driven App design
• azure-openai — Azure OpenAI integration patterns
• copilot-studio — Copilot Studio agent design and deployment