By Ben Weeks
We love PowerApps. We use it both internally and externally for our clients. It enables fast development without the use of full traditional pure “development” tools and skills. This allows for the potential to deliver solutions quicker than traditional pure development projects. However, that’s not to say it’s always the most appropriate technology for a project. From the large number of projects that we have now used PowerApps for, we have drawn up a loose set of rules we use at Cielo Costa when considering the use of PowerApps. Therefore, here are our 5 “golden” rules of when NOT to use PowerApps:
In a little more detail, the rules are as follows:
> 2000 items
If there are likely going to be more than 2000 items that you need to display within the app then consider the use of a different solution. PowerApps allows for the delegation of queries for larger datasets, however, these can be difficult, limiting, and the documentation is lacking (in particular with regards to limitations to SharePoint).
Proceed with caution if there are more than say 50 questions as this can be difficult to maintain (such as the positions of these questions).
More than 5 screens
Proceed with caution if there are going to be more than 5 screens as this can be difficult to maintain (you will end up with repeat logic in the various screens). It can become tricky to maintain a consistent navigation, aligned, and look and feel across multiple screens.
Keep the forms simple. Advanced logic can be difficult to maintain and debug. There are also no easily re-usable functions. You may find with complex apps that as you fix one issue, you create another. Dealing with permissions (e.g. enabling or disabling buttons for users) can be tricky. In addition, it’s not so easy searching and navigating through the app to find the area that needs to be amended. Lastly, the editing experience compared to your usual tools such as say Visual Studio Code can be frustrating.
Application Lifecycle Management (ALM) required
PowerApps is a power users tool. That is, they can be built by technically savy users who aren’t necessarily developers. This allows for solutions to be built quickly for the business. However, it does have some limitations if you want to integrate this into the Application Lifecycle Management of a Solution. For example, trying to integrate PowerApps into your release pipelines can be difficult (not all steps can be automated and connections need to be repaired making it time consuming to do a release). This process may not also be compatible with your power users (as a very development orientated process) and make supporting it slower and more difficult.
At Cielo Costa, PowerApps forms part of our solution, but we don’t as a general rule build all-inclusive “super PowerApps” that contain the whole solution, rather it forms a value part of the whole, where we often also make use of Microsoft Teams, Flow, Power BI and SharePoint Framework development. In addition, this will often mean we break down a PowerApp into small components.
It should be noted that PowerApps is a fast moving development, and I wouldn’t be surprised if these rules will need to be addressed again in the next 6-months (so take the “Golden” with a pinch of salt!).
I would be interested to here if you are also using PowerApps, and what you deem as the point at which you look at perhaps more traditional or other development platforms.