Forem: Zsolt Zombik

Canvas Apps vs Code Apps in Power Apps: When low-code hits its ceiling

Zsolt Zombik — Fri, 17 Apr 2026 06:22:28 +0000

You're three months into a Power Platform engagement. The Canvas App you built is impressive — multiple screens, solid Dataverse model, Power Automate flows running clean. Stakeholders are happy. The maker on the team has already started adding screens themselves.

Then the requirements change. A filterable grid against 50,000 Dataverse rows. A custom chart with real-time updates. Pixel-perfect components from a Figma file. And then someone asks: "Can we write unit tests for the business logic?"

You're staring at Power Fx, knowing it can't get you there. This is the ceiling.

📄 This post summarizes Power Apps: Canvas Apps vs. Code Apps – When Low-Code Hits Its Ceiling originally published on AIDevMe.
The full article includes a head-to-head comparison table across 15 dimensions, architecture deep dive with runtime execution models, complete CSP security configuration guide, decision framework with specific signals, and FAQ covering the 10 most common Code App gotchas.

Code Apps are not PCF controls — this is where most architects get it wrong

When I say "Power Apps Code Apps," most people think "PCF controls." That's not it.

PCF (Power Apps Component Framework) controls are individual UI components you embed in Canvas or Model-Driven Apps. They're React components with a specific lifecycle, wrapped to integrate into the Power Apps runtime.

Code Apps are full applications. React + TypeScript projects developed in VS Code, run locally against a live Dataverse environment, deployed as solution components. They have their own routing, state management, component tree. They access Dataverse and the full Power Platform connector catalog via the Power Apps client library (@microsoft/power-apps) from JavaScript.

The scaffold comes from the official template:

npx degit github:microsoft/PowerAppsCodeApps/templates/vite my-app
cd my-app
pac auth create
pac env select --environment <Your environment ID>
npm install
pac code init --displayname "My Code App"
npm run dev

You write real TypeScript with hooks, context, custom components. Any npm package that runs in a browser is available. Full developer experience: IntelliSense, debugging, source maps, Jest test suite in CI/CD.

The app inherits enterprise governance — Microsoft Entra auth, DLP enforcement, Conditional Access — but you control the architecture. It's closer to building a React web app that happens to run inside Power Platform than a Canvas App built with code.

The three signals that Canvas Apps are fighting you

Canvas Apps are excellent tools. I reach for them constantly. But they have a capability ceiling, and when you hit it, you feel it immediately.

Performance at scale. Complex filtering and aggregations against tens of thousands of Dataverse rows require workarounds — collections, Power Automate flows, defensive UI patterns. A Code App using direct OData access through the client library? No comparison. The delegation model in Power Fx helps, but when you're writing intermediate Power Automate flows just to pre-aggregate data because the Canvas formula layer can't handle it, you've crossed the line.

Component reuse and maintainability. State management across 30+ screens becomes painful. You can't import npm packages. There's no dependency injection. When Canvas Apps grow beyond 40 screens, they become difficult to maintain — not because developers are careless, but because the paradigm doesn't scale to that complexity.

No real unit testing. You cannot write meaningful unit tests for Power Fx formulas the way a professional development team expects. PAC CLI has basic testing support, but it doesn't compare to Jest and React Testing Library in a Code App where you can test components, mock API calls, and validate state transitions.

When you're spending more time fighting Canvas limitations than solving the business problem, it's time to move up the stack.

The architectural difference that actually matters

Canvas Apps operate on a platform-managed abstraction. The runtime interprets your Power Fx formulas, manages state, handles rendering, routes data calls through the connector layer. You work within the platform's model.

Data calls from Canvas Apps flow through connectors over OData. Standard online connectors travel from the client through Azure API Management and the connector layer to the target data source and back — each layer adds latency. Dataverse is the fast path (direct to environment instance), but you're still inside the Power Fx abstraction. The .msapp bundle is a ZIP archive of serialized screen definitions and control metadata. No direct DOM access. No module bundler. Your logic lives entirely in Power Fx.

Code Apps operate on a developer-controlled execution model. Your TypeScript compiles to JavaScript and runs in the browser. The platform provides the host (authentication, app lifecycle) and the Power Apps client library (connector access), but everything between — component architecture, state management, rendering logic, data fetching strategy — is yours to design and own.

The platform constraints move from "the runtime won't let you do this" to "the CSP policy needs to allow this origin." That's both the power and the cost.

Security: CSP enforced strict by default

Canvas Apps ship with Content Security Policy off by default. Even when enabled, the default is permissive — script-src * 'unsafe-inline' 'unsafe-eval' — trading security for compatibility.

Code Apps enforce CSP strict by default from day one: connect-src 'none', script-src 'self'. Every outbound fetch or XHR call — including calls to your own Azure Functions backend — is blocked until you explicitly allowlist the origin in the Power Platform admin center under Settings → Privacy + Security → Content Security Policy → App tab, or via the PowerApps_CSPConfigCodeApps REST API setting.

For regulated industries where InfoSec needs auditable control over exactly which origins the app communicates with, this is an advantage. You can prove to a security auditor exactly which origins are allowlisted, enforce it at the platform level, and get violation reports sent to a SIEM endpoint. Canvas Apps can't offer that level of CSP specificity — only frame-ancestors is customizable; everything else is platform-controlled.

