When to use and when not to use
Oliver Wirkus
Working with organizations to improve automation, collaboration and information management in Microsoft 365
There is no doubt - Power Platform (and especially Power Apps and Power Automate) are a great addition to the entire Microsoft 365 suite of applications and services. Being able to create custom e-forms and custom LOB workflows has always been in high demand by many organizations. With Power Apps and Power Automate, organizations now have extraordinary tools at their disposal to create e-forms and workflows. Still, as a senior consultant, I am often asked my opinion on whether to use both tools and, if yes, for what use-cases or purposes. You might have guessed it already - my answer usually is "It depends!". Although that appears to be the most common answer from consultants (at least if you believe in the many jokes spread on that topic), I don't mean it negatively. It really depends on many factors, and in this article, I want to share my opinion.
Citizen Developer Platform
If you are into Power Apps or Power Automate, you might have heard that term very often. If I am correct, it was Microsoft's Marketing that first linked that phrase to Power Platform. I totally get why they used the term, but to be honest, this term does more harm than good. I agree that Power Apps and Power Platform are easy to use - up to a certain point. For example, a custom approval workflow connected to a SharePoint Document Library can be created within minutes. You truly don't need to be a skilled developer to achieve this. Still, creating and running even a non-complex approval workflow in a professional environment requires more than just a few pre-configured actions stitched together. I am not talking about professional development skills and a complex and powerful development environment like Visual Studio. If organizations are looking to utilize custom workflows to increase efficiency, those workflows need to be developed in a certain way, QA tested, documented and rolled out with proper Change Management activities. That's a little too much for a common citizen developer who enjoys building new stuff - and don't get me wrong, I do not mean that in a derogatory way.
Use Cases and Applications
In a professional environment, nobody develops an app or a workflow just for the heck of it. Usually, there is a dedicated process around any new development, which starts with requirements gathering and continues with architectural diagrams. Basically, the list of requirements and the architectural diagram should be used as a foundation to decide if Power Platform is the best platform to implement and run this - or if other options should be considered.
License Costs
Even Power Platform comes with a price tag, and for many organizations, the licenses costs are a big factor when deciding what platform to use. Basically, there are two different types of licenses: Per App and Per User (Reference). Generally speaking, the more users use an app, the more an organization needs to spend on licenses. That's not entirely true, though, because if most users already enjoy the benefits of a Per User license, there might be hardly any additional costs for licenses. If you want to know more about Power Platform licensing (which can be a very complex topic), I recommend this Microsoft document (Reference). In a nutshell: licensing costs are an important factor to consider.
Target Platforms
Another aspect to consider is the anticipated target platforms. For example, let's assume an organization decides to utilize an electronic form on one of their intranet sites. In that case, a basic web form tailored to the dimensions of the website might be sufficient. However, if the electronic form is used more like an app on multiple devices (like phones, tablets and big desktop screens), a responsive approach appears to be more suitable. Although web forms can be created in a responsive manner as well, targeting multiple devices in an app-like fashion is definitely a strength of Power Platform.
User-Interface Complexity
Some applications come with a very complex user interface, and sometimes the input screen needs to be split into multiple screens, guiding a user through the complex input process screen by screen. In those cases, there are likely complex dependencies between data input elements as well. For example, a list of choices varies depending on what the user selects in a different field shown on a different screen. In other words: complex user interfaces usually use complex business logic as well. Theoretically, business logic can be hard-coded into the user interface, but that's not a recommended approach. Each time the business logic got updated, a new version of the app needs to be published.
The above is just one example of a complex user interface. As a rule of thumb, I would say that the more complex a user interface becomes, the more organizations want to evaluate other options as Power Apps isn't build for large and complex user interfaces. On the other hand: if your app does not have a complex UI and all user interface actions can be handled with a few forms, Power Apps offers a variety of UI elements a developer can use to create an appealing app almost effortlessly.
Connections
In my previous article (Reference), I already talked about connectors as one of the building blocks of Power Apps and Power Automate. If your application requires connections to other services or applications, the Power Platform connectors provide a great benefit as they hide almost the entire handshaking and data traffic from users. Isn't that a big PRO for Power Platform? Well - yes and no. 'Yes' because establishing a connection to a different service is easy as the connector hides all those nitty-gritty handshake details from the developer. 'No' because this does not unshackle a developer from error handling (which I will discuss later). In a nutshell, if your app requires connections to other services (especially M365 services), utilizing the almost ready-to-use Power Platform connectors greatly saves time during development and testing.
Error Handling
I am pretty sure die-hard advocates of Power Platform might disagree, but even a Power Apps application or a Power Automate flow requires proper error handling. Let me explain what I mean. Let's assume a connector is used to read data from a SharePoint list. In Power Platform, the SharePoint Online connector already provides an activity that a developer can use to read a data item based on its ID. If everything is configured properly, it is likely that this activity won't fail, but what if it fails anyways? In a professional environment, artifacts like apps or workflows need to be created with proper error handling. Just because Microsoft likes to advertise Power Platform as a platform for Citizen Developers or as a hardly-no-code development environment, that does not mean that we can just stitch together activities taken from connectors and publish an app that is safe to use. Proper error handling is important for at least these two reasons: User Acceptance and Data Integrity. There are definitely more good reasons to implement proper error handling, but let's just go with those two. If an app or workflow often crashes without any noticeable wrongdoing of users, this will catapult any app back to the devs and QAs and the user acceptance is ruined. A second release will have to deal with the poor user acceptance of the first release.
领英推荐
The second reason is much more important. The app or workflows deals with corporate assets (computer systems, data records or documents) and a sudden crash might corrupt data if ignored. Here is an example: let's assume an app adds a new order to a Dataverse data table and then updates the customer's record. Let's further assume, the first operation fails (no order got added), but the app just continues with the second operation (updating the customer's record). All of a sudden, the data integrity is corrupted. OK, acknowledged, that's a poorly made-up example, but I guess it illustrates the problem. I am trying to say here: even though hundreds of ready-to-use connectors are available, developers in a professional environment need to add proper error handling to ensure the app or workflow is safe to use with organizational assets. Of course, that's not necessarily a CON for Power Platform. Still, organizations should not underestimate the efforts needed to create a safe app or workflow in Power Platform - just because it might look as apps or workflows can be created based on a LEGO brick principle.
Life-Cycle Management
This is a different topic and depending on the use-case or the complexity of an app or workflow, the meaning of "Life-Cycle Management" might differ. So, let's try a high-level approach here. If an app or workflow is created and unlikely to be changed frequently, there might be no real benefit in having a textbook-like Life-Cycle Management. However, if we are talking professional development, there needs to be at least a fundamental Life-Cycle Management. Don't get me wrong, this kind of lightweight Life-Cycle Management can be established in Power Platform, but it is still very hands-on and requires much additional manual effort.
Data Repositories
When developing a new electronic form, developers need access to a data repository that uses the same schema as the real-world data used after the app got published. In most cases, this requires switching of repositories. Here is a basic example: let's assume a PowerApp application for managing maintenance tasks is created. The app runs on data provided by a complex Dataverse database that includes tasks, responsibilities, locations and options to order replacement parts. In addition, the app requires access to Dataverse tables, a SharePoint Online list and the M365 user repository. During development, the repositories created with dummy data are used, but once the app is released officially, it consumes and updates data from the repositories in production. Switching between both sets of environments is doable, no doubt. Still, depending on the actual connectors, it is not as easy as just using an additional/different connection string in a C# application.
Debugging Options
Nobody is perfect and even the most skilled developers require proper debugging options in case their app misbehaves. Being a former C# developer, I loved the great debugging options provided by Visual Studio. Sometimes, setting up a debugging session in Visual Studio wasn't easy and took some time. Still, once everything was up and running properly, debugging an application could be fun just because of the powerful features Visual Studio offered. In Power Platform, things are different. There are debugging options and some are really handy, but if you need to debug a huge app or a complex multistage flow, you will soon realize that there is some room for improvement. Again, I am not saying it isn't doable. Depending on the complexity of an app or flow, debugging can be a lengthy and time-consuming process that caused me some additional grey hair. On the other side, I admit that due to the many pre-created actions and connectors there are fewer chances that something goes wrong. Again, that's not a topic that should scare you away from using Power Platform. It is just meant to be an additional topic to consider when deciding on a platform.
Development Environment
Admittedly, I am spoiled, because when thinking about a development environment, Visual Studio is the first that comes to my mind - and I loved it! However, when developing a complex flow, you will notice that very soon you are missing a curved wide-screen monitor (the ones that can fit three or more regular screens next to each other) that makes your desk almost look like a wide movie screen. I created some complex flows already and being forced to scroll from left to right and back is annoying. Even though Microsoft really improved the Power Platform development environments and will publish additional improvements, both -PowerApps and Power Automate- offer room for improvements and are still far from the comfort offered by Visual Studio (but I might compare apples and oranges here). Let's say it this way: both Power Platform development environments can be used to create even complex apps and flows, but due to both environments not being ideal for large projects, developers might need more time to develop and test apps or flows.
Corporate Branding
I think it is important to apply proper corporate branding to apps and flows as well. This ranges from designing forms to incorporate the company's colours and logos, up to notifications that can be recognized as originating from the company and not moved to SPAM folder accidentally. Although corporate branding appears to be a no-brainer for common web forms, I don't see a lot of corporate branding when looking at apps and flows clients have developed. It's not rocket science to apply a corporate logo and the approved colour codes to an app, but it needs to be done. Depending on the number of UI elements used in forms, this might take some time and needs to be added to the effort estimates.
Summary
Let me be clear: I do not want to scare you away from using Power Platform when planning apps or flows. The opposite is true! I want to encourage organizations to use PowerApps and Power Automate more often to build great applications and LOB workflows. I just want to increase the awareness of decision-makers in organizations of PowerPlatform not being an environment enabling citizen developers (and again, I don't mean this in a deprecatingly manner) to create the new app the organization wants to have in a jiffy. Power Platform provides many great advantages when it comes to creating apps or flows. Still, as with every professional development, there are pros and cons that need to be evaluated thoroughly. Decisions will be easier if an approved corporate strategy regarding app development is built into the process of reviewing and approving new apps. Many organizations do this: prior to staffing teams and providing funding, every new app needs to be reviewed and approved. An important step during this app approval process is looking at the anticipated development environment and checking it is the best fit.
With this article, I want to raise awareness of decision-makers, that Power Platform isn't the panacea to professional app and flow development. It is a new exciting development environment with its own specific pros and cons. Admittedly, often it makes sense to create apps and flows using Power Platform. Still, even Power Platform development can't be done in next to no time as it is professional development as well. If it makes sense to utilize Power Platform for your next project, definitely go for it, but run a thorough effort and cost analysis prior to starting developing - and if that analysis reveals that Power Platform isn't the best option, don't shy away from checking alternatives.