
1. What's Changed Since This Session
The landscape of the Microsoft Power Platform has evolved significantly since the original session was recorded in early 2024. The following table summarizes the key technological shifts, brand updates, and architectural replacements that define the ecosystem as of April 2026.
| Technology Demonstrated (2024) | Status in April 2026 | What Replaced It / Current Approach |
|---|---|---|
| Power Virtual Agents (PVA) | Replaced / Integrated | Microsoft Copilot Studio. |
| PVA Classic Topic Orchestration | Legacy / Deprecated | Generative Orchestration powered by Large Language Models (LLMs). |
| Power Apps Portals | Rebranded / Upgraded | Microsoft Power Pages. |
| Portals Admin Center | Deprecated (June 2023) | Power Pages Setup Workspace and Power Platform Admin Center. |
| Portals Standard Data Model | Legacy | Enhanced Data Model (solution-aware, virtual tables). |
| Portal Content Editor Tool | Deprecated (June 2026 Removal) | Power Pages Design Studio. |
| Classic Form Designer | Deprecated | Modern App Designer (mandatory for model-driven apps as of April 2026). |
| Classic Theming | Ignored by Modern UI | Fluent 2 Custom Theming via XML web resources. |
| Manual Table Creation | Active | Copilot "Start with data" using natural language prompts. |
| Manual Bot Workflows | Active | Agentic Apps and Autonomous Event Triggers. |
| Per-User Licensing Default | Active | Pay-As-You-Go Azure Meters and Capacity Packs. |
| Azure AD B2C for Portals | Active but Legacy | Entra External ID. |
2. How to Build This Today
The original session demonstrated the assembly of four distinct business applications using the tools available in early 2024. Today, a developer must leverage the April 2026 feature set. This era introduces agentic artificial intelligence, modern designer interfaces, and stricter governance models. The following sections provide an exhaustive, step-by-step methodology for rebuilding these exact scenarios using the current toolset.
Scenario 1: Issue Reporting System in Dataverse for Teams
The session demonstrated an issue reporting system in Dataverse for Teams. The speaker built this using canvas Power Apps (for the app), Dataverse (data), Teams (hosting), Power Virtual Agents (bot), Power Automate flows, and adaptive cards in Teams.
Here is how a developer builds that same thing today in April 2026.
Phase 1: Provisioning the Teams Environment
The foundation remains Microsoft Dataverse for Teams. This platform provides a relational data store scoped strictly to a specific Teams group. It eliminates the need for standalone premium licenses for basic internal applications.
A developer must understand the constraints of this environment. Dataverse for Teams environments are limited to one million rows or 2 gigabytes of storage. Furthermore, there is no direct API access to Dataverse for Teams outside of the Teams client. If standalone Power Apps or Power Automate usage is required later, the environment must be upgraded to a full Dataverse instance.
The developer must first install the Power Apps personal app within the Teams client. Navigating to the Microsoft Teams app store, the developer searches for Power Apps and selects Add. For easier access, the developer can right-click the icon in the Teams app bar and select Pin. Once the app loads, the developer selects the Build tab from the top menu. Selecting Create an app prompts the developer to choose a target Team. Selecting the Team triggers the automatic provisioning of a Dataverse for Teams environment in the background.
Quick Win: Instead of building the canvas app from absolute scratch, the developer can utilize the native "Issue reporting" sample template. Navigating to the Power Apps app in Teams, the developer selects Issue reporting from the available templates. This template automatically provisions the required Dataverse tables, standard user interfaces, and manager dashboards in a matter of seconds, providing a massive head start.
Phase 2: Customizing the Canvas App
With the template installed, the developer must adjust the application to fit the specific organizational workflow. Within the Power Apps Build tab in Teams, the developer selects Installed apps and opens the Issue reporting app. This action launches the Power Apps Studio directly within the Teams client. The interface features a modern command bar at the top of the screen. This dynamic bar provides contextual options based on the selected control, such as font types or alignment settings when a text label is highlighted. The developer selects the Tree view on the left navigation pane to locate the specific reporting screens.
To add custom data fields, the developer navigates to the Data pane. Locating the Issue table, the developer selects Edit data to open the inline Dataverse table editor. The developer can add a new column, such as an Issue Urgency choice column, directly from this interface. Returning to the canvas, the developer inserts a Drop down control from the modern command bar. The developer binds the Items property of this drop-down to the newly created choice column. To save progress, the developer selects the Save icon on the app actions menu, followed by Publish to Teams to make the updates live for the selected Team.
Phase 3: Building the Agent in Copilot Studio
The most significant departure from the original session involves the chatbot. Power Virtual Agents no longer exists as a standalone brand. It is now an integrated capability within Microsoft Copilot Studio.
The architectural shift from the rigid, topic-based decision trees of classic Power Virtual Agents to the dynamic, LLM-driven generative orchestration model of Microsoft Copilot Studio is the most critical learning curve for developers updating 2024 architectures. Generative orchestration replaces static dialogue trees with an LLM-driven planner. This planner autonomously selects the best tools, knowledge sources, and plugins to resolve user queries. Instead of linear, sequential boxes representing hardcoded triggers and actions, the modern architecture features a central LLM hub dynamically connected to satellite capabilities.
The developer navigates to the Teams app store and installs the Microsoft Copilot Studio application. From the Copilot Studio Home page, the developer selects Start now. The developer chooses the identical Team used for the canvas app and selects Continue. The developer names the agent "IT Issue Assistant", selects the primary language, and selects Create.
In 2026, the developer must configure Generative Orchestration to utilize the full capabilities of the platform. Navigating to the agent's Settings, the developer selects Generative AI. The developer ensures the orchestration mode is set to Generative rather than Classic. If an administrator has disabled generative orchestration in the environment, the developer will be forced to use classic, manually authored dialog trees. Assuming generative features are active, the developer provides high-quality metadata and descriptions for the agent's actions instead of building rigid decision trees. The orchestrator uses these descriptions to decide when to trigger specific workflows.
The developer selects Knowledge from the left pane. The developer connects the agent to the organization's SharePoint intranet or specific public URLs. This knowledge integration allows the bot to dynamically answer basic IT queries without requiring any manual scripting or predefined conversational nodes.
Phase 4: Integrating Adaptive Cards via Power Automate
When an issue requires escalation, the agent must trigger a workflow to post an adaptive card to the IT support channel. Within Copilot Studio, the developer selects Topics & Plugins, then adds a new Action. The developer chooses Create a flow, launching the embedded Power Automate interface. The flow is automatically configured with the Copilot Studio (Preview) trigger. The developer adds the Post adaptive card in a chat or channel action from the Microsoft Teams connector. The flow maps the variables captured by the generative agent, such as the issue description and the newly created urgency field, directly into the adaptive card payload. Once saved, the developer returns to Copilot Studio. The generative orchestrator will now autonomously invoke this flow whenever it detects a user intent matching the flow's description, passing the required parameters without needing an explicit trigger phrase. Finally, the developer selects Publish from the navigation menu to deploy the agent to the Team.
Scenario 2: CRM-Like Sales Solution
The session demonstrated a CRM-like sales solution. The speaker built a custom model-driven app on Dataverse with tables, forms, and views for sales pipelines, avoiding full Dynamics 365 licensing. It also covered free Dataverse developer environment setup.
Here is how a developer builds that same thing today in April 2026.
Phase 1: Establishing the Developer Environment
Before architecting the data model, the developer must establish a secure sandbox. The Microsoft Power Platform Developer Plan provides a free, individual environment equipped with a 2 gigabyte Dataverse database and access to premium connectors.
The developer navigates to the official Power Apps Developer Plan website (https://learn.microsoft.com/en-us/power-platform/developer/plan). The developer signs up using a work or school email address backed by Microsoft Entra ID. Personal email accounts are not supported for this plan. Once authenticated, the platform automatically provisions a dedicated developer environment. This environment supports the full application lifecycle management process. However, it is restricted strictly to non-production testing and development. The developer must also be aware that developer environments remaining inactive for 30 days are automatically disabled and eventually deleted. If the automatic creation fails, the developer can manually create the environment through the Power Platform admin center.
Phase 2: Defining the Schema with Copilot
In the past, developers manually created tables, columns, and relationships through a lengthy visual interface. Today, this process is heavily accelerated by natural language processing. The developer signs into the Power Apps maker portal (make.powerapps.com). The developer verifies the new developer environment is selected from the environment picker in the top right corner. From the Home screen, the developer utilizes the Start with data capability powered by Copilot. The developer types a specific prompt into the chat interface: "Create a relational data model for a sales pipeline tracking system. Include a primary table for Accounts with company details, and a related table for Opportunities featuring deal size, probability, and sales stage.".10
Copilot generates the proposed Dataverse schema in real-time. This includes the primary columns and the required one-to-many relationship between the Accounts and Opportunities tables. The developer reviews the AI-generated schema on the screen. The developer selects specific columns to adjust data types, such as ensuring the deal size column is formatted as currency. The developer can also select Advanced Options to configure the schema name, modify the table ownership from User/Team to Organization, and enable auditing. Once satisfied with the structure, the developer selects Create app.
Phase 3: Assembling the Model-Driven App
The Copilot action automatically generates a foundational model-driven app, but the developer must refine the user interface and secure the components. Navigating to Solutions on the left navigation pane, the developer creates a new solution to ensure proper dependency tracking. The developer names the solution "Custom Sales CRM", assigns a dedicated publisher to manage prefixes, and selects Create. Inside the empty solution, the developer selects Add existing > App and imports the AI-generated model-driven app. The developer also selects Add existing > Table to bring in the Account and Opportunity tables.
Opening the app launches the Modern App Designer. The classic form designer has been entirely deprecated and is no longer accessible as of April 2026.8 To organize the application, the developer selects the Navigation pane. The developer adds new groups and areas, naming them "Sales Execution" and "Customer Management".10 The developer adds Dataverse tables as pages within these navigation groups, ensuring users can easily access the Account and Opportunity views.
Quick Win: The modern Unified Interface requires modern theming. The developer should immediately abandon any classic UI themes. Applying a cohesive corporate color scheme across the entire app is now done by creating an XML web resource using the Microsoft Fluent 2 design system. This XML file is then applied via the Custom theme definition app setting, instantly styling headers, hyperlinks, and hover effects across the entire application.
Phase 4: Configuring Business Logic and Pipelines
To enforce sales methodologies, the developer implements Business Process Flows. From the solution view, the developer selects New > Automation > Process > Business Process Flow. The process is bound to the Opportunity table. The developer defines specific stages within the visual designer: Qualify, Develop, Propose, and Close. Each stage is configured with required data steps. This ensures sales representatives capture critical information, such as budget amounts or decision-maker contacts, before advancing a deal to the next phase.
Furthermore, the developer enables AI-generated descriptions for the application. By navigating to the app's Settings > General, the developer selects the Create descriptions using AI button under the Description field. This utilizes the Azure OpenAI Service to analyze the app's metadata and generate a concise summary for end-users. This feature requires the environment to be configured as a Managed Environment by the tenant administrator. Finally, the developer selects Save on the command bar, followed by Publish to make the CRM solution active for testing.
Scenario 3: Customer and Partner Portals
The session demonstrated customer and partner portals. The speaker demonstrated Power Apps Portals linked to Dataverse for external access.
Here is how a developer builds that same thing today in April 2026.
Phase 1: Provisioning the Power Pages Site
This product has been entirely overhauled and rebranded as Microsoft Power Pages. The legacy Power Apps portals admin center was retired in June 2023, and the legacy portal content editor tool is scheduled for complete removal by June 2026.4
The developer begins in the dedicated Power Pages maker portal (make.powerpages.microsoft.com). Selecting Create a site launches the modern site creation wizard. The developer selects a blank template or an industry-specific starter template. Crucially, as of 2026, all new sites utilize the Enhanced Data Model by default. This modernized framework relies on a combination of system tables, nonconfiguration tables, and virtual tables rather than the standard custom tables used in the past. The Enhanced Data Model drastically accelerates site provisioning times and allows website configurations to be contained within standard Dataverse solutions, streamlining the application lifecycle management process. When the site is created, it is set to Private by default. This security measure requires Microsoft Entra authentication to view even partially developed content, preventing accidental data leaks.
Phase 2: Designing the Interface and Data Integration
The developer utilizes the Power Pages design studio, which offers distinct workspaces for Pages, Styling, Data, and Setup. In the Data workspace, the developer connects the site to the Dataverse tables created during the CRM scenario, specifically the Account table. The developer must configure Table Permissions to ensure external users can only view records associated with their specific profile. This involves defining web roles and associating them with specific contact records. Moving to the Pages workspace, the developer creates a new page titled "Partner Dashboard".34 A List component is added to the page and bound to the Account table. This component displays the filtered data securely to the authenticated external user.
Phase 3: Configuring External Authentication
External users should not use internal organizational credentials to access the portal. The developer must configure an external identity provider. The developer navigates to the Setup workspace and selects Identity providers.

While Azure AD B2C was the historical standard, Microsoft now highly recommends Entra External ID for modernized, integrated external identity management. The developer selects the Entra External ID provider option from the list. The developer configures the OpenID Connect protocol settings. This requires inputting the Client ID and Issuer URI obtained from the Azure portal after registering the application. To enable secure API authorization, the developer opens the Portal Management app and creates specific site settings. The developer sets Authentication/BearerAuthentication/Enabled to True and Authentication/BearerAuthentication/Provider to the newly configured external identity provider.
Phase 4: Integrating the Agent API and Analytics
To elevate the partner experience, the developer infuses intelligent experiences using the Agent API. Still within the Setup workspace, the developer adds an AI-powered agent created in Microsoft Copilot Studio. The developer selects the specific Copilot Studio agent from the environment list. Agents created directly from Power Pages automatically become aware of the site context. They respect assigned web roles and utilize Generic OAuth 2 authentication with a token pass-through method. The new Agent API allows the developer to seamlessly integrate this Copilot Studio agent into custom React, Angular, or Vue single-page applications hosted on the portal. This provides conversational support securely grounded in Dataverse knowledge.
Quick Win: The developer should immediately configure site analytics and server logging within the Setup workspace. This 2026 feature integrates Application Insights via a simple provider script. It tracks page views, form interactions, and session details using client-side analytics, moving IT teams from reactive troubleshooting to proactive monitoring of portal traffic.
Scenario 4: Financial Forecasting App
The session demonstrated a financial forecasting app. The speaker extended Dynamics 365 Sales using canvas Power Apps embedded within a model-driven form.
Here is how a developer builds that same thing today in April 2026.
Phase 1: Designing the Canvas App
While Dynamics 365 offers native AI forecasting capabilities, organizations frequently need to embed custom canvas apps to handle highly specific, proprietary financial logic or custom data sources. The process of embedding these applications has been modernized within the Unified Interface.
The developer must first build the standalone forecasting calculator. Navigating to the Power Apps Studio, the developer creates a new Canvas app. The developer formats the app for a custom tablet layout to ensure it renders cleanly within the model-driven interface. The app connects directly to the Dataverse environment containing the Dynamics 365 Sales data. The developer utilizes a specific control named ModelDrivenFormIntegration. This vital control allows the embedded canvas app to receive contextual data passed dynamically from the host model-driven form. The app is configured to pull the current Account ID from the integration control. It then queries Dataverse for associated historical revenue records to populate the internal forecasting charts. Once the visual layout and data logic are validated, the app is saved and published.
Phase 2: Preparing the Model-Driven Form
The developer must integrate this newly published canvas app into the Dynamics 365 Sales interface. Navigating back to the Solutions area in the maker portal, the developer opens the solution containing the Dynamics 365 Account table. The developer selects Forms and opens the primary Account Main Form. Crucially, the developer must use the Modern App Designer. The classic form designer, previously accessed via a "Switch to classic" button, is no longer the supported path for this configuration.
Phase 3: Embedding the Component
Within the modern form designer, the developer selects the specific layout section where the forecasting tool should reside. To avoid cluttering the primary summary view, the developer selects Add page and creates a dedicated New Tab labeled "Financial Forecast".9 The developer must add a required Dataverse column, such as Account Name, to this new section. This column serves as the necessary anchor for the canvas app component. With the anchor column selected, the developer navigates to the left-hand navigation pane and selects Components. Expanding the Display section, the developer selects the Canvas app control.
Phase 4: Configuring Parameters and Publishing
The properties pane for the Canvas app control appears on the right side of the screen. The developer must provide the App ID. This is a unique GUID found in the canvas app's details page. Alternatively, the developer can select the app directly from the populated environment list. The developer configures the control properties to pass the Record ID as a dynamic parameter to the canvas app. To ensure a clean, professional user interface, the developer clears the Display label on the form checkbox. This prevents the anchor column's name from interfering with the canvas app's design. If another canvas app is already embedded on the form, the developer will receive a warning message stating that only one canvas app can be enabled per form. The developer must disable the older app first. Finally, the developer selects Done, saves the form layout, and clicks Publish. When a sales representative opens an Account record in Dynamics 365, the custom forecasting canvas app renders natively within the tab, dynamically updating based on the specific account being viewed.
Quick Win: For full-page, immersive experiences that do not require tying to a specific Dataverse record, the developer can leverage Custom Pages. Introduced in the modern designer, custom pages allow developers to build canvas experiences that sit alongside standard model-driven views in the primary left-hand navigation menu. This offers a more cohesive application architecture than traditional embedded forms.
3. Licensing Quick Reference
Deploying these four applications in a production environment requires strict adherence to the Microsoft Power Platform licensing model. As of April 2026, the licensing structure relies heavily on specific capacity packs, Azure meters, and tiered user models.
The following table details the necessary licenses, billing metrics, and pricing (listed in USD and GBP) required to sustain the architectures recommended in this report. Pricing excludes VAT and represents annual commitment rates where applicable.
| Product & License Type | Applicable Scenario | Pricing (April 2026) | Billing Metric & Capacity Notes |
|---|---|---|---|
| Power Apps Premium | Scenario 2 (Custom CRM) Scenario 4 (Embedded Canvas) | $20/user/month (£15.40/user/month UK) 45 | Required for unlimited applications utilizing premium Dataverse connectors. Accrues 250 MB Dataverse database capacity per user. |
| Power Apps Premium (Volume) | Enterprise Deployments | $12/user/month (£9.20/user/month UK) 45 | Discounted tier requiring a minimum commitment of 2,000 newly assigned premium seats. |
| Power Pages Authenticated | Scenario 3 (Partner Portals) | $200 per pack/month (£153.80 per pack/month UK) 38 | Sold in capacity packs of 100 authenticated unique users per site, per month. Tiered volume discounts available. |
| Power Pages Anonymous | Scenario 3 (Public Knowledgebases) | $75 per pack/month 38 | Sold in capacity packs of 500 anonymous unique users per site, per month. |
| Power Pages Pay-As-You-Go | Scenario 3 (Variable Traffic Sites) | $4.00 per Auth User $0.30 per Anon User 14 | Billed via Azure subscription per active user, per website, per month. Avoids upfront capacity commitments. |
| Copilot Studio License | Scenario 1 (Teams Issue Bot) | $150 per bot/month (£153.80/month UK) 45 | Provides 25,000 "Copilot Credits" per month. Credits are decremented based on generative task complexity. |
| Copilot Studio Pay-As-You-Go | Scenario 1 (Low-volume Bots) | $0.01 per Copilot Credit 50 | Billed via Azure meter. Eliminates up-front commitments for highly variable generative workloads. |
| Microsoft 365 Copilot Business | Broad Copilot Studio Access | £13.80/user/month UK 51 | Usage of Copilot Studio agents is included within the M365 Copilot USL for internal scenarios without requiring additional credits. |
| Dataverse for Teams | Scenario 1 (Teams Environments) | Included with Microsoft 365 16 | Free structural database. Maximum of 2 GB per Teams environment. Does not permit standalone API access outside of the Teams client. |
Organizations must monitor their Dataverse consumption closely. Environments configured for Pay-As-You-Go billing receive a one-time entitlement of 1 gigabyte of Dataverse Database capacity and 1 gigabyte of File capacity. Additional Dataverse Database storage can be purchased via capacity add-ons if the standard accruals are exceeded during the application lifecycle.