For developers spinning up their first Code App, it's the gotcha that costs an afternoon wondering why fetch calls silently fail. Read the CSP docs before you deploy.

The fusion team pattern: Canvas and Code, not Canvas vs Code

Here's the insight that changed how I design solutions: Canvas Apps vs Code Apps isn't an either/or decision.

On the Nextwit Environment Management Application, the architecture was:

Dataverse as the shared backend
Power Automate for long-running provisioning workflows
Canvas App for the operational dashboard — maintained by a maker without developer involvement
Code App for the architect-facing frontend — dynamic filtering, complex state, real-time updates, custom React components

Neither app was a compromise. Each was exactly the right tool for its audience. This is the fusion team pattern: citizen developers and pro developers working in parallel on different parts of the same solution, each in the paradigm that fits their skills. Both apps share the same Dataverse tables, subject to the same security roles and DLP policies.

When a stakeholder asks "should we use Canvas or Code Apps?" — often the right answer is "yes."

Key takeaways

Code Apps are full React + TypeScript applications, not PCF controls — they have their own routing, state management, and component tree
Code Apps require Power Apps Premium licensing for end-users, not standard per-user licensing — factor this into your project budget from day one
CSP is enforced strict by default in Code Apps — connect-src 'none' will block all external API calls until you configure allowed origins
Code Apps must be explicitly enabled per environment by an admin in the Power Platform admin center — it's off by default
The Canvas ceiling shows up in performance at scale, complex UI, ALM friction, and unit testing — when you hit it, you feel it immediately
The fusion team pattern uses both — Canvas for makers, Code for developers, shared Dataverse backend — this is the most powerful architectural pattern in the Power Platform toolkit right now

Read the full article

This post covers the strategic comparison, but the complete article on AIDevMe goes further:

Head-to-head comparison table across 15 dimensions (paradigm, tooling, licensing, ALM, performance ceiling, governance, CI/CD integration)
Architecture deep dive — how Canvas and Code Apps actually work at runtime, with execution model diagrams and data flow paths
The decision framework — specific signals for when to reach for Canvas, Code, or both
Agentic development with the microsoft/power-platform-skills marketplace for Claude Code and GitHub Copilot
Code App setup walkthrough with the npm-based CLI and PAC CLI hybrid approach
Security configuration — complete CSP directive control and how to configure per environment via admin center or REST API
FAQ section covering the 10 most common Code App gotchas (CSP failures, licensing requirements, environment enablement, ALM strategies)

👉 Read the complete article: Power Apps: Canvas Apps vs. Code Apps – When Low-Code Hits Its Ceiling

Under the Hood: How Dataverse Skills Actually Work (And Why It Matters for Your Copilot Credit Bill)

Zsolt Zombik — Sat, 11 Apr 2026 06:38:03 +0000

I asked my coding agent to "create a table for tracking employee certifications."

Five minutes later: complete Dataverse schema. Five tables. Relationships. Sample data. The whole thing.

But here's what kept me up that night: How did the agent decide which tool to use for each step?

Why MCP Server for metadata queries, Python SDK for bulk data, and PAC CLI for solution export?

More importantly: One of those costs Copilot credits. The other two don't.

Let's tear apart Dataverse Skills to see how it actually works.

The Two Unfair Advantages

Understanding skill internals gives you:

1. Cost Control Through Tool Selection

MCP calls: Consume Copilot credits (per 10 responses)
Python SDK calls: Free (direct Web API)
PAC CLI calls: Free (local tooling)

When your agent uses MCP for a bulk operation that could've used the Python SDK, you're paying unnecessarily.

2. Organizational Knowledge as Code

Write skills that encode your patterns:

Publisher prefix conventions
Mandatory audit columns
Solution structure standards

Update one skill file → every developer follows the new pattern automatically. No retraining needed.

Skill File Anatomy: It's Just Markdown

Every Dataverse skill: Markdown + YAML frontmatter. That's it.

Microsoft's Official Format

---
name: dv-metadata
description: >
  Create and modify Dataverse tables, columns, relationships, forms, and views.
  Use when: "add column", "create table", "modify form".
  Do not use when: exporting solutions (use dv-solution).
---

# Skill: Metadata — Making Changes

**Do not write solution XML by hand.**

The correct workflow:
1. Make the change in the environment via MetadataService API
2. Pull the change into repo via `pac solution export` + unpack
3. Commit the result

The exported XML is generated by Dataverse itself and is always valid.

Key insight: The description field's "Use when" triggers are what agents use to match your prompts to skills.

Extended Format: Security Boundaries

For organizational skills, extend the frontmatter:

---
name: aidevme-create-table
description: >
  Creates a new custom table in Dataverse.
  Use when: "create table", "add entity", "new table".
version: 1.0.0
phase: build
allowed-tools:
  - bash
  - python
  - file
  # NO web_fetch - prevents data exfiltration
safety:
  - Verify publisher prefix matches active solution
  - NEVER add tables to Default solution
requires:
  - dataverse-connect
  - dataverse-create-solution
priority: normal
---

The `allowed-tools` Security Boundary

