Oftentimes, PowerApps deployments go hand in hand with an ERP implementation. Clients are enthralled by the flexibility and strength of the PowerApps platform in extending ERP data and want to leverage these capabilities as they are upgrading their ERP software. While this is a great thing, we’ve found that PowerApps projects tend to have the hazard of what we sometimes call “scope creep” – frequently, once we demo the first iteration of an app or show proof of concept work, they often identify or think of additional needs or wants that we did not initially budget for from a scheduling perspective. In the scenario in which an app is a part of a larger ERP implementation, this requires additional forethought during the solution architecture phase of the project to identify what functionality is necessary for deployment, and what functionality is desired but can wait until after the first phase to make sure that our solution is production-ready by the client’s go-live date.
In doing so, “Application Lifecycle Management”, or ALM becomes extremely important – when developing a second phase of the app, bug fixes, or any type of update to the application, maintaining a development environment separate from production becomes vital for several reasons. First, when interacting with a production app, any mistake (which every developer knows there are many while writing new code or developing new applications) would affect the entire user base. Second, even if the original app was cloned into a second, testing your updates would require writing data directly to production and could lead to confusion, bad data, or any number of other issues.
Now that we’ve talked about the importance of ALM for multi-phase PowerApps implementations, we can discuss an issue I ran into on one of my first PowerApps deployments while cloning a production app to my client’s development environment. After exporting the unmanaged solution file to my development environment, I began making changes and received the following error upon saving.
I wasn’t sure what this error meant – some research online didn’t yield any relevant results, and I couldn’t find any app settings that would allow me to select an environment name, even after I looked at the underlying code of the app by saving it to my computer and opening some of the solution files. After spending some time troubleshooting, I realized that despite that the connection to Common Data Model was configured to my account which had access to both environments, the data sources I was connected to needed to be re-added once I moved over because they were still pointed to production. Unlike my experiences in Microsoft Flow, where I could select the environment I wanted to perform CRUD operations on, in PowerApps, it required me to remove and re-add them to ensure that I was connected to the correct environment.
This is an issue that Microsoft seems to want to fix, as shown by the “Current” Common Data Model connector, which connects to whatever the current environment is. I’ve been using this connector more recently, particularly in Flow, but haven’t tested whether the issue I described above still occurs when using this and migrating environments within the same tenant in PowerApps.
Microsoft PowerApps is just one of the many easy to use products in the Power Platform. While designed to make your business easier, getting started might feel overwhelming. At MIBAR, we have the experience and expertise not only in traditional Microsoft business applications, but are also one of the most trusted partners for Power Platform products like Power BI and Flow. Contact us to learn more.
Additional PowerApps Resources
Are You Making the Most of the Power Platform?
