When Microsoft first launched Power Apps and Power Automate, these apps were positioned to replace legacy SharePoint on-premises functionality such as InfoPath forms and SharePoint Designer workflows. Just like the tools it was replacing, Power Apps was targeted towards the savvier power user who could easily spin up an app, link it to a SharePoint list, use Excel-like coding to make some tweaks, and within days or weeks have something to solve a specific business need.
That is the beauty of Power Apps. It lets people take ownership of their solutions and have the skills within their departments to maintain the application. Authentication and permissions are based on the user’s credentials, the distribution model is easy, and the app itself can be accessed via a mobile device (or even embedded in a SharePoint page) within the context of daily work.
Department-specific apps like Engineering Change Notifications (ECNs) and Approvals are great use cases. Even enterprise-wide solutions like a Return-to-Work app or an Employee Directory can be easily be solved with Power Apps.
But at what point is the business need and corresponding technical solution too complex for Power Apps?
We usually know it when we hear it. There are tell-tale signs that a custom application may be better suited for a particular business scenario than a Power App. Here are some examples when a custom app may be the best choice:
- Deemed an enterprise-wide, business-critical app
- Needs to interact with external users
- Involves advanced complexity, logic, integrations, or UI requirements
- Requires controlled releases and updates
Let’s start with the intended audience of the application. Power Apps has a single tenant distribution model. This means that, within a single organizational tenant, internal users with the right permissions may access the app with their Microsoft 365 (M365) credentials.
An enterprise-wide audience requirement does not preclude Power Apps as a viable solution. As I mentioned above, there are some great use cases for using Power Apps more widely within the organization like filling out a form to change your address with HR, submitting an expense report, or ordering apparel from the company store. But Power Apps can be a little buggy at times, and sometimes a little slow, too. If your app is enterprise-wide and business critical, then you may want more reliability and scalability. A custom solution would allow you to switch hosts if a server is down, easily revert to a previous release if there is a bug, or offer faster loading times for end-users when accessing the app.
If you need input from external users to start or interact with your process, then the scenario starts to get more complex. Staying within the M365 platform, a Microsoft Form could be made available for external users to input data, Power Automate could be used to grab that data and copy it to the data source, and then the Power App can be accessed internally to continue the process. However, that’s starting to get more complex than a typical power user can envision and support. And what if an external user needs to interact in the middle of the process? There really isn’t a model to allow external users to edit existing data. For that, you may decide that a custom solution, or even Power Apps portals, is a better answer.
Complexity, Logic, and Integrations
The more data you load into a Power App, the slower it loads. SharePoint is not performant as the backend of a gigantic dynamic form. The form itself is updating at the same time the app is retrieving records. Added complexity such as lookup lists, special conditions, and complicated form logic can also reduce efficiency and sour end-users.
Power Apps can be a good way to create a proof-of-concept (POC) to prove out a business case. If, after solidifying features and functionality, you have a year-long backlog of development and deployments ahead of you, then you’re probably exceeding what the platform is meant to do. Your solution is too complex, or you’re trying to do too many workarounds to match the business case to the technical solution.
Conditional and validation logic is available in Power Apps. You can show fields based on a value in another field, require a field when certain conditions are met, do some math, or display an optional value when conditions are not met. All logic is stored within the control or form property, which might be helpful for the business owner to make targeted updates. For those who are attuned to managing the logic in one place, this may be a drawback. You can use components to help (reusable logic) but sometimes the logic doesn’t translate over.
For larger, more enterprise-wide apps, this makes it more difficult to support, and it’s one of the reasons developers may find the Power Apps interface counter-intuitive.
Integrations & Licensing
Most business or enterprise licensing plans include basic Power Apps functionality, assuming you are staying within the bounds of what’s available in Microsoft 365. Apps built on SharePoint lists or libraries are good candidates for Power Apps. Apps built within the context of Microsoft Teams can even take advantage of Dataverse if they don’t exceed the maximum number of rows included.
Microsoft offers over 200+ connectors to other third-party apps and services, and here’s where you need to be cautious. Once you move to what Microsoft considers a premium connector, such as SQL DBs or Azure connections, then you’ll have additional licensing considerations.
If it’s it a straight-forward app with just a handful of users, additional Power Apps licenses might make the most sense. The cost of development will be low, and the cost of supporting the app monthly will also be relatively low.
But what about enterprise-wide applications where premium connectors are required? Some applications might be only accessed periodically, like quarterly AED tracking or annual enrollment for health insurance. Does it make sense to license users or applications monthly when the apps are utilized infrequently?
You’ll have to weigh the cost of developing the solution in Power Apps – along with monthly licensing and maintenance costs – with the investment required for a custom solution, both upfront and ongoing. Many times, the custom application will be less over a two- or five-year period.
Look and Feel
If you have very specific UX/UI needs, a custom app will allow much more freedom of field placement, corporate branding, icon options, and other look and feel specifications.
Controlled Releases and Updates
Power Apps work best with a single owner and service account access for backup. That works for Power Apps development since it has historically lacked any true source control. You really can’t have multiple people developing at the same time because they would keep writing over each other’s work.
Power Apps also stores some of the code within the form controls. That’s great for the owner troubleshooting an issue with a button because they can go right to the button to see the code. That’s not so great when someone accidentally deletes the button – and therefore the code – and doesn’t realize it until it’s too late.
To restore previous versions in Power Apps, it takes discipline when saving and publishing versions to add comments to know which version to restore. There are a few options for storing source control for Power Apps: you can export an app and store the resulting zip file in a source control repository, or you can use Microsoft’s recently released functionality for Canvas Apps that makes the process more like custom development. Either way, you’ll need to consider the skills and comfort level of the application owner. This may be too much to expect from the average Power Apps owners like those in HR, Finance, and Marketing departments.
Custom apps allow for larger development teams to work on the application simultaneously while using platforms like GitHub or Azure DevOps for source control.
Updates & Deployments
If you make a change in Power Apps, it doesn’t automatically replicate to other controls with the same code. You’ll need to manually update each place the code exists and keep them in sync. This complicates the process for the average power user and invites the potential for bugs into your code. For multi-screen, moderately complex apps with repeated functionality, a custom app may provide a better and more reliable experience for the end-user as updates are released.
If you find a bug in your code, you may want to release an immediate bug fix. A custom app would allow a bug fix to be released without releasing any in-progress code. For the enterprise-wide and business-critical applications, custom code would allow you to follow a more rigorous change control process with automated testing and build pipelines. With Power Apps, it’s a little trickier to follow the development framework. It’s an all or nothing release. Or you may make a copy of your Dev tenant code to include the bug fix and push that to Production, but then you’ll need to go back to your working Dev source and add the bug fix back in that instance before releasing the new features. If SharePoint is the data source, then each time you push the latest release to Prod, you’ll need to reconnect the underlying lists and/or libraries. There is no automated way to push updates.
There is no one-size-fits-all approach for application development within an organization. You’ll want to balance the line of business side of things – people who know their processes and want a tool to help them increase efficiency, track approvals or outcomes, or improve product quality – with larger and more complex efforts that might have multiple stakeholders and involve several company initiatives.
You also need to weigh the longevity of the app. Is it a POC or a short-term stop gap before a new solution or system is in place? Or is it a long-term solution that will require extensive care and feeding and a permanent development team?
The perfect world for most organizations is likely a combination of both Power Apps and custom development.