This field restricts which tools the agent can use.

Example: A data-loading skill may allow bash and file for CSV imports.

But allowing web_fetch opens the door to prompt injection attacks that exfiltrate data via external APIs.

The allowed-tools field is your defense against prompt injection.

How Agents Chain Skills

When you type:

Create a table for tracking employee certifications

The agent:

Scans all skills for relevance
Identifies dataverse-create-table as primary match
Checks requires field → loads prerequisites first
Executes steps in sequence
Selects tools based on allowed-tools

For complex prompts, the chain looks like:

dataverse-connect
  └── dataverse-mcp-register
dataverse-create-solution
dataverse-create-table (× 5)
  └── dataverse-create-column (× N)
  └── dataverse-create-relationship (× 2)
dataverse-load-data
dataverse-query

Not hardcoded. Built from requires declarations + semantic analysis.

The Three-Tool Strategy (The Part That Really Matters)

Agent-driven development requires encoding tool selection logic into skills themselves.

It's about three factors:

Cost management: MCP calls = Copilot credits
Operational correctness: Bulk ops need transactional integrity
Architectural compliance: ALM needs PAC CLI for audit trails

Tool 1: Dataverse MCP Server

Best for:

Fast metadata queries (list_tables, describe_table)
Simple record reads (read_query)
Single-record operations

Limitations:

Charged per use (Copilot credits)
Not optimal for bulk operations

Tool 2: Dataverse Python SDK

Best for:

Bulk data operations (100+ records)
Pandas DataFrame transformations
ETL pipelines

The advantage: Uses Web API directly. No MCP charges.

from PowerPlatform.Dataverse.client import DataverseClient
from azure.identity import AzureCliCredential

client = DataverseClient(
    "https://yourorg.crm.dynamics.com", 
    AzureCliCredential()
)

# Bulk create with CreateMultiple (100x faster)
records = [
    {
        "aidevme_firstname": f"Consultant {i}", 
        "aidevme_specialization": "Power Platform"
    }
    for i in range(1, 51)
]
ids = client.records.create("aidevme_consultant", records)
print(f"Created {len(ids)} consultants")

Tool 3: PAC CLI

Best for:

Solution ALM (export, import, publish)
Environment management
Component registration

# Solution export for ALM
pac solution export \
  --name ConsultingTracker \
  --path ./solutions/ConsultingTracker.zip \
  --managed false

# Publish all customizations
pac solution publish

The Decision Matrix

Task	MCP	Python SDK	PAC CLI
List tables	✅	❌	❌
Read 10 records	✅	✅	❌
Read 10,000 records	❌	✅	❌
Create 1 record	✅	✅	❌
Create 500 records	❌	✅	❌
Export solution	❌	❌	✅

The cost impact:

Typical dev session (5-table solution): 25-50 MCP calls

50-person team, 10 sessions/week: 12,500-25,000 MCP calls/month

Industry benchmark: $200-800/month for 20-100 developers

Real-World Production Example

From Daniel Kerridge's claude-code-power-platform-skills:

---
name: dataverse-plugins
description: >
  Use when developing Dataverse plugins.
  Use when: "plugin", "server-side logic", "PreValidation".
---

## CRITICAL RULES

1. **Plugins run in a sandbox.** Restricted access to external resources.

2. **2-minute timeout** for synchronous plugins. Use async or 
   offload to Power Automate for long operations.

3. **Throw `InvalidPluginExecutionException`** to show user-facing 
   errors. All other exceptions = generic error messages.

4. **Never use static variables** for state. Plugin instances are 
   cached and reused. Use `IPluginExecutionContext.SharedVariables`.

5. **Always register entity images** when you need pre/post values. 
   Don't make extra Retrieve calls.

Why this matters: Junior developers make these mistakes once (painfully). When encoded in the skill, the agent never makes them.

That's organizational knowledge as code.

Writing Your Own Skills

Base Template

---
name: {publisher}-{action}-{subject}
description: >
  What it does and when to use it.
  Use when: "trigger phrases".
  Do not use when: {anti-patterns}.
---

# Skill: {Title}

## Purpose
What does this skill do?

## Pre-conditions
1. What must be true before running?
2. What environment state is assumed?

## Steps

### Step 1: Validate inputs
What to check first.

### Step 2: Main operation
The actual work. Include tool calls, code examples.

### Step 3: Verify and report
How to confirm success.

## Error handling
| Error | Cause | Resolution |
|-------|-------|------------|
| ... | ... | ... |

Extended Template (With Security)

Add these optional fields:

---
name: {publisher}-{action}-{subject}
description: >
  Description with triggers.
version: 1.0.0
phase: build
allowed-tools:
  - bash
  - python
  - file
safety:
  - Explicit safety rules
requires:
  - dataverse-connect
priority: normal
---

Testing Your Skills

For Claude Code

Create .claude-plugin/marketplace.json:

{
  "name": "My Power Platform Skills",
  "version": "1.0.0",
  "skills": [
    {
      "name": "aidevme-create-table",
      "path": "skills/aidevme-create-table.md"
    }
  ]
}

For GitHub Copilot

Add to .github/plugins/yourorg/.

Test with explicit invocation

/aidevme-create-environment Create a sandbox named "Project Alpha Dev"

