What is an Architectural Decision Record…and why as an Architect you should know about it?
Every architecture is just the sum of its decisions. The schema choices, the environment strategy, the integrations you accepted and the ones you ruled out. Thousands of calls in total — most of them made under pressure, half of them forgotten within six months.
So are you recording yours..?
Some decisions are celebrated, some quietly regretted. The Architecture Decision Record (ADR) is the artefact that turns those calls into institutional memory, not tribal knowledge. In this blog, we’ll unpack what it is, what makes a great one, and how it applies directly to Power Platform. Stick around — there’s a downloadable template at the end.
It is one of the most important deliverables of a solution architect. Without it, future architects — including future-you — are left reverse-engineering logic from artefacts that were never designed to explain themselves.
Each entry captures the context, justifications, and implications of a decision, incorporating requirements and constraints into the documented effects of the decision.
An Architecturally Significant Requirement (ASR) is a requirement that has a measurable effect on the architecture and quality of a software and/or hardware system. An Architectural Decision Record (ADR) captures a single AD and its rationale; Put it simply, ADR can help you understand the reasons for a chosen architectural decision, along with its trade-offs and consequences.
ADR serves as an append-only log
Don’t go back and edit accepted records
preserve the history of your thinking and makes it clear when and why the direction shifted
A record should include consistent elements such as:
Problem statement with context
Options considered
Decision outcome
Include important tradeoffs made with this decision
Record the confidence level of the decision. Sometimes an architecturally significant decision is made with relatively low confidence. Documenting that low confidence status could prove useful for future reconsideration decisions.
Status, such as Proposed, Accepted, or Superseded. Tracking status makes the current state of each decision clear, especially as the number of decisions grows.
Break one decision into multiple if an architectural decision is going to result in multiple phases, such as short-term, mid-term, long-term approaches. Log each phase as its own decision record.
Avoid hiding consequences of decisions intentionally or accidentally.
On Power Platform engagements — where architecture decisions span Dataverse schema design, environment strategy, ALM topology, Copilot Studio integration, and governance — ADRs are especially powerful. The platform evolves rapidly; what was best practice eighteen months ago may be superseded today. A well-maintained ADR log tells the next architect why you chose managed vs. unmanaged layers, why you opted for canvas over model-driven, or why the COE Starter Kit was accepted and later superseded by a custom governance model.
Let’s take an example for Field Service Inspection Platform
Context & problem statement
Field engineers conduct site inspections on tablets in environments with intermittent or zero mobile connectivity. The inspection form requires dynamic section visibility based on asset type (electrical, HVAC, structural), a map-based site locator, and photo capture with annotation. Engineers are non-technical users who need a minimal, task-focused interface. The programme requires the app to go live within 12 weeks.
Architecturally significant requirements driving this decision
Full offline capability with local data sync on reconnection
Custom tablet-optimised layout — two-column with map panel
Native camera access for annotated photo capture
Conditional section visibility driven by asset classification lookup
Hope you got an understanding about ADR…please check out the references further if necessary.
Today in this blog post, lets understand what’s the idea behind creating default environment and what are some best practices managing the default environment. Firstly, let’s understand why Default environment was brought in place.
Why Microsoft Created the Default Environment
1. Frictionless Adoption (The “Land” Strategy) The Default environment meant zero barrier to entry — any licensed user could open Power Apps or Power Automate and start building immediately, with no admin provisioning required. This was critical for competing with other low-code competitors.
2. Consumer-Grade Experience Expectation Early Power Apps was positioned almost like an Office app — something an individual could pick up like Excel. The Default environment mirrored that philosophy: personal, always-there, no setup.
3. Seeding the Platform in Organizations Microsoft’s adoption model has always been land and expand. Let citizen developers build things in the Default environment, create business value, get noticed by IT, then graduate to managed environments. The Default environment was the landing strip.
4. CoE Didn’t Exist Yet When the Default environment was conceived, the governance tooling (CoE Starter Kit, DLP policies, environment strategies) didn’t exist. The assumption was simpler: small platform, small footprint, manageable.
Now that we understood the back ground behind bringing the default environment. Let’s understand few more concepts on how to Manage and govern the default Power Platform environment…
Every employee in an organization that uses the Power Platform has access to the default environment. As a Power Platform admin, you should consider and implement ways to manage the default environment. Your Center of Excellence (CoE) teams can gather information using the PowerShell cmdlets, and Power Platform admin connectors to understand what’s happening in your organization’s environments.
This article also provides some best practices for using the data you gather from these sources to manage your default environment.
Enable managed environments
Maintain robust security and governance by making use of managed environment features in the default environment. Managed environment features provide advanced capabilities, such as monitoring, compliance, and security controls that are important for protecting your data. By enabling this feature, you can configure sharing limits, gain more usage insights, limiting user access to Microsoft Dataverse from only allowed IP locations, and use the actions page to get personalized recommendations to optimize the environment. Evaluate the current managed environments features and stay up to date with the product roadmap to maintain a secure, compliant, and well-governed default environment.
Track connectors
Connectors are Power Platform services that integrate apps and flows with other services. Power Platform administrators can use data policies to control which integrations are permitted in each environment.
Some connectors that drive core Power Platform functionality can’t be blocked. You need to know if these core connectors are being used so that you can provide policy guidance to your makers. For example, you might want to track the apps and flows in the default environment that use the Exchange connector and direct the makers to move to a different environment that allows outbound emails.
The CoE Starter Kit contains schema and flows to report the details of all connectors used by each app or flow in all environments. The data reported in the CoE dashboard is refreshed every 24 hours. You can also search for related flows and apps directly from the Dataverse environment where the CoE Starter Kit is installed. Learn more about tracking connectors with the CoE Power BI dashboard.
Discover unused and owner-less resources
As Power Platform adoption in your organization grows, you’re likely to have owner-less and unused resources in your default environment. When a maker leaves an organization, the maker’s apps and flows are in effect owner-less. Apps and flows that are used for a while and then are no longer needed can clutter the default environment.
To maintain environment hygiene, establish processes and procedures to clean up orphaned and unused flows and apps. These processes are especially important for the default environment, where all users are potential makers.
Use the actions page to view recommendations for apps without valid owners and apps that haven’t been used in the last 60 days. You can take action for each recommendation in the recommendation pane, or you can use the Power Platform for Admin V2 connector to automate tasks.
The default environment is designed for personal productivity, but makers can create apps and flows that become widely adopted or business-critical. This outcome is positive, but it requires management.
Apps that don’t follow a proper application lifecycle management are prone to business continuity risks. Moving high-value apps from the default environment to a Managed Environment lets you use premium security and governance capabilities.
Use the actions page to view recommendations for high-value apps in the default environment. Contact makers and develop a plan to migrate these apps out of the default environment into their own Managed Environment.
When 10 or more employees use a personal productivity app or flow, the Power Platform CoE helps you evaluate whether to move it to its own or a shared environment. The following table describes the parameters to consider. Learn more about developing an environment strategy.
Parameters
Defining criteria
Environment
Number of users
1–10 users
Default
7–30 users
Shared
>30 users
Dedicated
Nature of data
Highly confidential
Dedicated
Confidential
Shared
Not confidential
Default
Monetary or reputational impact
Yes
Shared or Dedicated
No
Default
Requires ALM
Yes
Shared or Dedicated
No
Default
Proactively set sharing limits to control how broadly users can share canvas apps, flows, and agents to avoid over-sharing of resources.
For a reactive approach, use the compliance process in the CoE Starter Kit to track app sharing and usage. Use it as-is or modify it to suit the needs of your organization. Learn more about the app auditing process. This process occurs only after sharing is complete.
Move applications from the default environment
Use solutions to package and deploy your applications, flows, and tables from one environment to another.
Fusion teams can use the following process to package the solution components, deploy it to a target environment, and delete it from the default environment:
Create a solution and add the app and all its dependent apps, flows, and tables.
Export the solution from the default environment and import it in a different environment.
Make sure that all users who had access to the app in the default environment have the right security roles in the target environment. Consider creating and using a dedicated security group to manage them.
Migrate all configuration and app data to the new environment.
Test and validate the app.
Notify users of the new application.
Remove access to the application for all users in the default environment. However, keep access for a few admins and makers.
Eventually, delete the solution and its contents from the default environment. Make sure that you don’t delete any shared assets. For example, if another app or flow uses a table, don’t delete the table.
Quarantine apps
Power Platform admins can quarantine canvas apps. In the default environment, you might want to quarantine an app when:
You want to disable it temporarily while it’s reviewed.
It’s been shared with many users and must be disabled.
It’s being upgraded or moved to a different environment.
Makers can edit a quarantined app, but users can’t play it. Remove the quarantine to restore access for shared users. Only admins can change an app’s quarantine state.
Get quarantine state:Get-AppQuarantineState -EnvironmentName <EnvironmentName> -AppName <AppName>
Back up and restore the default environment
Like every other environment type (sandbox, production, developer), the default environment is archived automatically. However, you can request a restore for the default environment. If you need to restore a backup, contact Microsoft Support. They can restore your environment data to a support environment. Once that restore is complete, you can view and export data as needed. Keep in mind that restoring the default environment might also restore unused or orphaned apps and flows removed during cleanup.
Environment routing is available which allows to streamline your governance strategy for Default Environments.
Hope you have learned something about the default environment.
This blog post is all about performance considerations for your Power Platform CE Projects and how you can plan to optimize application performance for your Power Apps. So I just want to take you through them…
Are you tired of creating solutions for longer durations and while at the end of the project or during UAT you end up facing performance issues for the solutions you have developed, one of the most important non-functional requirements for a project’s success is Performance. Satisfying performance requirements for your users can be a challenge. Poor performance may cause failures in user adoption of the system and lead to project failure, so you might need to be careful for every decision you take while you design your solutions in the below stages.
Let’s talk about them one by one..
1. Network Latency and bandwidth
A main cause of poor performance of Dynamics 365 apps is the latency of the network over which the clients connect to the organization.
Bandwidth is the width or capacity of a specific communications channel.
Latency is the time required for a signal to travel from one point on a network to another and is a fixed cost between two points. And usually many of these “signals” travel for a single request.
Lower latencies (measured in milliseconds) generally provide better levels of performance. Even if the latency of a network connection is low, bandwidth can become a performance degradation factor if there are many resources sharing the network connection, for example, to download large files or send and receive email.
Dynamics 365 apps are designed to work best over networks that have the following elements:
Bandwidth greater than 50 KBps (400 kbps)
Latency under 150 ms
These values are recommendations and don’t guarantee satisfactory performance. The recommended values are based on systems using out-of-the box forms that aren’t customized.
If you significantly customize the out-of-box forms, it is recommend that you test the form response to understand bandwidth needs.
You can use the diagnostics tool to determine the latency and bandwidth:
On your computer or device, start a web browser, and sign in to an organization.
Also, to mitigate higher natural latency for global rollouts, customers should leverage Dynamics 365 Apps successfully by having smart design for their applications.
2.Smart Design for your application
Form design
Keep the number of fields to a minimum. The more fields you have in a form, the more data that needs to be transferred over the internet or intranet to view each record. Think about the interaction the user will have with the form and the amount of data that must be displayed within it.
Avoid including unnecessary JavaScript web resource libraries. The more scripts you add to the form, the more time it will take to download them. Usually, scripts are cached in your browser after they are loaded the first time, but the performance the first time a form is viewed often creates a significant impression.
Avoid loading all scripts in the Onload event. If you have code that only supports OnChange events for fields or the OnSave event, make sure to set the script library with the event handler for those events instead of the OnLoad event. This way loading those libraries can be deferred and increase performance when the form loads.
Use tab events to defer loading web resources. Any code that is required to support web resources or IFRAMEs within collapsed tabs can use event handlers for the TabStateChange event and reduce code that might otherwise have to occur in the OnLoad event.
Set default visibility options. Avoid using form scripts in the OnLoad event that hide form elements. Instead set the default visibility options for form elements that might be hidden to not be visible by default when the form loads. Then, use scripts in the OnLoad event to show those form elements you want to display. If the form elements are never made visible, they should be removed from the form rather than hidden.
Avoid opening a new tab or window and do open the window in the main form dialog.
For Command Bar, keep the number of controls to a minimum. Within the command bar or the ribbon for the form, evaluate what controls are necessary and hide any that you don’t need. Every control that is displayed increases resources that need to be downloaded to the browser. Use asynchronous network requests in Custom Rules When using custom rules that make network requests in Unified Interface, use asynchronous rule evaluation.
Only the columns required for information or action should be included in API calls:
Retrieving all columns (*) creates significant overhead on the database engine when distributed across significant user load. Optimization of call velocity is key to avoid “chatty” forms that unnecessarily make repeated calls for the same information in a single interaction.
You should avoid retrieving all columns in a query result because of the impact on a subsequent update of records. In an update, this will set all field values, even if they are unchanged, and often triggers cascaded updates to child records. Leverage the most efficient connection mechanism (WebAPI vs SDK) and reference this doc site for guidance on the appropriate approach.
You should continue to use the ITracingService.Trace to write to the Plug-in Trace Log table when needed. If your plug-in code uses the ILogger interface and the organization does not have Application Insights integration enabled, nothing will be written. So, it is important to continue to use the ITracingService Trace method in your plug-ins. Plug-in trace logs continue to be an important way to capture data while developing and debugging plug-ins, but they were never intended to provide telemetry data.
For organizations using Application Insights, you should use ILogger because it will allow for telemetry about what happens within a plug-in to be integrated with the larger scope of data captured with the Application Insights integration. The Application Insights integration will tell you when a plug-in executes, how long it takes to run and whether it makes any external http requests. Learn more about tracing in plugins Logging and tracing (Microsoft Dataverse) – Power Apps | Microsoft Learn.
Use Solution Checker to analyze solution components
Best practice is to run Solution Checker for all application code and include it as mandatory step while you design solutions or check when you complete developing your custom logic.
Quick Find
For an optimal search experience for your users consider the next:
All columns you expect to return results in a quick find search need to be included in the view or your results will not load as expected.
It is recommended to not use option sets in quick find columns. Try using the view filtering for these.
Minimize the number of fields used and avoid using composite fields as searchable columns. E.g., use first and last name as searchable vs full name.
Avoid using multiple lines of text fields as search or find columns.
Evaluate Dataverse search vs using leading wildcard search
3. Training
This step should be done during user training or during UAT. To ensure optimal performance of Dynamics 365, ensure that users are properly leveraging browser caching. Without caching, users can experience cold loads which have lower performance than partially (or fully) warm loads.
Train users to not clear the browser cache manually.
Check if devices have enough space allocated for browser cache.
Make sure to train users to:
Use application inline refresh over browser refresh (should not use F5)
Use application inline back button instead browser’s back button.
Avoid InPrivate/Incognito modes in browser which causes cold loads.
Make users aware that running applications which consumes lot of bandwidth (like video streaming) may affect performance.
Do not install browser extensions unless they are necessary (this might be also blocked via policy)
Do use ‘Record Set’ to navigate records quickly without switching from form back to the list.
4. Testing
For business processes where performance is critical or processes having complex customizations with very high volumes, it is strongly recommended to plan for performance testing. Consider reviewing the below technical talk series describing important performance considerations, as well as sharing practical examples of how to set up and execute performance testing, and analyze and mitigate performance issues. Reference: Performance Testing in Microsoft Dynamics 365 TechTalk Series – Microsoft Dynamics Blog
5. Monitoring
You should define a monitoring strategy and might consider using any of the below tools based on your convenience.
Monitor Dynamic 365 connectivity from remote locations continuously using network monitoring tools like Azure Network Performance Monitor or 3rd party tools. These tools help identify any network related problems proactively and drastically reduce troubleshooting time of any potential issue.
Application Insights, a feature of Azure Monitor, is widely used within the enterprise landscape formonitoring and diagnostics. Data that has already been collected from a specific tenant or environment is pushed to your own Application Insights environment. The data is stored in Azure Monitor logs by Application Insights, and visualized in Performance and Failures panels under Investigate on the left pane. The data is exported to your Application Insights environment in the standard schema defined by Application Insights. The support, developer, and admin personas can use this feature to triage and resolve Telemetry events for Microsoft Dataverse – Power Platform | Microsoft Learn
Dataverse and PowerApps analytics in the Power Platform Admin Centre. Through the Plug-in dashboard in the Power Platform Admin Center you can view metrics such as average execution time, failures, most active plug-ins, and more.
Dynamics 365 apps include a basic diagnostic tool that analyzes the client-to-organization connectivity and produces a report.
Monitor is a tool that offers makers the ability to view a stream of events from a user’s session to diagnose and troubleshoot problems. Works both for model driven apps and canvas apps.
I hope this blog post had helped you learn or know something new…thank you for reading…
Hope you’re all doing great and staying safe. This week, let’s dive into a question almost every architect, developer, and Power Platform enthusiast eventually faces when choosing a backend for the implementation—but rarely gets a clear answer to:
“Should I use Dataverse, SQL Server, or PostgreSQL for my next Power Apps solution…?”
With so many platforms claiming speed, scalability, flexibility, and low‑code magic, choosing the right one can feel like navigating a maze. But don’t worry—I’ve broken it all down into a simple, structured guide that can help you guide your implementation choice.
Whether you’re building Power Apps, designing enterprise systems, or architecting cloud‑native solutions, this comparison will help you. You will understand what each platform really offers. You will see how they differ. And—most importantly—which one fits your scenario best.
Let’s jump in and make your next data decision a confident one.
“Firstly, why think of PostgreSQL, in a Microsoft ecosystem
While Power Platform implementations rarely use PostgreSQL directly, it remains one of the most widely adopted enterprise databases. Including it in this comparison helps architects understand how Microsoft’s data platforms stack up against a major industry standard.”
High‑Level Summary
Dataverse is a managed, low‑code data platform built for the Microsoft Power Platform. SQL Server is a commercial, enterprise-grade relational database tightly integrated with the Microsoft ecosystem. PostgreSQL is an open‑source, highly extensible relational database known for standards compliance and advanced features.
What Each One Is
🟦 Microsoft Dataverse
A cloud-based data platform used by Power Apps, Power Automate, Dynamics 365.
Not just a database—includes security, business rules, API layer, auditing, integration, and a managed schema.
Under the hood uses Azure SQL, Cosmos DB, and Azure Blob Storage.
🟥 Microsoft SQL Server
A full-featured relational database management system (RDBMS).
Commercial licensing, strong enterprise tooling, and deep integration with Azure, .NET, Windows Server.
Supports OLTP, analytics, and BI workloads.
🟩 PostgreSQL
A free, open-source RDBMS with strong SQL standards compliance.
Known for extensibility (custom types, functions, extensions like PostGIS).
Competes directly with SQL Server in enterprise features without licensing fees.
Comparison Table
Feature / Aspect
Dataverse
SQL Server
PostgreSQL
Primary Purpose
Low‑code app data platform
Enterprise RDBMS
Open‑source enterprise RDBMS
Best For
Power Platform & Dynamics apps
Enterprise apps, BI, Microsoft stack
Cross‑platform apps, open-source ecosystems
Hosting
Fully managed SaaS
On‑prem, Azure, hybrid
On‑prem, cloud (AWS, Azure, GCP), hybrid
Licensing
Per‑user/app licensing
Commercial licenses
Free (open source)
Extensibility
Limited (managed schema)
High
Very high (extensions, custom types)
APIs
Built‑in REST, OData
Requires custom API layer
Requires custom API layer
Security Model
Row-level, role-based, built-in
Highly configurable
Highly configurable
Performance Control
Limited (managed)
Full control
Full control
Use in Power Platform
Native
Requires connectors
Requires connectors
Key Differences Explained
1. Purpose & Abstraction Level
Dataverse abstracts away database management. You don’t manage tables, indexes, or backups—Microsoft does.
SQL Server and PostgreSQL give you full control over schema, performance tuning, and infrastructure.
2. Integration
Dataverse is the default data layer for Power Apps and Dynamics 365.
SQL Server integrates deeply with Microsoft tools (SSIS, SSRS, Azure Synapse).
PostgreSQL integrates broadly across open-source ecosystems and cloud platforms.
3. Cost Model
Dataverse: Licensing based on Power Platform usage (can get expensive at scale).
SQL Server: Licensing per core or CAL.
PostgreSQL: Free, with optional paid support.
4. Flexibility
Dataverse: Highly opinionated; great for business apps but restrictive for custom architectures.
SQL Server: Flexible but within Microsoft’s ecosystem.
PostgreSQL: Most flexible—extensions, custom data types, procedural languages.
5. Scalability
Dataverse: Scales automatically but within platform limits.
SQL Server: Scales vertically and horizontally (with Always On, sharding patterns).
PostgreSQL: Scales well; many cloud providers offer managed scaling.
When to Use Each
Choose Dataverse if:
You’re building Power Apps, Power Automate, or Dynamics 365 solutions.
You want zero database administration.
You need built‑in security, auditing, business rules, and managed APIs.
Choose SQL Server if:
You’re in a Microsoft-centric enterprise.
You need high-performance OLTP, BI, or analytics.
You want tight integration with Azure and .NET.
Choose PostgreSQL if:
You want open-source, cost-effective, and highly extensible technology.
You need advanced SQL features or geospatial support (PostGIS).
You want cloud portability (AWS, Azure, GCP).
How to Decide Quickly
Check the below…ask yourself…the following questions…
Are you building Power Platform apps? → Use Dataverse.
Are you building enterprise apps in the Microsoft ecosystem? → Use SQL Server.
Do you want open-source, flexible, and cloud-portable? → Use PostgreSQL.
Everyone in their career will reach a point. At this stage, the next step is to raise a Microsoft Support ticket to report any product issue — particularly for Power Apps implementations, as we did recently.
Microsoft Support generally asks to send a HAR File to escalate issues to the Product team. In this blog post today, let’s understand what a HAR File is and why the MS Product team needs it.
A HAR file (HTTP Archive) is a diagnostic capture of everything your browser does during a web session. It includes network calls, payloads, headers, and timings. It also encompasses redirects, failures, and more.
You raise a ticket for Power Apps, Power Automate, or Power BI Service. The product team often needs more than just screenshots. They need detailed information. They can’t reproduce the issue with just images. They need to see exactly what your browser saw.
What a HAR File Includes.. and why Microsoft Product team needs it??
Think of it as a flight recorder for your browser:
Network requests Every API call your browser makes
Failing endpoints or throttling
Ask/response headers Auth tokens, cookies, metadata To check authentication, region routing, tenant context
Payloads JSON bodies sent/received To see malformed data, schema mismatches, or server errors
Timings DNS, SSL, wait time, download time To diagnose latency, timeouts, or CDN issues
Errors 4xx/5xx responses To pinpoint backend failures
This is the only way the engineering team can see the real sequence of events that caused your issue.
Why It’s Critical for Power Platform Issues
Especially in Power Platform, a HAR file helps diagnose:
• Connector calls failing due to throttling • Canvas app load failures • Dataverse API errors • Authentication loops (AAD, MSAL, cookies) • Portal/Power Pages rendering issues • Power BI embedded or service-side failures • Browser-specific regressions • Region misrouting or CDN cache issues
You’ve probably seen cases where the UI shows a generic message like Something went wrong.
The HAR file reveals the actual error behind it.
Is It Safe?
A HAR file can contain sensitive data (tokens, cookies, request bodies). That’s why Microsoft always asks you to:
• Reproduce the issue in a test environment if possible • Scrub sensitive fields if needed • Upload via the secure support portal
Microsoft support uses it only for debugging and deletes it after the case is resolved.
With a HAR file, MS Engineers can:
• Reproduce the issue in their internal environment • Identify whether the problem is client-side, network-side, or server-side • Trace the exact failing API • Confirm whether it’s a regression, configuration issue, or tenant-specific problem • Escalate to the product group with concrete evidence
Now you have understood the purpose of the HAR file, use the below link to generate the same
Model Context Protocol(MCP) has quickly become one of the hottest topics in today’s AI landscape. The excitement around it is huge—not just within the Microsoft ecosystem, but across the entire industry, because it’s designed to be open and accessible to everyone.
Microsoft Power Platform is also moving fast, releasing its own MCPs. I’ve already been asked several times about the difference between them, so this post breaks down how the Dataverse MCP and the Power Apps MCP differ—and when you should use each one.
We know that Dataverse MCP is generally available last year. Now Microsoft announced the public preview of Power Apps MCP this month. So what’s the difference between the two, this post will help to discern the differences between two.
Although both use the Model Context Protocol (MCP), they serve different purposes and operate at different layers of the Power Platform.
Feature
Dataverse MCP
Power Apps MCP
Primary Role
Expose Dataverse as an MCP server so AI agents can query tables, records, and metadata
Allow Power Apps to use MCP to call external AI models or tools
Focus
Data access & operations
AI integration inside apps
Who Uses It
Developers building AI agents or copilots that need Dataverse data
App makers building Power Apps that need AI-driven logic
2. Direction of Integration
Direction
Dataverse MCP
Power Apps MCP
MCP Server
Yes — Dataverse acts as an MCP server
No
MCP Client
No
Yes — Power Apps acts as an MCP client
Meaning
AI tools connect into Dataverse
Power Apps connects out to AI tools
Dataverse MCP: AI → Dataverse Power Apps MCP: Power Apps → AI
3. What You Can Do
Dataverse MCP
Query Dataverse tables
Retrieve records
Update or create data
Use Dataverse as a tool inside Copilot Studio, VS Code GitHub Copilot, Claude Desktop, etc.
Power Apps MCP
Call external AI models from inside a Power App
Build AI-driven app logic
Trigger workflows using AI reasoning
4. Typical Use Cases
Dataverse MCP
Build a Copilot that answers questions using Dataverse data
Let GitHub Copilot query Dataverse while coding
Create AI agents that read/write CRM or ERP data
Power Apps MCP
Add AI reasoning to a canvas or model-driven app
Use external AI models to classify, summarize, or generate content
Build intelligent forms or workflows
5. Relation to Connectors
Dataverse MCP is increasingly seen as a future alternative to connectors for AI-driven scenarios.
Power Apps MCP does not replace connectors — it extends apps with AI capabilities.
Summary
Category
Dataverse MCP
Power Apps MCP
Acts as
MCP Server
MCP Client
Used for
AI agents accessing Dataverse
Power Apps calling AI tools
Primary Benefit
Intelligent, standardized Dataverse access
AI-enhanced app logic
Typical Tools
Copilot Studio, GitHub Copilot, Claude
Canvas apps, model-driven apps
Decision Guide: When to Use Dataverse MCP vs Power Apps MCP
1. If you want AI to access Dataverse → Use Dataverse MCP
Choose Dataverse MCP when:
You’re building a Copilot, AI agent, or LLM-powered tool that needs:
Dataverse tables
Records
Metadata
CRUD operations
You want AI to reason over business data
You want a standardized, connector-free way for AI to talk to Dataverse
You’re integrating Dataverse with:
GitHub Copilot
Copilot Studio
Claude Desktop
Custom LLM agents
Typical scenarios
My AI assistant should answer questions using CRM data.
I want GitHub Copilot to autocomplete code based on Dataverse schema.
I’m building an AI agent that updates Dataverse records.
If the AI is the one doing the work → Dataverse MCP.
2. If you want your Power App to call AI → Use Power Apps MCP
Choose Power Apps MCP when:
You’re building a canvas or model-driven app that needs:
AI reasoning
AI-generated content
AI classification or summarization
You want your app to call:
OpenAI models
Azure AI models
Custom MCP tools
You want AI logic inside the app, not outside it
Typical scenarios
My form should summarize customer notes using AI.
My app should classify images or text using an external model.
I want to call an LLM from a button in a canvas app.
3. If you need both directions → Use both
Some solutions need AI ↔ Dataverse ↔ Power Apps.
Example
A Power App collects data
AI agent (via Dataverse MCP) analyzes historical records
Power App (via Power Apps MCP) calls AI to generate insights for the user
This is becoming a common pattern in enterprise AI.
This is continuation in this series of Dataverse SDK for Python, if you haven’t checked out earlier articles, I would encourage to start from the beginning of this series.
Machine learning often begins with one essential step: data preprocessing. Before models can learn patterns, the raw data must be cleaned, scaled, and transformed into a form suitable for analysis. In this example, let me demonstrate how to retrieve numerical data from Microsoft Dataverse and apply a linear normalization algorithm using Python.
Normalization is a fundamental algorithm in machine learning pipelines. It rescales numeric values into a consistent range—typically between 0 and 1—making them easier for algorithms to interpret and compare.
1. Retrieving Data from Dataverse
Using the DataverseClient and Interactive Browser authentication, we connect to Dataverse and fetch the revenue field from the Account table. This gives us a small dataset to run our algorithm on.
from azure.identity import InteractiveBrowserCredential
from PowerPlatform.Dataverse.client import DataverseClient
This is a classic preprocessing algorithm used in machine learning pipelines before feeding data into models such as regression, clustering, or neural networks.
3. Visualizing the Normalized Output
To better understand the effect of the algorithm, we plot the normalized values:
import matplotlib.pyplot as plt
plt.plot(normalized_revenues, marker='o')
plt.title('Normalized Revenues from Dataverse Accounts')
plt.xlabel('Account Index')
plt.ylabel('Normalized Revenue')
plt.grid()
plt.show()
The visualization highlights how the algorithm compresses the original revenue values into a uniform scale.
4. Why Normalization Matters
Normalization is not just a mathematical trick—it’s a crucial algorithmic step that:
prevents large values from dominating smaller ones
improves convergence in optimization-based models
enhances the stability of distance‑based algorithms
makes datasets comparable across different ranges
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The use of this code is to transform raw Dataverse revenue data into normalized, machine‑learning‑ready values that can be analyzed, compared, and visualized effectively.
You can download the Python Notebook below if you want to work with VS Code
Now in this series, we entered an interesting part where Machine learning algorithms were run to analyze Dataverse Data and in this post we will understand why feature scaling is a critical preprocessing step for many machine learning algorithms because it ensures that all features contribute equally to the model’s outcome, prevents numerical instability, and helps optimization algorithms converge faster to the optimal solution
Primarily before running any Machine Learning Algorithm, we need to do some data preprocessing like scaling the data, in this case we will use a formula which is used to scale using min–max normalization (feature scaling to the [0, 1] range).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As you folks know that Python currently is the number #1 programming language with a massive, versatile ecosystem of libraries for data science, AI, and backend web development. This post kicks off a hands‑on series about working with Microsoft Dataverse using Python. We’ll explore how to use the Dataverse SDK for Python to connect with Dataverse, automate data operations, and integrate Python solutions across the broader Power Platform ecosystem. Whether you’re building data-driven apps, automating workflows, or extending Power Platform capabilities with custom logic, this series will help you get started with practical, real‑world examples.
With the release of the Dataverse SDK for Python, building Python-based logic for the Power Platform has become dramatically simpler. In this post, we’ll walk through how to download Python and set it up in Visual Studio Code so you can start building applications that interact with Dataverse using Python. Sounds exciting already. Let’s dive in and get everything set up..
1. Download and install Python from official website below and then install it in your computer.
Important: During installation, make sure to check “Add Python to PATH”. This ensures VS Code can detect Python automatically.
3. After installation, open VS Code and install the Python extension (Microsoft’s official one). This extension enables IntelliSense, debugging, and running Python script
4. That’s it, you are now able to run Python logic inside Vs Code
5. Create or Open a Python file in the system, opened a sample file below
5. If you want to run Python Programmes in your VS Code, follow below options
a. Select Start Debugging
b. You will be prompted a window like below
You can select the first option highlighted above, it automatically runs your Python Code
This is very easy to setup…
If you want to continue reading this series, check out the next article.
This is in continuation in the Python + Dataverse series, it is worth checking out from the start of this series here.
At times, there will be a need to remove PII(Personally Identifiable Information) present in the Dataverse Environments, for this one time task, you can easily run Python script below, let’s take example of removing PII from Contact fields in the below example.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ECELLORS CRM Blog 