SharePoint
Power Apps vs. SharePoint Framework for Forms
06.02.20
Overview
As the capabilities in the Microsoft Power Platform have matured over the last couple of years, Thrive has spent considerable time delivering business process automation solutions using the tools in the platform. With Power Apps, Power Automate, and Power BI, the platform allows us to accelerate the digital transformation process for our customers using the low-code capabilities in the platform. However, when requirements get complicated, a better approach may be to build your form using the SharePoint Framework (SPFx). This is especially true if you are dealing with large amounts of data, fast load time of the form is critical, or the UI requirements are complicated. Using SPFx does require development experience, but with the right skills, you can quickly build out custom forms that can provide a better solution.
The table below provides a detailed comparison of building your form in Power Apps versus using the SharePoint framework. We have also provided a summary of our findings at the end of this post.
Detailed Comparison
| Power Apps | SharePoint Framework | |
List Thresholds |
Currently, when a list has threshold problems, there is no way to easily work around them in Power Apps. The Power Apps will immediately break if already published and will not allow you to publish or save it. All submissions will break. | Structuring the data or applying filters makes it easy to work around List Thresholds and retain functionality. |
Performance |
Even with small-scale forms and applications, the load times for Power Apps can be relatively lengthy. | Performance is exponentially better than Power Apps. Small or large applications will load quickly and navigation in large applications is also extremely fast. |
Simple Forms/Applications |
For forms that we just want to add a couple of easy conditionals, set up some formatting or styling, and so forth, Power Apps is probably the way to go. It requires little to no development knowledge and allows for further customizations by Power users. | For simple forms or applications, we may want to stray away from an SPFx solution. The development overhead and time spent would most likely outweigh the benefits. |
Large Forms/Applications |
Power Apps can get very bogged down by large applications that contain paged navigation, a lot of conditions, several lookups, etc. Maintaining connections between pages, altering conditions, implementing validation, etc. becomes very difficult. | Large forms and applications can be constructed to be exactly what meets the needs of the business. Inline field validation, paged navigation, conditions, etc. can all be implemented with ease. Performance is also fantastic in any SPFx application. |
Dev, Test, Prod |
Power Apps becomes tricky if you want to try to have a development stream. If you have a Power App that is integrated with a SharePoint list or library, it cannot be exported or migrated anywhere else. You would need to continuously rebuild the app from scratch and reconnect all data connections for this work. Canvas apps do allow for exports, but the amount of configuration required for each installation can be painstaking. | Seeing as SPFx solutions are packages, they can be deployed at a tenant wide level or per site collection. This means you can easily spin up a development, test, and prod site collection and have a development stream that can publish updates to any one of these environments with ease without affecting anything you don’t want. Pipelines can be established to further simplify the development stream. |
Migration |
As stated in the previous point, migration can be very difficult or even impossible with Power Apps. | Given the nature of SPFx solutions, migrations can happen with little to no effort moving between site collections, environment, and tenants. |
Validation/Conditionals |
Conditional and validation logic is certainly possible in Power Apps, but only to an extent. Certain fields do not have the innate ability to filter out things such as special characters and implementing logic to do so is tricky. In some cases, the logic may not even have the ability to be implemented. Conditionals are also implementable, but take time and can be very reliant on form loading factors. Rules were removed so there is no central location to manage all of your logic. | Literally any form of conditional or validation is possible in SPFx. Real-time/async validation is implementable. Regex, string validation, number validation, etc. is all easily implementable and scalable. Conditional logic can easily hot-swap visible components to the user. |
Data Connections |
While data connections to other applications in Office 365 are easy enough to set up, they cause some unintended side effects that may result in an undesirable user interface. For example, if you wanted to pre-populate a Manager field in Power Apps, you can do this by adding the Office 365 Users data connection. However, when you add this data connection, it will prompt the user to allow access to this when they load the Power App. This will occur each time they load it if their cache has been cleared and in other instances as well. | While data connections require a bit more set up in SPFx, they can be tailored to do exactly what you need them to do. The sign-in prompt that was mentioned in the Power Apps version of this functionality is no longer an issue. Data connections will migrate with the application should you decide to move it. By default, connections to Teams, Graph, SharePoint, and more are relatively preconfigured for you when creating an application in SPFx. |
Redirects |
Currently, redirecting applications on submission is not possible from Power Apps. This can cause a lot of headaches, particularly in SharePoint integrated Power Apps. | Redirects are completely possible in all manners within SPFx. |
SQL Connections |
Connections to SQL databases are available from in Power Apps. Depending on what needs to be done with them, you may or may not want to use SPFx (driven by the complexity of the app). | SQL connections are also easily implementable in SPFx. They can integrate with non-standard SQL connections such as Azure Cosmos DB, AWS, Firebase, NoSQL DBs, etc. |
Customizations |
Depending on what needs to be customized, you may or may not be able to complete the task in Power Apps. While they give you a wide range of customization options in Power Apps, you will still encounter some limitations in terms of styling, sizing, resolution, etc. | There are essentially no limits to the customizations you can do in SPFx. |
Responsiveness |
While Power Apps can and will work across platforms, it still has a wide range of issues with responsiveness across browser sides. One area of note is when using People Pickers, Date Picks, and Multiple-Choice fields. These components will often be inoperable on smaller devices. In addition, embedded Power Apps will often have scrolling issues where a user cannot scroll to the very bottom of the app on smaller devices. This is currently a known issue. | SPFx applications can be made to be 100% responsive across devices. In addition, SPFx grants the ability to design per device or screen size. For example, you could create a design for phones, a design for tablets, and a design for PCs all in one application. |
Data Load |
Data loading can be tricky in Power Apps. If you are trying to execute actions based on pre-loaded data, there is not much in terms of something asynchronous that will await the response. Many different issues can come up in things like conditions based on pre-loaded information as the information is not ready to be consumed. | Data loading is no issue. Async/Await functionality is easily implementable to ensure that you have the information you need when you need it. |
Summary
Use Power Apps if…
- You do not require storing more than 5,000 records
- The speed of the forms is not a significant consideration
- Your forms are relatively basic, without complex repeating sections or business logic
- You do not need to promote the forms through Development, Test, and Production environments
- You do not have complex conditional or validation logic
- Your forms do not need to redirect to a custom location upon completion
- Responsive design across numerous browser configurations is not critical
- You have power users who can maintain and modify basic forms and functionality
Use SharePoint Framework if…
- You need to store larger amounts of data
- Fast form load and navigation time is critical
- There is complex logic and/or UI design involved
- You need to support a full Software Development Lifecycle or migrate the form to various locations
- You want complete control over the responsive design to support various browser configurations
- Having seamless integration into Teams and/or SharePoint is important