The Debugging Checklist

Agent using wrong tool?

✅ Check skill's description field for user's trigger phrase
✅ Add explicit tool guidance in step instructions
✅ Review allowed-tools restrictions
✅ Increase priority if competing with built-in skills
✅ Verify skill registration in marketplace.json

Key Takeaway

The most valuable IP in intent-driven development: well-crafted skills that encode your organization's patterns.

When you write a skill that says:

"Always verify publisher prefix before creating tables"
"Never add to Default solution"
"Use Python SDK for 100+ records"

You're encoding decisions that would otherwise live in developer heads and tribal knowledge.

Update one skill file → every agent session follows the new pattern.

What's Next: Part 4

Coming up: Enterprise Architecture View

MCP billing models (real benchmarks)
Managed Environment governance
ALM integration patterns
Security posture (prompt injection, secrets)
2026 Power Platform roadmap context

The questions that determine enterprise adoption.

Resources

📖 Full Technical Guide: aidevme.com/under-the-hood-how-dataverse-skills-work

🔧 Daniel Kerridge's Skills: github.com/DanielKerridge/claude-code-power-platform-skills

🎯 Microsoft Dataverse Skills: github.com/microsoft/dataverse-skills

Discussion

Have you written custom Dataverse skills? What patterns are you encoding?

What tool selection decisions have you made (MCP vs SDK vs CLI)?

Drop a comment below 👇 — I reply to everyone.

From Scripts to Intent: How AI Agents Are Changing Power Platform Development

Zsolt Zombik — Fri, 03 Apr 2026 08:02:21 +0000

The Developer Tax We've All Been Paying

If you've built anything on Power Platform, you know the workflow:

Open terminal → pac auth create
Switch to browser → navigate maker portal
Inspect table schema
Jump to docs → find correct API syntax
Write PowerShell script
Run it (column name typo)
Fix it, run again
Export solution (forgot to add the table)
Go back, repeat

This constant context-switching between CLI, browser, docs, and scripts? That's what I call the developer tax on enterprise platforms.

On April 1, 2026, Microsoft's Dataverse team shipped something that fundamentally changes this equation: Dataverse Skills.

(Shout-out to Suyash Kshirsagar from Microsoft for the excellent announcement post)

What If You Could Just... Say What You Want?

Instead of orchestrating six different tools, what if you could describe your intent in natural language?

"I'm building a recruiting system for Zava Construction 
with tables for Positions, Candidates, and Interviewers. 
Positions link to multiple Candidates, and Candidates 
can have multiple Interviewers."

With Dataverse Skills installed, GitHub Copilot or Claude Code:

✅ Creates a new solution with publisher prefix

✅ Generates tables with proper columns and data types

✅ Configures relationships (1:N, N:N)

✅ Loads sample data that matches your domain

✅ Validates the schema

✅ Exports a deployable solution package

All from a single prompt. Zero context-switching.

How It Actually Works

Dataverse Skills is an open-source plugin that gives coding agents structured knowledge of Power Platform development patterns.

Under the hood, it uses the Model Context Protocol (MCP) to expose Dataverse capabilities through a standardized interface that AI agents can invoke.

The Architecture:

┌─────────────────────────────────────┐
│   You (Natural Language Intent)    │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│  AI Agent (GitHub Copilot/Claude)  │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│      Dataverse Skills Plugin       │
│  (Translates intent → actions)     │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│   Dataverse MCP Server + PAC CLI   │
│    (Executes operations)           │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│     Your Dataverse Environment     │
└─────────────────────────────────────┘

Three Core Phases:

CONNECT - Authenticate, discover environments, register with MCP server
BUILD - Create tables, columns, relationships, solutions, forms
OPERATE - Load data, run queries, perform bulk operations

What This Means for Different Roles

👨‍💻 For Developers

Onboarding acceleration: Junior devs can be productive on day one instead of spending weeks learning PAC CLI syntax. They describe what they need; the agent scaffolds it correctly.

Prototyping speed: A full data model with sample data can be stood up in minutes from a single prompt, not hours of maker portal clicking and script debugging.

Knowledge embedded: Best practices are encoded in the agent. No more searching wikis for "how to set up a publisher prefix correctly."

🏗️ For Solution Architects

Consistency by default: The plugin encodes best practices (publisher prefixes, solution structure, ALM hygiene) that propagate automatically across projects.

Governance without friction: Because the agent uses the same tools and patterns every time, architectural standards become self-enforcing rather than requiring constant code reviews.

Focus shift: You move from explaining how to do things to defining what should be done and why — which is where architectural value actually lies.

👥 For Teams

Tool standardization: One plugin investment works for both GitHub Copilot and Claude Code users. Teams get consistent Dataverse capabilities regardless of which AI assistant they've adopted.

Portable knowledge: Architectural patterns become portable across different coding agents rather than locked into a single vendor's ecosystem.

The Broader Shift: Intent-Driven Development

This isn't just about Dataverse. It's about a fundamental shift in how we interact with enterprise platforms.

Traditional approach:

Developer → Manual tool orchestration → Platform

Intent-driven approach:

Developer → Natural language intent → AI agent → Automated orchestration → Platform

