Matt LaCasse

Adventures in Power Platform

Category: Power Apps

  • Power Apps SharePoint Series

    Over the years, I have spent a lot of time integrating SharePoint into Power Apps. Getting the basic setup complete is fairly straightforward, but going with the Out of Box options leaves a lot to be desired.

    Leveraging some hard-earned lessons from different implementations, I wanted to put all of that knowledge together so that if you are at the beginning of your SharePoint integration journey, that this can serve as a good step-by-step guide across the various intersects between Power Apps and SharePoint.

    “Integrate SharePoint with Power Apps” doesn’t mean one thing. There are nuances between model-driven apps, Power Pages, Canvas Apps or Power Automate Flows. The steps are scattered across a dozen docs pages, and the gotchas usually aren’t written down anywhere until you trip over them. So I figured I’d put it all in one place.

    Why SharePoint instead of just Dataverse

    Cost

    SharePoint storage is cheap, and Dataverse capacity is not (to be fair, Microsoft has steadily bumped up the default capacity included with most licenses over the years, so there’s more headroom than there used to be, but it still fills up faster than you’d think).

    Pushing your documents to SharePoint keeps your premium capacity for the data that actually needs to be there.

    User Experience

    Your users likely already know SharePoint. And just because your files are in a Power Apps context, it doesn’t mean that you don’t need things like co-authoring and version history. Additionally, files are reachable outside the app to users who may not have a Power Apps or Dynamics 365 license. Lastly, it is an out of the box integration.

    That being said, SharePoint integration is not without trade-offs. Permissions get more interesting, and each product has its own quirks, but those are exactly the things this series is going to dig into.

    What this series covers

    Because “SharePoint integration” looks different in each corner of the platform, one post was never going to cut it. Here’s the roadmap. I’ll link each one up as it goes live:

    • Model-Driven Apps: turning on the built-in document management experience and what it gives you.
    • Power Pages: surfacing SharePoint documents to external, portal-facing users.
    • Power Automate: handling files with flows when you want full control over what happens and when.
    • Canvas Apps: connecting to SharePoint and building your own file experience.
    • Advanced, multiple SharePoint sites: pointing one model-driven app at more than one site.
    • Advanced, custom folder structures: taking control of how folders get named and organized.
    • Advanced, syncing permissions: keeping access in Power Apps and SharePoint in step with each other.

    What you’ll need to follow along

    I’m going to assume you’re already comfortable poking around the Power Platform. To actually try any of this, you’ll want a SharePoint site to point at and enough admin rights in your environment to flip the integration on. Nothing exotic, but worth having ready before you dive into the hands-on posts.

    Let’s get into it

    First up is the one most people meet first: document management in a model-driven app. See you in the next post.

  • Works in DEV but not in TEST? Check the Unmanaged layer!

    Introduction

    As a Power Platform developer, there’s nothing more frustrating than deploying a solution to a new environment, only to find that it doesn’t work as expected. You’ve tested it thoroughly in your development environment, and everything works perfectly. But in the new environment, it’s broken. What’s going on?

    More often than not, the answer lies in the unmanaged layer.

    Unmanaged layers can cause problems when you’re moving solutions between environments. If you have unmanaged changes for components in your target environment, and you import a solution with those same components in a managed solution. your app will not show the configuration for the components from the managed solution because component changes at the unmanaged layer veto the configuration at the managed layer.

    Even with robust DevOps procedures, unmanaged configurations can still pop up due to user error, inheriting a solution before robust controls were in place, etc.

    TLDR: How to remove unmanaged changes

    In your solution, find the misbehaving component, and click Advanced -> See Solution Layers

    If there is an unmanaged layer, it will appear in the next window.

    If you click on the layer, it will show you what has changed for that component in the unmanaged layer.

    To remove the unmanaged customizations, simply click the Remove active customizations buttons.

    Deep Dive – What are the Managed and Unmanaged Layers?

    To illustrate this concept, let’s suspend everything we know about the Power Platform, and let’s pretend that the only type of component available is a rectangle component.

    Let’s also pretend that the only attribute available for the component is a colour. Not very practical for apps, but very practical for demonstrating layers.

    One managed solution in an environment

    In the illustration above we have a Managed solution that has been in our environment. Inside of the managed solution there are three components.

    As this is the only solution in this environment, you can see in the App presentation that the three components are green. So what happens when we start adding more solutions to this environment?

    Adding another managed solution

    Let’s see what happens when we add a second managed solution

    A second managed solution

    We can see the the second managed solution was added containing another copy of Component 1 with a different color attribute. And in the App Presentation, we can see that the color has changed to orange.

    This teaches us a few key points about Managed solutions and Managed layers.

    • The way the power platform decides which component configuration to use is literally whichever one is at the top.
    • Solution layers are ordered by the import order of the solutions themselves.

    And there are some not so obvious points

    • Once a solution layer is created, it does not move.
    • If you were to make a change to Component 1 in Managed Solution 1 and re-import it, because of the presence of configuration of that component in a higher level, the changes in Managed solution 1 will not be seen by the user.
    • The only way to have the configuration in Managed Solution 1 to become what is presented in the App, is to delete Managed Solution 2. Removing a managed solution also removes the associated managed layer.

    This behavior will continue on and on with each new managed solution added to the environment. Configurations add up and the behavior of the app changes based on which one is on top.

    Introducing the Unmanaged Layer

    In this diagram we’ve introduced an unmanaged solution with configuration for some of our components. The Power Platform rules for taking the top most layer still apply here. And as you’ll note, the unmanaged layer is always above the managed layers. This tells us that configuration in the unmanaged layer will always override changes in any managed layer.

    Introducing an unmanaged solution

    The other important thing to note here is that where bringing in a managed solution, the system will create an independent layer containing a copy of the solution’s configuration, when you import an unmanaged solution, the platform just kind of dumps the components into the unmanaged layer. Instead of ownership over the components, you instead get a reference to the solution component in the unmanaged layer. The solution just points to that component.

    This tells us that when we export our unmanaged solution, the system takes a Snapshot of the component’s configuration from the unmanaged layer and exports that.

    What happens when you import another unmanaged solution?

    As components are only referenced in the unmanaged layer, when you add a new unmanaged solution that contains components that also exist in other unmanaged solutions, the newly imported solution configuration will overwrite the config in the unmanaged layer.

    In addition, all unmanaged solutions that reference that component will automatically be updated.

    Deleting unmanaged solutions

    When you delete an unmanaged solution, the configuration remains in the unmanaged layer as it was only ever referenced in an unmanaged solution.

    The unmanaged solutions are deleted but the configuration remains.

    Deleting Managed Solutions

    If you delete a managed solution, the configuration goes with it, and the principal of highest layer wins will apply.

    Conclusion

    Unmanaged layers can be a major source of frustration for Power Platform developers. But if you understand how they work, and know how to identify and remove them, you can save yourself a lot of time and headache.

  • Power Tip: Quickly check Power Automate Licensing Compliance with PowerShell

    In this tip, let’s make sure that your mission critical flows are not in danger of being suspended due to licensing non-compliance.

    TLDR: Quick Steps

    Overview

    The PowerApps Administration PowerShell module includes a handy little tool to ensure your Power Automate flows are in compliance with licensing requirements. When run, the command will indicate any flows that meet the following non-compliance scenarios:

    • Premium flows are being used without a Premium license assigned to the flow owner.
    • Premium flows created by Power Apps premium and Dynamics 365 licensed users must be in context of the Power App/Dynamics365 application.
    • Premium flows are owned by Application user(SPN) but do not have appropriate license

    Detailed Steps

    Install the Power Apps Administration PowerShell Module

    Open a PowerShell window as administrator, and install the module:

    Install-Module -Name Microsoft.PowerApps.Administration.PowerShell

    Run the Get-AdminFlowAtRiskOfSuspension command

    After the Power Apps Administration PowerShell module is installed, run the following command:

    Get-AdminFlowAtRiskOfSuspension -EnvironmentName <your environment guid>

    Once run, if any flows are out of compliance, they will be displayed with the appropriate non-compliance reason.

  • Power Apps Solutions, the Recycle Bin Feature, and bad timing.

    Power Apps Solutions, the Recycle Bin Feature, and bad timing.

    Sometimes you find yourself in the wrong place at the wrong time. No, this was not rain at a picnic, but rather an unfortunate intersection of the early days of a preview feature and full steam ahead development.

    In reality, the following may only help a small percentage of folks, who through bad timing and luck, find themselves in a similar situation. But when there are zero Google results for the error message, it’s probably worth writing about.

    The Recycle Bin

    The Recycle Bin is a great new feature of Power Platform that will undoubtedly help roll back some accidental deletion of records.

    (More info on the Recycle Bin feature: https://learn.microsoft.com/en-us/power-platform/admin/restore-deleted-table-records)

    Still in preview, this feature seems to be enabled in many environments. Supporting this new feature are a couple of components. One is a new table (Deleted Record Reference), and 1:N relationships on all tables where the feature is enabled(xyx_tablename_DeletedItemReferences).

    The problem

    As of the time of writing, when enabling the recycle bin on a new or existing table, 1:N relationships are added between the new table and the Deleted Record Reference table. Those relationships live in a managed layer, in a solution called Basic.

    Screenshot of the solution layers for the xyz_tablename_DeletedItemReference relationship as of December 10, 2024.

    However, nearer the beginning of the preview window, there is evidence in some environments that the relationships were instead added to the unmanaged layer. In our case, they were also added to our unmanaged solution. The mechanism by which they were added to the solution, in our case, is up for debate. My best theory is that it was added because we had Include All Assets selected for our table in the solution. But I cannot discredit the possibility that it may have been added manually, be it accidentally or on purpose. Ultimately, it doesn’t matter.

    The unmanaged solution with this relationship was exported as managed and brought into a new environment.

    The problem surfaced when trying to do a managed solution deployment with the relationship removed. On deployment, we were presented with the following error message:

    Entity Relationship: xyx_tablename_DeletedItemReferences Cannot be deleted since it is not a custom entity relationship

    As previously mentioned, our managed solution had the relationship between one of our tables and the Deleted Record Reference.

    Somehow, for one of our tables, this became the only reference for this relationship in the target environment. The “Basic” layer mentioned above does not exist in the target environment. So here is the conundrum – how do you remove a relationship from a solution in which it does not belong, but where the “proper” layer does not exist?

    Resolution

    When all else fails, turn it off, and turn it back on again

    There were a lot of failed attempts to resolve the issue, but ultimately, the resolution was quite simple. If you turn off the Recycle Bin feature in the environment, and let the background processes do what they have to do to to disable the feature (give it like 20 minutes), you can then update your solutions which no longer contain the relationship, and the relationship will be removed from the managed layers.