In this blog post, we will learn and explore the unsupported customizations in Microsoft Power Apps / Dynamics 365. Before we begin, ensure you subscribe to CRM Crate to stay updated in the field of Power Platform.

In Power Apps, whether you’re working with Canvas Apps or Model Driven Apps, customization is all about tailoring your applications to suit your specific needs. With Canvas Apps, you have the freedom to design your app’s layout, user interface, and functionality from scratch, using a drag-and-drop interface that doesn’t require coding expertise. This means you can create highly personalized user experiences with custom controls, data connections, and complex business logic. On the other hand, Model Driven Apps offer a more structured approach, where you can customize the app’s behavior by configuring entities, forms, views, and business rules within the Dataverse environment. Whether you’re building a Canvas App or a Model Driven App, the goal is the same: to create powerful, intuitive applications that streamline processes and empower users to achieve their goals efficiently.

What are the known unsupported customizations in Power Apps?

If you make changes to Dataverse without using the methods outlined in Power App Developer Resource or the provided Dataverse tools, those modifications won’t be supported or maintained during future updates or upgrades of Dataverse. Any alterations not covered in the Power App Developer Resourceor supporting materials are considered unsupported. It’s important to note that unsupported changes could lead to issues during updates, such as the addition of hotfixes or service packs, or when upgrading Dataverse.

Below are the known unsupported customizations / modification stated by Microsoft:

1. APIs: Using application programming interfaces (APIs) other than the documented ones such as the Web API, SDK for .NET, Deployment service, Discovery service, and Organization Data service in the web services is not recommended.
2. Plug-ins: Plug-in and workflow assemblies (Class Libraries) should include all required logic within their respective DLL files. While plug-ins may reference certain core .NET assemblies, Microsoft do not endorse dependencies on .NET assemblies that interact with low-level Windows APIs, such as graphics design interface.
   Developing a plug-in assembly for a standard Dataverse assembly (Microsoft.Crm.*.dll) or attempting to update or delete a platform-created plugin assembly is not endorsed.
3. Referencing DLLs / NuGet Packages: Using any Dataverse dynamic-link libraries (DLLs) besides the ones listed below is not recommended.
   A. Microsoft.Crm.Sdk.Proxy.dll
   B. Microsoft.Crm.Outlook.Sdk.dll
   C. Microsoft.Xrm.Sdk.dll
   D. Microsoft.Xrm.Sdk.Data.dll
   E. Microsoft.Xrm.Sdk.Deployment.dll
   F. Microsoft.Xrm.Sdk.Workflow.dll
   G. Microsoft.Xrm.Tooling.Connector.dll
   H. Microsoft.Xrm.Tooling.CrmConnectControl.dll
   I. Microsoft.Xrm.Tooling.PackageDeployment.CrmPackageExtentionBase.dll
   J. Microsoft.Xrm.Tooling.WebResourceUtility.dll
4. Solution Components: Modifying a solutions file to edit solution components other than ribbons, forms, SiteMap, or saved queries is not recommended. Creating new solution components by modifying the solutions file is not endorsed. Similarly, modifying web resource files exported with a solution is not recommended.

• LinkedIn
• Facebook
• Telegram