diff --git a/.gitignore b/.gitignore index cb5b487608a..a2a9989ecf9 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,23 @@ +# macOS system files .DS_Store -.vscode/settings.json -*public/ + +# VS Code settings +.vscode/ + +# Visual Studio files +.vs/ +*.suo +*.user +*.userosscache +*.sln.docstates + +# Build artifacts +bin/ +obj/ + +# Hugo/static blog build artifacts +public/ resources/_gen/** + +# Windows thumbnails +Thumbs.db diff --git a/.vs/slnx.sqlite b/.vs/slnx.sqlite deleted file mode 100644 index 955fa6f185b..00000000000 Binary files a/.vs/slnx.sqlite and /dev/null differ diff --git a/content/post/homemade-plan-designer/index.md b/content/post/homemade-plan-designer/index.md new file mode 100644 index 00000000000..67cd01b6642 --- /dev/null +++ b/content/post/homemade-plan-designer/index.md @@ -0,0 +1,253 @@ +--- +title: "Homemade Plan Designer: Pragmatic Blueprinting for Power Platform" +date: 2025-08-26T19:50:00Z +author: "Jakub Bajla" +githubname: JakubBJL +categories: ["Community post"] +tags: [Power Platform, Plan Designer, Copilot, VS Code, Azure DevOps, ALM, Delivery Engineering] +type: "regular" +description: How a custom, environment-aware plan designer pipeline converts legacy artifacts + unstructured requirements into an automated, traceable Azure DevOps backlog using VS Code, Copilot, Power Platform CLI, and REST APIs. +--- + +## A Pragmatic Walkthrough: What Is Power Platform Plan Designer? + +Plan Designer (currently evolving; some capabilities may still be in preview) is Microsoft’s copilot‑first solution blueprinting tool for Power Platform. You describe your business scenario in natural language, attach diagrams or legacy screenshots, and the tool **generates a proposed solution plan**. The best features? It interprets process flows, requirements, and (where supported) images to suggest Dataverse tables, app screens, automations, connectors, and governance considerations—tailored to your business context (subject to the platform’s present maturity, which continues to expand). + +**Key capabilities:** + +- **Natural Language Input:** Feed Plan Designer business scenarios, requirements, even screenshots or ERD diagrams. +- **AI-Powered Blueprinting:** It suggests a mix of Power Apps, Dataverse tables, flows, connectors, and security elements. +- **Iterative Planning:** You can refine and rerun the plan, incorporating feedback or new requirements. +- **Copilot Collaboration:** The built-in AI can answer questions, propose alternatives, and explain architectural decisions. +- **Fast Prototyping:** The output is a structured planning artifact you can translate rapidly into a working prototype. + +### Where It Stops Today (and Why That Matters) +Plan Designer is brilliant for greenfield scenarios, but today it’s less opinionated about deep-diffing existing environments, enforcing custom naming standards, or wiring into bespoke ALM pipelines. If you want your blueprint to truly understand what’s already in your environment or enforce stricter governance, you extend—or build—a complementary layer. + +--- + +## Why Build My Own? The "Homemade" Premise + +Ever since Plan Designer came out, I presented it countless times, tracked reviews from fellow MVPs, watched features roll out at speed. But there was a different direction I wanted to explore, and the nudge came when I learned that Power Platform CLI now supports connecting to MCP Server. That’s when the experiment began — wiring MCP into my VS Code (Thanks, Appie! Link to blog below, in resources), where GitHub Copilot Pro was already my daily buddy. + +### What is MCP Server & Why Does It Matter? + +An MCP Server (preview) provides context-aware access to environment metadata—solutions, tables, relationships and selected records—subject to permissions. MCP‑aware clients (where integrations exist) can query and analyze that metadata to accelerate discovery and reuse. + +Functional walkthrough: +- Stand up or connect to an MCP Server endpoint (preview feature—verify availability). +- Authenticate your client. +- Enumerate metadata (solutions, tables, relationships) and surface existing candidates for reuse. +- Drive assisted prompts: “Reuse existing table?” “Extend existing automation?” “Align to existing pattern?” + +For more: official docs, community deep dives, and GitHub repos (links below). + +Curiosity took over. What if I could assemble my own plan designer—one that: + +- **Is Environment-Aware:** Surfaces existing tables, flows, apps, and prompts for reuse. +- **Handles Varied Documentation:** Word docs, PDFs, legacy specs—because real requirements are messy. +- **Follows My Rules:** My naming, conventions, and architectural guardrails—not only defaults. +- **Feeds Directly into Azure DevOps:** Automatically generates epics, issues, tasks with traceable tags. + +--- + +## Step-by-Step: My Homemade Plan Designer Pipeline + +### Step 1: Connect to Dev Environment & Extract Artifacts + +Work against a *development* (unmanaged) environment for discovery. (Production ALM should rely on managed solutions and official deployment tooling.) + +**Functional Steps:** + +1. Authenticate: + + ```shell + pac auth create --url + ``` + +2. List / export solutions (for analysis): + + ```shell + pac solution list + pac solution export --name --outputDirectory ./export --managed false + ``` + +3. Enumerate tables: + + ```shell + pac table list + ``` + + - Parse `customizations.xml` to catalog entities, option sets, environment variable definitions/values, workflows. + - Assemble a configuration inventory (Name, IntendedPurpose, DeploymentScope, DefaultValue). + - Note custom controls, web resources, process automation assets. + - (Optional ALM hygiene) Unpack for source control: + + ```shell + pac solution unpack --zipFile ./export/.zip --folder ./src/ + ``` + +### Step 2: Artifact Analysis & Domain Synthesis + +Map technical artifacts into business-aligned capability domains using heuristics or lightweight classifiers: + +| Artifact | Heuristic | Domain | +|------------------|----------------------------------|----------------------| +| Workflow name | contains 'Group' | Identity & Access | +| Env var name | contains 'URL' + doc keywords | Document Integration | +| Custom control | reused in multiple forms/apps | Experience / UX | + +(Extendable with regex, keyword scoring, or future embeddings.) + +### Step 3: Requirements Upload & Analysis + +Convert PDFs to text locally (avoid external services for sensitive content), chunk text, classify segments, and prompt an AI assistant in the editor: +> “Given these extracted lines, propose domain alignment and flag references to existing tables.” + +Aggregate into candidate capability sets. + +### Step 4: Backlog Engineering & Codification + +Define a consistent CSV schema: + +| Ref | ParentRef | Type | Title | Description | Domain | Tags | Priority | Effort | +|-----|-----------|-------|-------|-------------|--------|------|----------|--------| +| REF-101 | (blank for Epic) | Epic | Access Management | ... | Identity & Access | IAM;REF-101 | 1 | 5 | + +Use deterministic reference tags (REF-*) for traceability (the system’s numeric work item IDs are generated separately). + +Create work items via Azure DevOps REST (JSON Patch, Content-Type: application/json-patch+json): + +```json +[ + { "op":"add","path":"/fields/System.Title","value":"Access Management Epic" }, + { "op":"add","path":"/fields/System.Description","value":"Full HTML/Markdown description here" }, + { "op":"add","path":"/fields/System.Tags","value":"Identity & Access;REF-101" } +] +``` +Check existence first (idempotency) with WIQL: +```json +{ "query": "SELECT [System.Id] FROM WorkItems WHERE [System.TeamProject] = @project AND [System.Tags] CONTAINS 'REF-101'" } +``` +Conceptual “Features” collapse into Issues in the Basic process (hierarchy: Epic → Issue → Task). + +### Step 5: Automated Delivery Loop + +Indicative timing: + +- Extraction: ~2 min +- Parsing + domain synthesis: ~2 min +- Backlog assembly: ~3 min +- Import run: <2 min + +Idempotency: WIQL guard by REF tag; consistent tagging enables safe re-runs without duplication. For future drift detection, a hash or version marker could be added as an additional tag or custom field. + +### Step 6: Flow Diagram (ASCII) + +```text +(Env Export via CLI) + ↓ +(Artifact Parser) → (Config Catalog) + ↓ +(Domain Classifier) ← (Req Docs Ingestion) + ↓ +(Backlog Generator CSV) + ↓ +(Import Script: WIQL guard + JSON Patch) + ↓ +(Azure DevOps: Epics / Issues / Tasks tagged + refs) + ↓ +(Future Enrichment: Areas, Iterations, Telemetry Hooks) +``` + +--- + +## Technical, Architectural, and Developer Aspects + +**Contract:** +- **Inputs:** Export folder (analysis only), requirements text, mapping config. +- **Outputs:** Azure DevOps epics/issues/tasks with domain + REF tags. +- **Non-Functional:** Idempotent, extensible, offline-friendly. + +**Layering:** Export → Parse → Classify → Backlog → Import → (Enrich). + +**Security & Governance Notes (Added):** +- Treat exports as potentially sensitive; keep in secured source control. +- Do not place secrets or personal data into AI prompts. +- Store Azure DevOps PAT in a secure secret store or environment variable—never inline. +- Managed Environments, DLP policies, and solution layering remain authoritative governance controls. + +**Scope Clarification:** This pipeline accelerates *planning and analysis*, not production deployment. Official deployment should use Pipelines for Power Platform, ALM Accelerator, or equivalent. + +--- + +## Where This Fits in ALM & Governance + +This experimental pattern complements (not replaces) official tooling: +- **Use It For:** Environment discovery, capability mapping, structured backlog seeding. +- **Hand Off To:** Managed solution packaging, pipeline-based promotion, environment validation (DLP, solution checks) via standard ALM tools. +- **Governance Layers:** Managed Environments, DLP policy enforcement, solution layering strategy, policy-as-code validation (naming, publisher consistency). +- **Preview Features:** Plan Designer enhancements and MCP Server endpoints may differ across tenants; verify availability before adoption. + +--- + +## Challenge Themes Tackled → Mechanisms + +| Challenge Theme | Mechanism / Pipeline Component | +|---------------------------|-------------------------------------------------------------------------------| +| Configuration Governance | Central variable inventory + naming validation (planned regex rules) | +| Process Modernization | (Planned) Workflow normalization + orchestration templates | +| Domain Taxonomy Sustain | Artifact-to-domain mapping + backlog classification | +| Observability & Metrics | Tagging + planned telemetry hooks for dashboards | +| Iterative Planning | Future area/iteration enrichment layered on domain hierarchy | +| Extensibility Guardrails | Mapping config + contract-based extensibility | +| Idempotent Automation | WIQL guard + reference tag uniqueness | +| Governance Reporting | Domain tags + REF tags powering dashboards and compliance views | + +--- + +## Result: Reusable, Scalable Pattern + +Artifacts: +- Backlog CSV template +- Parameterized import script (org/project, tag prefix) +- Classification mapping table (artifact → domain) +- Extensible flow allowing future modules (environment diff, dependency graph, policy validation) + +KPIs (Track Empirically): +- Time-to-backlog (minutes) +- Requirement coverage (count of tagged references) +- Re-run consistency (no duplicate creations) + +--- + +## Summary + +In short, this experiment pulled everything together: we started by inspecting the environment and cataloging what already existed, then layered in every requirement we could gather — no matter the format. From there, we applied structure: mapped artifacts to domains, enforced naming and governance rules, and turned it all into a clean, hierarchical backlog. Finally, the entire plan flowed into Azure DevOps as traceable work items, ready for iteration and delivery. The result is a design and execution blueprint that respects what’s in place, aligns with what’s needed, and stays true to the standards we set. + +--- + +## Final Thoughts + +This homemade pipeline isn’t trying to beat the official Plan Designer — let’s be honest, Plan Designer is slick, approachable, and on a rocket of a roadmap. This is something else: a sandbox for makers, architects, and curious engineers who like taking things apart, wiring them back together, and seeing how far the platform can stretch. On a canvas as wide as Power Platform, playing around isn’t a distraction — it’s how new patterns, reusable accelerators, and better habits get discovered. + +What makes this fun is that experimentation doesn’t have to ignore the serious stuff. You can play with AI-assisted classification, custom extraction, and idempotent backlog generation while still respecting ALM discipline, Managed Environments, solution layering, DLP policies, and secure handling of exports and tokens. Governance and innovation aren’t opposing forces; when you line them up, they actually speed each other along. + +The recipe here is simple: extract, learn, model, codify, automate — then iterate. Keep what works, retire what doesn’t, and feed the good pieces back into your standard toolchain (pipelines, managed solutions, dashboards). The rest of the Microsoft ecosystem — Azure DevOps, CLI tooling, AI copilots — is more than ready to meet you halfway. + +So keep experimenting. Build your own accelerators. Stress-test ideas before the product ships them. The boundaries of what’s possible on the platform keep expanding, and the only real limit is how curious (and disciplined) we’re willing to be. + +--- + +## Resources & Further Reading + +- [Power Platform Plan Designer Documentation](https://learn.microsoft.com/en-us/power-apps/maker/plan-designer/plan-designer) +- [Power Platform CLI Documentation](https://learn.microsoft.com/en-us/power-platform/developer/cli/introduction) +- [Power Platform ALM Guidance](https://learn.microsoft.com/power-platform/alm/) +- [Azure DevOps Work Item REST API](https://learn.microsoft.com/en-us/rest/api/azure/devops/) +- [Azure DevOps WIQL basics](https://learn.microsoft.com/en-us/azure/devops/boards/queries/wiql-syntax) +- [JSON Patch (RFC 6902)](https://datatracker.ietf.org/doc/html/rfc6902) +- [MCP Server: Connect to Dataverse (Preview)](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/data-platform-mcp) +- [MCP Server GitHub repo (m365-galleries-mcp)](https://github.com/pnp/m365-galleries-mcp/) +- [CloudAppie: Exploring MCP Server benefits](https://www.cloudappie.nl/power-platform-cli-exploring-mcp-server-benefits/) +- [XrmBedrock on GitHub](https://github.com/delegateas/XrmBedrock) diff --git a/content/post/managed-dev-environment-license-to-build/index.md b/content/post/managed-dev-environment-license-to-build/index.md new file mode 100644 index 00000000000..7fa265df198 --- /dev/null +++ b/content/post/managed-dev-environment-license-to-build/index.md @@ -0,0 +1,184 @@ +--- +title: "Managed DEV Environment Bottleneck: License to Build" +date: 2025-07-30T08:00:00+02:00 +author: "Jakub Bajla" +githubname: JakubBJL +categories: ["Community post"] +tags: [Power Platform, Power Apps, Power Automate, Microsoft 365, Governance, ALM, Managed Environments] +type: "regular" +--- + +## Quick Overview or TL;DR +We built a governance model for onboarding new Power Platform makers using Managed Environments. By leveraging environment group and environment routing features, we ensured that new makers are automatically directed away from the Default environment and into their own personal, developer-type Managed Environments. The solution detects when a trial license is silently provisioned, informs the maker with clear guidance, and keeps admins in the loop with reminders and escalation logic. + +--- + +## Introduction & Context +Managed Environments offer advanced governance capabilities for Power Platform, but they require premium licenses. When onboarding new makers, especially in large organizations, this licensing requirement can become a bottleneck. + +It's important to note that “premium” in this context doesn’t mean only Power Apps Premium (Power Apps per user plan) — it also includes trial licenses, and in some cases, even Per-App entitlements. This piece of information is at the core of both the challenge and the solution. + +To streamline onboarding while maintaining governance, we leveraged environment routing, developer environments, and Power Automate to create a scalable, automated solution that ensures compliance and supports makers throughout their journey. + +--- + +## Problem & Requirements +When a new maker starts building in Power Platform, environment routing sends them to a personal developer environment. This routing is triggered the first time the user accesses https://make.powerapps.com. If the environment already exists, routing simply redirects them there. If it has been deleted, a new developer environment is provisioned automatically. + +This routing mechanism is part of the environment group feature and is designed to keep makers away from the Default environment — a space that often lacks governance, visibility, and control. But this use case goes beyond just isolation. It’s about creating a more advanced and streamlined experience for admins and makers alike. For admins, it brings visibility into who is building, when, and under what license. For makers, it ensures their work is protected and that timely support can be provided. It also aligns with Microsoft’s product direction, as recent release waves have introduced more capabilities exclusive to Managed Environments. + +Access to build or edit within a Managed Environment requires premium license rights. These rights can come from: +- A Power Apps Premium (Power Apps per user plan) license already assigned to the user. +- A Per-App pass granted when the user is given access to an app they want to edit. + +If none of these apply, and the user has never had a Power Apps trial before, a trial license is automatically provisioned in the background (unless your organization has specifically disabled trial provisioning via Power Platform admin settings). This silent provisioning is what enables the Managed Environment to function - but it also introduces a governance blind spot. + +We want unaware makers away from Default, but routing only works with environment groups - and the full benefits of automatic personal dev environment creation and isolation are only available when using Managed Environments. While environment routing can be configured for non-managed environments, the advanced features described here require Managed Environments. + +This raises several challenges: +- Admins have no visibility into trial provisioning. +- Makers may be unaware of licensing implications. +- Governance teams need assurance that work won’t be lost. +- Licensing must be upgraded if the maker’s solution is accepted for production. + +We needed a solution that: +- Detects when a trial is provisioned. +- Notifies the maker with clear, comforting guidance. +- Keeps admins informed and prompts follow-up actions. +- Supports ALM and solution promotion workflows. + +--- + +## Solution Architecture + +### Environment Routing +- Environment group is configured with routing enabled. +- New makers are automatically routed away from the Default environment and into personal developer-type Managed Environments. + +This architecture assumes that your organization has implemented a basic “maker experience” — a set of onboarding practices that help new makers understand where they’ve landed and what to do next. This typically includes enabling the **Maker Welcome Message** feature, which appears when a new environment is provisioned. That message can link to training materials, explain the purpose of the environment, and point to internal support channels or documentation. For example, you might link to a SharePoint site or Azure DevOps wiki that outlines how to request promotion of a solution from an individual dev environment to a shared dev environment — such as the Solution Promotion Guide used in our organization. This is all part of a broader journey: enabling makers, supporting their growth, and helping them move from ideas to production-ready apps. + +For more technical details on environment groups and routing, see Microsoft’s official documentation: +- [Managed Environments overview](https://learn.microsoft.com/power-platform/admin/managed-environments-overview) +- [Environment groups and routing](https://learn.microsoft.com/power-platform/admin/environment-groups) + +### Trial Detection +- Environment creation is logged in Microsoft Purview (or in the unified audit log, if enabled). Ensure that Purview or unified audit logging is enabled and that log retention meets your organization's needs for robust monitoring and tracking. +- **Note:** There is no direct audit log for license provisioning events. Our solution infers trial provisioning by monitoring related activities, such as environment creation and license assignment through associated audit events. +- Trial provisioning is inferred using audit events such as `EnvironmentCreated` or `PowerPlatformEnvironmentProvisioned`, which indicate when a new environment is created. +- A Power Automate flow monitors these logs and identifies the environment creator/owner. +- The flow uses Microsoft Graph API to check the creator’s assigned licenses. Note: This requires the flow to have appropriate permissions (such as Directory.Read.All) in Entra ID, and these should be granted securely with admin consent and proper credential management for production scenarios. +- The flow queries the `/users/{id}/licenseDetails` endpoint to retrieve assigned SKUs. This includes trial SKUs such as `POWERAPPS_P2_VIRAL`, if visible based on tenant settings. +- If the user does not have a premium or Dynamics 365 license, but holds a trial SKU (e.g., POWERAPPS_P2_VIRAL), the flow infers that a trial was provisioned. +- The user is then notified via email with onboarding or governance guidance (next step). + +For more on trial license provisioning and monitoring, refer to Microsoft Docs: +- [Power Platform licensing FAQ](https://learn.microsoft.com/power-platform/admin/powerapps-flow-licensing-faq) +- [Official Power Platform Licensing Guide (PDF)](https://go.microsoft.com/fwlink/?linkid=2223452) +- [Auditing in Power Platform](https://learn.microsoft.com/power-platform/admin/auditing-power-platform) + +> **Best Practice:** +> When using Microsoft Graph API in Power Automate flows, grant permissions via a secure Azure AD application and follow your organization’s credential management standards. Regularly review permissions and API usage for compliance. + +### Maker Notification +- The flow sends a personalized email to the maker explaining: + - Why the trial was provisioned. + - What Managed Environments are. + - What happens when the trial expires. + - How their work will be preserved. + - How to submit their solution for promotion. + - Who will help them and where to find guidance. + +### Admin Notification & Reminder +- The flow also notifies Power Platform admins that a trial-based environment was created. +- It schedules reminders at 20 and 25 days after the initial notification to prompt license review or escalation. + +--- + +## Maker Email Template + +Subject: Welcome to Your Power Platform Developer Environment + +Hi [Maker Name], + +Welcome to Power Platform! A personal development environment has been created for you so you can start building apps and automations. + +To enable this, a free trial license was automatically activated for you. This trial is only used to give you access to a Managed Environment — a workspace with advanced features like enhanced security, monitoring, and support. + +✅ What you should know: +- You can start building right away — no action needed. +- Your work is safe. Even if the trial expires, you won’t lose anything. +- When your trial expires, you will lose access to Managed Environment features and any premium capabilities (such as premium connectors or Dataverse) unless you have another valid premium license (Power Apps Premium (Power Apps per user plan), Per-App, or Pay-As-You-Go). Your work remains stored and accessible. You can continue building in a standard (unmanaged) development environment, but premium features will only be available if your license supports them. + +📚 Getting Started +You may have already seen a welcome message in your environment — this is part of our Maker Onboarding Experience. It includes links to training materials, development guidelines, and support contacts. If you missed it, you can access the same resources here: +👉 [Insert link to Maker Onboarding Portal or SharePoint site] + +🚀 What happens if your idea gets approved? +If your prototype is submitted and selected for further development: +- Your solution will be moved to a team development environment that flows through our deployment pipeline to production. +- You’ll be given a full license so you can continue working in Managed Environments without limitations. +- Please note: Moving solutions between environments may require admin or elevated permissions, so this process is not always fully self-service for makers. + +📌 What if your idea isn’t meant for production? +If your current project is exploratory or not intended for production, you can request a standard (unmanaged) development environment instead. Just reach out to your Power Platform admin or team sponsor. + +📈 Want help getting your solution ready for production? +You can review the full process for promoting your solution here: +👉 [Insert link to Solution Promotion Guide on SharePoint or Azure DevOps] +And if you’d like advisory support with your development efforts — from architecture to ALM — feel free to contact us directly. + +If you have any questions, we’re here to help. + +Happy building, +[Your Team or Admin Name] + +--- + +## Admin Notification & Reminder Flow + +### Flow: Trial Detection & Notification + +Trigger: +- Scheduled or Purview-based detection of new environment creation. + +Steps: +1. Get environment metadata and owner. +2. Check owner’s license type via Power Platform Admin APIs. +3. If no premium or Dynamics 365 license: + a. Send email to maker (template above). + b. Notify Power Platform admins. + c. Schedule reminders at +20 and +25 days. + +### Flow: Admin Reminder Logic + +Trigger: +- Scheduled flow triggered 20 and 25 days after initial notification. + +Steps: +1. Lookup environment and maker. +2. Check if license has been upgraded. +3. If not: + a. Send reminder to Power Platform admins. + b. Optionally escalate to licensing or governance team. + +These notifications and reminders serve a strategic purpose. Within 3–4 weeks of a maker starting their journey, it should become clear whether their work is exploratory and better suited for an unmanaged development environment, or whether it shows potential business value. In the latter case, the maker can be invited into a team-managed development environment — one that already has licensing investments in place, whether through Power Apps Premium (Power Apps per user plan), Per-App passes, or Pay-As-You-Go. This transition not only empowers the maker but also aligns their efforts with the organization’s ALM pipeline and ROI goals. + +--- + +## Result +We achieved: +- Seamless onboarding for new makers. +- Transparent communication about licensing. +- Automated governance and admin visibility. +- Support for ALM and solution promotion. + +This solution ensures that licensing constraints don’t block innovation, while maintaining control and compliance across the platform. + +--- + +## Final Thoughts +By combining environment routing, audit logs, and Power Automate, we created a scalable governance model that supports makers and admins alike. + +Thanks for reading. If you’re building similar onboarding flows or facing licensing challenges, I’d love to hear how you’re approaching it — feel free to connect, share your story, or ask questions. We’re all learning together. + +--- diff --git a/content/post/per-app-as-you-go/index.md b/content/post/per-app-as-you-go/index.md new file mode 100644 index 00000000000..65ec09e0fd0 --- /dev/null +++ b/content/post/per-app-as-you-go/index.md @@ -0,0 +1,165 @@ +--- +title: "Per-App-as-You-Go" +date: 2025-07-14T08:00:00+02:00 +author: "Jakub Bajla" +githubname: JakubBJL +categories: ["Community post"] +tags: [Power Platform, Power Apps, Power Automate, Microsoft 365, Microsoft Entra ID, Governance, ALM] +type: "regular" +--- + +## Quick Overview or TL;DR + +We built a licensing model for a nonprofit’s Power App that mimicked Pay-As-You-Go behavior using Per-App licenses, Power Automate, and security groups. + +--- + +## Introduction & context + +Licensing is often overlooked when designing Power Platform solutions, especially in environments with mature governance or existing premium entitlements. However, when building your first enterprise-grade app in a cost-conscious organization, licensing becomes a core architectural consideration. + +In our case, we worked with a nonprofit deploying their first enterprise-grade Power Platform solution. One role in the app was designed to be tenant-wide — available to everyone, but only used by a small subset of users, and only occasionally (sometimes never). This surfaced licensing as a design constraint, not just a budget item. + +The challenge: how to accommodate a large, undefined user base without overcommitting licenses or compromising governance. The licensing model would directly influence how we structured environments, provisioned access, and automated onboarding and offboarding processes. + +--- + +## About Licensing Sources + +Microsoft provides two primary resources for evaluating Power Platform licensing models: + +- **Power Platform Licensing Guide**: A downloadable PDF that outlines license entitlements, supported scenarios, and use rights across all Power Platform products. +- **Microsoft Learn documentation**: Continuously updated technical guidance covering licensing behavior, environment configuration, and governance considerations. + +Both are essential when validating assumptions, designing access models, or aligning architecture with licensing constraints. + +--- + +## Problem & Requirements + + +We needed a model that provided elastic access for a large, mostly inactive user base, with license assignment based on actual usage—not eligibility. Integration with identity-based access control and automated license recovery were key requirements, all while aligning with Enterprise Agreement cost structures. + +Static license assignment would either overcommit resources or require manual intervention to manage consumption, which was not sustainable for our scenario. + +--- + +## Alternatives + +### Pay-As-You-Go (PAYG) + +PAYG is billed through Azure and charges only when a user launches the app. It is ideal when you do not know how many users you will have or how often they will use the app. It is flexible, usage-based, and does not require upfront license commitments. + +The PAYG model is defined as a measure of the number of unique, active users who open a single PAYG-enabled app in an environment one or more times in a month. This makes it attractive for scenarios with unpredictable or infrequent usage. + +But here is the catch. My customer had an Enterprise Agreement (EA), which meant negotiated rates were in play. Under an EA, discounts are typically tied to projected license revenue, primarily Microsoft 365 or Business Applications, and are often approved based on committed project plans. Azure consumption, on the other hand, falls under a different revenue category. It usually requires a separate commitment and sometimes even a separate contractual motion. + +In practice, this means that PAYG licenses, billed through Azure, are discounted through a different channel than Per-App or Premium licenses. And that distinction matters. It is not just accounting, it is strategic. The two motions are treated differently by Microsoft’s internal teams, and the incentives do not always align with what is best for the Power Platform project or the customer. + +In our case, the Business Applications bucket received a significantly higher discount than Azure. Specifically, our discount for Business Applications licenses was nearly four times greater than what we received for Azure consumption. And when you factor in that PAYG is already roughly twice the cost of Per-App at list price, the economics became clear: Per-App licensing was substantially more cost-effective, even if PAYG offered more flexibility. + +So while PAYG may seem more flexible on paper, the licensing motion behind it can make it less favorable in EA-governed environments. Sometimes, especially in early-stage projects or initial business value assessments, even these nuances can have a significant impact, and they need to be factored in when building on the platform. + +### Per-App Licensing + +Per-App licenses are assigned to an environment, not directly to users. Once a user is granted access to any app in that environment, either by being shared the app or added to a security group, **they consume a Per-App license for each app they are assigned to**. If a user is given access to multiple apps, **each app assignment consumes a Per-App license**—this is the "stacking" behavior. + +Key behaviors: +- Licenses are consumed as soon as access is granted, regardless of whether the app is used. +- Licenses do not return to the pool unless access is explicitly revoked. +- If a user is assigned to multiple apps in the same environment, they will consume multiple Per-App licenses (one per app). + +This stacking behavior is intentional. It is a bridge between PAYG and Premium licenses. At $5 per app, once a user stacks four licenses, it makes sense to upgrade them to a $20 Premium license. The Premium license allows users to run unlimited apps and access unlimited Power Pages websites, which becomes cost-effective in broader usage scenarios. + +But for our use case, occasional users in a cost-conscious organization, this model was a bit too sticky unless we automated governance and access revocation. + + +--- + +## Reality Check: The Hidden Risk of Over-Assignment + +Considering all of the above means that if we added our entire tenant to a security group tied to the app environment (group created to be tied to that one particular role), every member of that group will start consuming a license, even if they never open the app. The system does not wait for usage, it assigns licenses based on access. + +So in theory, if your tenant has 2,000 users and you only have 500 Per-App licenses, only the first 500 users in the group (based on internal ordering) will get licenses. The rest will be blocked from access unless more licenses are added. This behavior is subtle but important, and it is why governance matters. + +That's why, when considering Per-App licenses, it's crucial to think about all access considerations. This ensures your license pool is used efficiently and avoids silent license exhaustion. + +--- + +## Our Decision + +While the previous section highlighted the risks of Per-App licensing—particularly how licenses are consumed upon access rather than usage, from an architectural standpoint, Per-App licensing also gave us the flexibility to build a governance model that directly addressed those risks. + +By automating access provisioning and revocation, we could ensure that licenses were only consumed when truly needed and returned to the pool promptly. This allowed us to neutralize the “stickiness” of Per-App behavior and turn it into a scalable, cost-efficient solution. + +Moreover, the lower cost of Per-App licenses under our EA meant we could engage more users within the same budget. For a first enterprise-grade app, this was critical. It allowed us to demonstrate business value early, reach a broader audience, and lay the foundation for future apps—all without overcommitting on licensing. + +We ruled out Access Packages (via myaccess.microsoft.com) because they require either Azure AD Premium P2 licenses or the Microsoft Entra ID Governance add-on for every user who might request access. Both options come at an additional cost, which wasn’t feasible for our tenant-wide audience. That said, if your organization already has P2 via M365 E5 or has invested in the Governance add-on, Access Packages might be a viable option. + +In summary, we chose Per-App licensing because: +- It was significantly cheaper under our circumstances compared to PAYG +- We could control access through security groups +- We could build a governance layer to simulate PAYG-like behavior + +--- + +## Implementation: Automated Governance + +To address the licensing behavior of Per-App licenses—where access, not usage, consumes a license—we built a lightweight governance model using Power Automate. The goal was to ensure that licenses are only consumed when needed and automatically released when no longer required. + +For this particular end-user group—occasional users with tenant-wide eligibility but low-frequency access—we designed a tailored onboarding experience. Their journey begins with a Microsoft Form embedded directly into the process documentation. This form acts as the official entry point for requesting access to the app. Once submitted, the request is handled by a Power Automate flow that governs access provisioning. The flow can be fully automated or include an approval step, depending on the organization’s governance preferences. + +### Step 1: Request Access via Microsoft Form + +Users initiate access by submitting a Microsoft Form. This form is tailored to their role and embedded in the documentation they already use, making it easy to find and understand. + +#### Why this matters: +- It provides a documented, auditable entry point for access. +- It aligns with business-led app adoption, where users may not be familiar with IT processes. +- It ensures that only eligible users trigger license consumption. + +#### Flow Logic: +1. **Trigger**: When a new response is submitted in Microsoft Forms. +2. **Validation**: The flow checks if the responder’s email ends with the organization’s domain (e.g., `@contoso.com`). If not, the request is rejected with a friendly message. +3. **Access Provisioning**: If valid, the user is added to a security group tied to the app environment. This grants access and consumes a Per-App license. +4. **Notifications**: Confirmation is sent to the user, and the system admin is notified for visibility. + +### Step 2: Revoke Access Automatically + +To avoid license waste, we implemented automated offboarding using two strategies: + +- **Time-Based Expiry**: A scheduled flow runs on a fixed cadence (e.g., monthly) and removes all users from the relevant security group. This is ideal when the business process has a predictable duration. +- **Process Completion-Based Removal**: For more dynamic scenarios, access is revoked as soon as the user completes their task. This is triggered by business logic—for example, when a submission is marked complete in Dataverse or SharePoint. + +Both approaches ensure that licenses are recycled efficiently, supporting a sustainable and scalable licensing model. + +--- +## Result + +We achieved: +- Cost savings by avoiding PAYG and Access Packages +- License recycling through automated access management +- Scalable governance without premium add-ons + +The solution is simple, transparent, and works well for occasional access scenarios, especially in organizations where every dollar counts. + +If you want to see or try the actual Power Automate flows described in this blog, check out the repository here: +[JakubBJL/per-app-as-you-go on GitHub](https://github.com/JakubBJL/per-app-as-you-go/tree/main) + +--- + +## Final Thoughts + +If you’re building your first enterprise app in Power Platform, don’t treat licensing as an afterthought. It’s not just a cost—it’s a constraint, a design factor, and sometimes a creative challenge. + +Thanks for reading. If you’re facing a similar licensing puzzle, feel free to connect. I’m Jakub, still learning, still experimenting, and always happy to share what’s worked (and what hasn’t). + +Special thanks to **Yannick**, who assured me of the basics when I started figuring this out (and replied to my message at 1:30 AM!), and to **Zilong**, my talented padawan, who brings my design ideas and architectures to life. + +## Resources & Further Reading + +- [Per-App Licensing Governance Flows Repository](https://github.com/JakubBJL/per-app-as-you-go/tree/main) + (Contains Power Automate flows, setup instructions, and more context) +- [Power Platform Licensing Guide (PDF)](https://go.microsoft.com/fwlink/?linkid=2085130) +- [Microsoft Learn documentation](https://learn.microsoft.com/power-platform/admin/power-platform-licensing) +