The agent becomes the orchestration layer that handles the busywork of tool integration, API syntax, and workflow coordination.

Other examples of this pattern:

Business Skills - Natural language → Copilot Studio conversational apps
Infrastructure-as-Code agents - "Deploy a highly available web app on Azure" → Terraform/Bicep generation
Database agents - "Add an audit log table to track all customer changes" → Schema migrations + triggers

The common thread? You describe the intent; the agent handles the implementation.

Getting Started (15 Minutes)

Install the plugin:

   # For GitHub Copilot
   gh copilot install dataverse-skills

   # For Claude Code  
   claude plugin install dataverse-skills

Authenticate:

   pac auth create --environment yourenv.crm.dynamics.com

Try a prompt:

   "Create a simple inventory tracking system with 
   Products, Categories, and Suppliers tables"

Watch the agent build it - Solution created, tables generated, relationships configured, sample data loaded.

That's it. You're building with natural language.

Real Talk: What This Changes (And What It Doesn't)

What it changes:

✅ Junior developers productive immediately (not after weeks of training)
✅ Prototyping 10x faster (minutes instead of hours)
✅ Best practices enforced automatically
✅ Architects focus on strategy, not syntax

What it doesn't replace:

❌ Understanding business requirements
❌ Architectural decision-making
❌ Security and compliance judgment
❌ Complex integration patterns

Think of it like Copilot for code completion—it handles the boilerplate and common patterns, freeing you to focus on the hard problems that actually require human expertise.

The Ecosystem Play

Dataverse Skills is part of Microsoft's broader MCP ecosystem:

Dataverse MCP Server - The foundation that exposes Dataverse operations
Business Skills - Link natural language to Copilot Studio apps
Azure Skills (coming) - Cloud infrastructure as intent
Third-party MCP servers - Community-built integrations

This creates a composable AI developer experience where different skills can work together through a common protocol.

Imagine:

"Create a recruiting system in Dataverse, 
deploy a web portal to Azure App Service,
and build a Copilot Studio conversational interface 
for candidates to check application status"

Three different skills, one unified intent, end-to-end automation.

My Take: This Is Just the Beginning

I've spent years building on Power Platform—from PCF controls to complex Dataverse solutions to ALM automation.

Every time, the orchestration overhead was the hidden cost. Not the learning curve of the platform itself, but the cognitive load of juggling tools, memorizing syntax, and context-switching constantly.

Dataverse Skills doesn't eliminate complexity—it abstracts the orchestration layer.

And that changes the economics of enterprise platform development in ways we're just starting to understand.

Questions? Thoughts?

Have you tried Dataverse Skills yet? What's been your experience with AI-assisted development on Power Platform?

Drop a comment—I'd love to hear what's working (or not working) for your team. 👇

About the Author

I write at AIDevMe.com about Power Platform development, AI-assisted coding, and enterprise automation. If you found this helpful, follow me for more content on building better with less friction.

Originally published at aidevme.com on April 3, 2026.

Power Pages Authentication Methods: The Complete Guide (2026)

Zsolt Zombik — Wed, 01 Apr 2026 09:39:08 +0000

"Wait, why are we storing passwords in Dataverse? Don't we have Azure AD?"

The question came from a security auditor during a partner portal review. I watched the project lead shift uncomfortably in their chair. The portal had been live for six months. Hundreds of external partners were logging in daily. And suddenly, we were all wondering the same thing.

The answer? It's complicated. And it revealed something I see far too often: teams building Power Pages portals don't fully understand the five authentication methods Microsoft provides — and most choose the wrong one.

The Problem With Power Pages Authentication

Microsoft Power Pages is brilliant for building external-facing portals quickly. Customer dashboards, partner collaboration sites, employee self-service pages — all built on top of Dataverse with low-code tools. It's fast. It's powerful.

But here's where it gets tricky: authentication.

The moment you add user-restricted content, you need to answer a critical question: How will your users prove who they are?

Power Pages gives you five distinct authentication methods:

Local Authentication (ASP.NET Identity) — username/password stored in Dataverse
OpenID Connect (OIDC) — modern federated authentication with Azure AD B2C or Entra ID
SAML 2.0 — enterprise-grade federation with ADFS, Okta, Ping Identity
OAuth 2.0 Social Login — "Sign in with Google/Microsoft/LinkedIn"
Open Registration — self-service account creation with invitation codes

Each has a different protocol, trust model, configuration complexity, and risk profile. Choose poorly, and you're looking at:

Account takeovers
Regulatory compliance failures
Phishing vulnerabilities
A painful (and expensive) re-architecture later

What I Wish Someone Had Told Me Three Years Ago

After that security audit, I spent weeks digging through Microsoft Learn documentation, OASIS specifications, IETF RFCs, and trial-and-error testing. I wanted to understand not just how each method worked, but when to use it and what security risks came with it.

Here's what I learned:

Local Authentication: Microsoft Says "Migrate Away From This"

The built-in username/password system stores credentials directly in Dataverse contact records. It's convenient for proof-of-concept work, but Microsoft explicitly recommends migrating to Azure AD B2C for production.

Why?

Email-only 2FA (not phishing-resistant)
No Conditional Access integration
Weak password policies by default (no uppercase/digit requirements out of the box)
If IsDemoMode is accidentally left True in production, OTP codes are displayed in the UI — catastrophic

When to use it: Rapid prototyping, internal demos, transitional scenarios

When NOT to use it: Any portal with regulated data (GDPR, HIPAA, PSD2)

OIDC: The Modern B2C Solution

OpenID Connect integrates with Azure AD B2C or Entra ID. It's the modern federated approach.

Key advantage: Conditional Access policies enforced at the identity provider level — device compliance, location-based restrictions, risk-based authentication

Security gotcha: By default, Power Pages uses the code id_token flow with form_post response mode. This exposes the ID token in the browser. For better security, switch to authorization code flow with PKCE.

Best for: Customer-facing portals (B2C scenarios)

SAML 2.0: Enterprise-Grade Federation

SAML is the gold standard for partner portals and B2B scenarios. It integrates with corporate identity systems like ADFS, Okta, and Ping Identity.

Key advantages:

Phishing-resistant (with proper configuration)
POST binding keeps tokens out of browser history
Single Logout (SLO) support
Group/role claims mapping for access control

Critical configuration: Set WantAssertionsSigned = True. Don't just validate the response envelope — validate the assertions themselves.

Best for: Enterprise/partner portals, B2B scenarios

Social OAuth: Convenience vs. Security

Let users sign in with their existing Google, Microsoft, LinkedIn, Facebook, or Twitter accounts.

When it makes sense: Consumer communities, public-facing portals where user convenience matters more than enterprise security.

What you give up: No enterprise MFA enforcement, minimal role claims, no Single Logout

Best for: Consumer-facing portals, community sites

Open Registration: Controlled Onboarding

Not an authentication protocol — it's a registration workflow. Users can create accounts with or without invitation codes.

Critical settings:

OpenRegistrationEnabled = False for enterprise portals
CaptchaEnabled = True if any self-registration is allowed
ResetPasswordRequiresConfirmedEmail = True (not the default!)

The Comparison Table You Actually Need

I built a side-by-side comparison table covering:

External IdP requirements
Enterprise MFA enforcement
Phishing resistance
Token visibility in browser
Group/role claims
Single Logout support
Regulatory compliance fit
Microsoft's recommendations
Setup complexity

It answers the question I had during that audit: "Which one should I actually use?"

The Real Answer to That Auditor's Question

Back to that security audit. Why were we storing passwords in Dataverse when we had Azure AD?

Because the team didn't realize they had better options. They saw "authentication" in the Power Pages setup wizard, clicked a few checkboxes, and moved on.

They didn't know:

Local auth is deprecated for production
SAML 2.0 would have leveraged the existing corporate identity system
Conditional Access policies could have been enforced automatically
Password rotation, MFA, and account lockout policies were already managed in Azure AD

The migration took three weeks, cost the project budget, and delayed the v2 roadmap. All because of an authentication decision made in the first sprint.

What I Built

I wrote the guide I wish had existed three years ago: a complete technical breakdown of every Power Pages authentication method with:

✓ Step-by-step protocol flows — understand exactly what happens during login

✓ Security configuration tables — every critical setting with defaults and recommendations

✓ Risk analysis — real-world security scenarios and how to mitigate them

✓ When to use each method — and when to absolutely avoid it

✓ Side-by-side comparison — answer "which one?" with confidence

Whether you're wiring up your first portal, designing an enterprise solution, or preparing for a security audit, this guide has the depth you need.

Read the Full Guide

The complete technical breakdown is here:

Power Pages Authentication Methods: The Complete Guide (2026)

It covers every authentication method in detail — local auth, OIDC, SAML 2.0, social OAuth, and open registration — with configuration examples, security best practices, and decision frameworks.

Your Turn

If you're building or securing Power Pages portals, I'd love to hear:

What authentication method did you choose — and why?
What "gotchas" did you run into during implementation?
What surprised you about Power Pages authentication?

Drop a comment. Let's learn from each other's experiences.

GitHub Agentic Workflows: AI Agents Are Coming for Your Repository Maintenance Tasks (And That's a Good Thing)

Zsolt Zombik — Wed, 01 Apr 2026 09:36:40 +0000

Your GitHub issues pile up unlabeled. Your documentation drifts three sprints behind your code. Your CI failures sit uninvestigated. Your test coverage quietly erodes, sprint after sprint.

If you manage a GitHub repository at scale — whether it's a Power Platform ALM pipeline, a PCF control library, or an enterprise DevOps monorepo — you know this grind intimately.

Traditional GitHub Actions workflows are powerful, but they're fundamentally deterministic. They execute exactly what you tell them, step by step. They don't understand your repository. They don't reason about context. They can't make judgment calls.

Until now.

Enter GitHub Agentic Workflows

In February 2026, GitHub Next launched GitHub Agentic Workflows in technical preview — bringing AI coding agents directly into GitHub Actions with security guardrails, sandboxed execution, and human-in-the-loop review.

The paradigm shift is elegant:

Instead of writing imperative YAML that tells GitHub exactly what to do, you write natural language specifications that describe what you want to achieve. The AI agent figures out how.

Here's what a workflow looks like:

---
on: issues
permissions:
  issues: write
  contents: read
safe-outputs:
  add-labels: {}
  add-comment: {}
---

# Issue Triage Agent

Analyze new issues in this PCF control repository and apply 
appropriate labels: bug, build-error, performance, feature-request, 
fluent-ui-migration, or needs-info.

Research the codebase for relevant context. If critical diagnostic 
information is missing, request it politely. Always explain your 
classification.

When a new issue opens, the agent analyzes the content, searches your codebase for context, applies appropriate labels, and leaves an explanatory comment — automatically, within seconds.

No manual rules. No explicit conditionals. Just intent.

Welcome to "Continuous AI"

GitHub calls this vision Continuous AI — positioning it alongside CI/CD, not as a replacement.

Just as:

Continuous Integration automated build verification
Continuous Deployment automated release pipelines

Continuous AI automates the subjective, judgment-heavy repository maintenance tasks that traditional automation simply cannot express.

Think about what falls through the cracks on every team:

❌ New issues sit unlabeled for days

❌ Documentation describes refactored features from three months ago

❌ Tests are added reactively, never proactively

❌ CI failures get acknowledged in Slack but never properly root-caused

❌ Repository health reports get written quarterly, if at all

These tasks require contextual understanding, not just script execution. That's where AI coding agents excel.

Six Core Automation Categories

GitHub has identified six primary use cases that become practical with Agentic Workflows:

1. Continuous Triage

Intelligent issue labeling, classification, and routing based on codebase context. In production on GitHub's own repositories, triage agents respond within 60 seconds with accurate, context-aware classifications.

2. Continuous Documentation

Automated documentation maintenance that stays synchronized with code changes. GitHub ran six specialized doc agents in production:

Daily Documentation Updater — 96% merge rate (57/59 PRs)
Glossary Maintainer — 100% merge rate (10/10 PRs)
Documentation Unbloat — 85% merge rate (88/103 PRs)

These aren't hypothetical. These are real production results.

3. Continuous Code Simplification

Autonomous refactoring agents that identify opportunities to simplify without changing functionality. In extended production use:

Automatic Code Simplifier — 83% merge rate (5/6 PRs)
Duplicate Code Detector — 79% merge rate (76/96 PRs)

The agents use semantic analysis (via Serena toolkit) to understand code meaning, not just textual patterns.

4. Continuous Test Improvement

Proactive test generation based on code changes, coverage gaps, and bug patterns — rather than reactive "write tests after the bug ships" approaches.

5. Continuous Quality Hygiene

Automated CI failure investigation. When workflows fail, agents analyze logs, identify root causes, and propose fixes as pull requests.

6. Continuous Reporting

Weekly or monthly repository health reports — dependency status, PR review latency, test coverage trends, deployment frequency — generated automatically with actionable insights.

How It Works: Architecture and Security

This isn't cowboys running unrestricted AI agents with full repository access. GitHub designed Agentic Workflows around principle of least privilege:

✅ Read-only by default — agents start with no write permissions

✅ Explicit permissions — YAML frontmatter declares exactly what the agent can access

✅ Sandboxed execution — agents run in isolated GitHub Actions containers

✅ Safe outputs — agents can only call explicitly declared GitHub operations

✅ Network isolation — restricted internet access prevents data exfiltration

✅ Human review gates — agents open pull requests, they don't auto-merge

You write workflow definitions in Markdown with YAML frontmatter. The gh aw CLI extension compiles your definition into standard GitHub Actions YAML that invokes one of three AI coding agents:

GitHub Copilot CLI (requires COPILOT_GITHUB_TOKEN)
Anthropic Claude Code (requires ANTHROPIC_API_KEY)
OpenAI Codex (requires OPENAI_API_KEY)

Real-World Applications for Power Platform Developers

For Power Platform teams, this unlocks automation scenarios that were previously impossible:

PCF Control Repositories

Documentation that auto-updates when TypeScript interfaces change
Intelligent issue triage that understands Fluent UI migration problems vs webpack build errors
Automated dependency upgrade PRs with context about breaking changes

Dataverse Solution Repositories

Schema documentation synchronized with solution export commits
Weekly health reports identifying ALM pipeline failures and patterns
Automated security role permission matrix updates

Power Automate Custom Connectors

API documentation that stays synchronized with OpenAPI spec changes
Intelligent routing of issues to connector owners vs platform bugs
Automated changelog generation from commit history

Important Caveats You Need to Know

GitHub Agentic Workflows are powerful, but they're technical preview with real limitations:

⚠️ Not production-ready — APIs and syntax will change

⚠️ API token costs — agents make dozens of API calls per run; costs can add up

⚠️ Human oversight required — always review agent-generated PRs before merging

⚠️ Prompt injection risks — untrusted input (public repo issues) can manipulate agent behavior

⚠️ Evolving best practices — we're all learning what works and what doesn't

This isn't replacing developers. It's augmenting repository maintenance workflows with intelligent automation that frees senior engineers from mechanical, time-consuming tasks.

Agentic Workflows vs Running Agents Directly in YAML

You might ask: "Why not just call Claude or Copilot directly from GitHub Actions YAML?"

You can — but you lose the safety guardrails:

Aspect	Direct YAML	Agentic Workflows
Permissions	Unrestricted (whatever the workflow has)	Explicit, minimal (declared in frontmatter)
Outputs	Agent can call any GitHub API	Agent restricted to declared safe-outputs
Sandboxing	Optional	Mandatory
Audit trail	Manual logging	Automatic, structured
Best practices	DIY	Built-in by GitHub

Agentic Workflows enforce principle of least privilege by design. You get intelligent automation and enterprise-grade safety controls.

The Bigger Picture: Where This Is Going

GitHub Agentic Workflows represent something larger than a new CI/CD feature. They're a preview of intent-driven software development.

Imagine a future where:

Developers define what should be accomplished (outcomes, quality standards, architectural principles)
AI agents handle how it gets implemented (code changes, tests, documentation, deployment)
Humans provide judgment (code review, architectural decisions, feature prioritization)

We're not there yet. But technical previews like this are signposts on the path.

The question isn't whether AI will change how we maintain codebases. It's whether your team will adopt it proactively — learning, experimenting, defining best practices — or reactively, two years from now when it's table stakes.

Getting Started

GitHub Agentic Workflows are in technical preview. To experiment:

Install the gh aw CLI extension
Pick a simple use case (issue triage is the "hello world")
Create a Markdown workflow definition
Configure an AI agent API key (Copilot, Claude, or Codex)
Run the workflow and review the output

Start small. Learn the patterns. Iterate.

Want the Full Technical Deep Dive?

This article covers the essential concepts, but there's much more to explore:

Detailed architecture diagrams
Complete workflow definition examples for Power Platform scenarios
Production metrics from GitHub Next's own usage
Security model comparisons
Cost analysis and API token management strategies
Step-by-step setup tutorials

Read the comprehensive guide:

GitHub Agentic Workflows: The Next Evolution of Repository Automation for Power Platform and Enterprise Developers

Final Thoughts

Repository maintenance is unglamorous work. It doesn't ship features. It doesn't close customer tickets. But it determines whether your codebase remains maintainable or slowly descends into chaos.

GitHub Agentic Workflows won't solve every problem. They won't replace human judgment. But they can handle the mechanical, context-heavy work that drains hours every week from your senior engineers.

And those hours? They can be redirected to architecture, feature development, mentoring, and the high-leverage work that actually requires human creativity.

Welcome to the era of Continuous AI.

Forem: Zsolt Zombik

Canvas Apps vs Code Apps in Power Apps: When low-code hits its ceiling

Code Apps are not PCF controls — this is where most architects get it wrong

The three signals that Canvas Apps are fighting you

The architectural difference that actually matters

Security: CSP enforced strict by default

The fusion team pattern: Canvas and Code, not Canvas vs Code

Key takeaways

Read the full article

Under the Hood: How Dataverse Skills Actually Work (And Why It Matters for Your Copilot Credit Bill)

The Two Unfair Advantages

1. Cost Control Through Tool Selection

2. Organizational Knowledge as Code

Skill File Anatomy: It's Just Markdown

Microsoft's Official Format

Extended Format: Security Boundaries

The allowed-tools Security Boundary

How Agents Chain Skills

The Three-Tool Strategy (The Part That Really Matters)

Tool 1: Dataverse MCP Server

Tool 2: Dataverse Python SDK

Tool 3: PAC CLI

The Decision Matrix

Real-World Production Example

Writing Your Own Skills

Base Template

Extended Template (With Security)

Testing Your Skills

For Claude Code

For GitHub Copilot

Test with explicit invocation

The Debugging Checklist

Key Takeaway

What's Next: Part 4

Resources

Discussion

From Scripts to Intent: How AI Agents Are Changing Power Platform Development

The Developer Tax We've All Been Paying

What If You Could Just... Say What You Want?

How It Actually Works

What This Means for Different Roles

👨‍💻 For Developers

🏗️ For Solution Architects

👥 For Teams

The Broader Shift: Intent-Driven Development

Getting Started (15 Minutes)

Real Talk: What This Changes (And What It Doesn't)

The Ecosystem Play

My Take: This Is Just the Beginning

Further Reading

Questions? Thoughts?

Power Pages Authentication Methods: The Complete Guide (2026)

The Problem With Power Pages Authentication

What I Wish Someone Had Told Me Three Years Ago

Local Authentication: Microsoft Says "Migrate Away From This"

OIDC: The Modern B2C Solution

SAML 2.0: Enterprise-Grade Federation

Social OAuth: Convenience vs. Security

Open Registration: Controlled Onboarding

The Comparison Table You Actually Need

The Real Answer to That Auditor's Question

What I Built

Read the Full Guide

Your Turn

GitHub Agentic Workflows: AI Agents Are Coming for Your Repository Maintenance Tasks (And That's a Good Thing)

Enter GitHub Agentic Workflows

Welcome to "Continuous AI"

Six Core Automation Categories

1. Continuous Triage

2. Continuous Documentation

3. Continuous Code Simplification

4. Continuous Test Improvement

5. Continuous Quality Hygiene

6. Continuous Reporting

How It Works: Architecture and Security

Real-World Applications for Power Platform Developers

PCF Control Repositories

Dataverse Solution Repositories

Power Automate Custom Connectors

Important Caveats You Need to Know

The `allowed-tools` Security Boundary