Power Platform – When To Use It and When Not

Microsoft Power Platform history and usage

When PowerApps and Power Automate were released in 2017, Microsoft’s intention was unmistakable. Office 365 needed tools that organizations can utilize to build modern and powerful electronic forms and workflows. Both were needed to advertise Power Platform as a foundation for organizations to develop their modern digital workplace. As Office 365 is a cloud-based solution, PowerApps and Power Automate needed to be cloud-based too, but not limited to an Office 365 tenant. That’s why Microsoft designed both to take advantage of connectors, which allows for creating apps and flows that can even read/write data hosted outside of the Microsoft cloud. Connectors and the easy-to-use development environment (often called No-Code-Solution for Citizen Developers) were the main drivers for success. Many organizations use PowerApps and Power Automate to create electronic forms and workflows that integrate with their custom digital workspaces. Recently, Microsoft even announced a significant reduction in licensing costs (effective October 2021). As license costs have always been a concern for organizations, this reduction will likely increase PowerApps and Power Automate usage and make it more competitive in the market against other no-code solutions and allow larger enterprises to adopt easier. However, PowerApps and Power Automate might not be the go-to solution for every use case or automation requirement. Both have their uncontested strengths, but there are use cases where both tools might not be the ideal solution.

Organizational use cases where Power Platform excels

Organizations use PowerApps and Power Automate to create custom solutions that fill gaps in their custom digital workspace strategy. For example, PowerApps is often used to create apps that offer a user-friendly UI to input data and hide direct access to the data’s repository. Those input forms can also include business logic and plausibility checks. Power Automate is often used to support internal LOB workflows (e.g., document approvals or records management). Combined, both can create solutions that use powerful forms (PowerApps) that trigger actions (Power Automate). This section provides details and best practices on three common use cases where Power Platform can play out its benefits.

Replacing InfoPath forms
InfoPath was released in 2003 and advertised as a tool to connect different systems and facilitate data exchange. Many organizations used InfoPath to create custom forms, which sometimes included internal logic as well. As InfoPath was designed as an on-premise application, it cannot be used with modern cloud-based services. Organizations are well-advised to review their existing InfoPath applications and consider modernization as support has ended and extended support will end in July, 2026. The best option to repleace classic InfoPath forms is PowerApps. Many more organizations can benefit from increased efficiency, improved security, enhanced governance, a modern UI and additional functionality or better integration by replacing outdated InfoPath forms.

Our recommendation:

• Thoroughly review existing InfoPath forms and look for modernization options incorporating a cost-benefits analysis
• If the InfoPath form still meets all requirements, perform a like-for-like upgrade using Power Platform
• If the InfoPath form still meets most requirements and would benefit from a few upgrades, perform a like-for-like upgrade using Power Platform and add modernizations
• If the InfoPath form only meets a few requirements but is still considered essential for the business, work with stakeholders on a redesign based on the capabilities provided by Power Platform
• If the InfoPath form does not meet requirements or is not considered essential for the business, retire the form and integrate potential beneficial parts into a global modernization strategy

Replacing outdated SharePoint workflows
When Microsoft initially released SharePoint in 2001, it was clear that SharePoint needs to support at least internal workflows to provide a fundamental level of automation. Although SharePoint provided workflow templates (SP2010 and SP2013 workflows), this wasn’t enough for many organizations to build their entire corporate intranet based on SharePoint. The infamous external tool SharePoint Designer added additional support regarding UI updates and custom workflows. Still, this tool was too clunky to use, couldn’t create reusable solutions, and was unsuitable for the new SharePoint Online.

Our recommendation:

• Thoroughly review outdated workflows and look for modernization options incorporating a cost-benefits analysis
• If a workflow needs to be replaced for technical reasons (such as an SPD workflow that can’t be executed in SharePoint Online anymore), perform a like-for-like upgrade using Power Automate
• If the workflow still meets most requirements and would benefit from a few upgrades, perform a like-for-like upgrade using Power Automate and add modernizations
• If the workflow only meets a few requirements but is still considered essential for the business, review the underlying business process and work with stakeholders on a redesign based on the capabilities of both

Increase integration in Microsoft 365
Although Microsoft 365 is a fantastic platform for organizations to build their version of a modern digital workplace, not all requirements can be met by adjusting configuration only. Each organization has individual enhancements requirements, which often include a customized integration of external systems (e.g., data from SalesForce or SAP) or support for internal LOB workflows (e.g., collecting data for monthly financial reports). Sometimes, there are requirements to enhance existing Microsoft 365 services (like updating project plans while in a Teams meeting) or support business automation or hybrid connectivity (e.g., while transitioning from an on-premises environment to a cloud-based M365 environment). It is pretty surprising to see how much potential for expedient improvement is discovered by employees involved in internal processes daily. On the other side, organizations have tangible benefits, like enhanced support, improved governance options, integrated toolset upgrades (due to a SaaS approach), and ready-to-use artifacts (like connectors and UI elements) that significantly reduce development time and maintenance costs. Compared to classic custom development, integrated M365 tools and the ease of use (means: development and usage) reduce the ROI time and costs for organizations.

Our recommendation:

• Perform a professionally led and engaging improvement gathering exercise to get a list of potential improvements identified by the businesses.
• Structure and categorize the list incorporating a cost-benefits analysis and corporate modernization strategies.
• Work with stakeholders on a prioritization of the identified enhancements and potential adjustments to make them fit a corporate modernization strategy
• Perform a risk and security analysis for identified enhancements — if required
• Plan and execute each enhancement as a regular software project, including proper Change Management activities and Governance updates

Know limitations and everyday struggles

Let’s be honest! Where there is light, there is also shadow. Although PowerApps and Power Automate are preferred solutions for most customizations in Microsoft 365, there are some limitations that organizations need to be aware of to select the best technology for their customizations. This section highlights some of the most prominent limitations and provides workarounds.

Provisioning
Provisioning describes how artifacts (apps and flows) are transitioned from development to production. Although provisioning is part of application lifecycle management, it makes sense to look at how provisioning works and what organizations need to consider. In the end, smooth provisioning is a crucial step to success and impacts user acceptance significantly. Our established best practice is to use at least two (2) environments: one for development and testing and one for sharing the production version of apps and flows with a broader audience. Depending on the complexity of your solution (apps and flows) and the involved data repositories (via connectors), a third environment can be beneficial to enable QAT and UAT to be performed uncoupled (or detached) from the development environment. This third environment can be used for training purposes as well.

Workaround/Solution
Our recommended approach is to use at least two environments to isolate development from production. However, there is no one-fits-all approach. Therefore, we usually perform a Development Environment Strategy planning with our clients to find the best process collaboratively. When conducting a Development Environments Strategy planning, we work with our clients on these topics:

• How is Power Platform development managed at your organization?
• Which corporate entities can get Power Platform environments?
• How are new environments requested and provisioned?
• Can corporate entities request, e.g., Dataverse, distribution lists or technical accounts, and, if yes, how?
• Are there options to automate requesting and provisioning?
• Are corporate entities charged for using Power Platform environments?
• What governance policies are there regarding Power Platform environments?
• Is there a central repository (e.g., Center of Excellence) that describes all processes around provisioning?

This planning should be performed with all stakeholders. Once the strategy got approved, describe the process in the corporate Governance document and preferably in the Center of Excellence.

Application Lifecycle Management
Microsoft is aware of the importance of professional Lifecycle Management for the Power Platform. Therefore, on the Power Platform developer site, Microsoft provides extensions to Power Platform that enhance Application Lifecycle Management (ALM) by connecting Power Platform development with, e.g., GitHub and Azure DevOps.

At Build 2021, the Power Platform team focused on Continuous Integration and Continuous Delivery (CI/CD) pipelines and ALM through GitHub and Azure DevOps. Also, the team showcased how Power Platform can take advantage of the GPT-3 language model to generate PowerFX code from English statements. By using and implementing ALM with Power Platform, processes can be streamlined.

Here are some examples of how ALM can be implemented:

• Automation: Automation is a vital part of the application lifecycle that improves the productivity, reliability, quality, and efficiency of ALM. Automation tools and tasks are used to validate, export, pack, unpack, and export solutions in addition to creating and resetting sandbox environments
• Shared Source Control among the Dev team: Today, professional software development is predominantly a team effort and not performed by a single developer. Tools such as those provided in Git, GitHub, and Azure DevOps were designed for the express purpose of improving communication and software quality. Still, working as a team can have disadvantages if not appropriately managed. Therefore, even if Power Platform is still advertised as a Citizen Developer Platform, we highly recommend following established procedures regarding managing a professional development team.
• Continuous Integration and Continuous Deployment: Although organizations can use almost any source control system and build a pipeline to start with Continuous Integration and Continuous Deployment (CI/CD), we recommend focusing on GitHub and Azure DevOps (Reference 8). Azure DevOps provides developer services supporting teams to plan work, collaborate on code development, and build and deploy applications.

Complex user interfaces
Some applications use a complex user interface. ‘Complex’ here means that many user interface elements are needed, or many of those UI elements have complex dependencies. In PowerApps, placing too many user interface elements on a single form usually is not a good idea as this would significantly decrease usability and user acceptance. Instead, it is much better to create multiple forms that work on the same data set and guide the user through the entire input process. This kind of user interface is sometimes referred to as a wizard. From a user interface perspective, this kind of guidance is the recommended approach. However, creating a multi-stage input process with multiple forms that allow moving back and forth (or even switch to a random form) is hard to implement and exceeds the proficiency of citizen developers by far. PowerApps is capable of executing even applications with complex multi-form user interfaces. But as a rule of thumb, the more complex a user interface is, the more there is a need for skilled and experienced developers and user-friendly form navigation.

Workaround/Solution
If the user interface becomes too complex and needs to be split up into coherent forms, this is what we recommend:

• Work with a Business Analyst or User Interface expert to restructure a form if the designed user interface is complex or requires too many UI elements
• Create a PoC or a form dummy and collect feedback from key users or SMEs
• Build a form structure that focuses on clearly defined data input and create form navigation that allows users to switch between those forms
• Implement a caching mechanism to ensure data isn’t lost when users switch between forms
• Design a multi-form user interface so that a user is guided smoothly and consistently through the entire input process

Using multiple data sources
The mentioned connector concept comes with another advantage. PowerApps and Power Automate can simultaneously use multiple (different) connectors to access various data sources if those connectors belong to the same group. This option can improve the user experience, e.g., by prepopulating choice fields in an input form based on a table in a SQL Server database. However, dealing with multiple data sets simultaneously demands a clear and elaborated concept regarding managing data sets from various sources. In addition, performance might become a concern if applications are executed on mobile devices. Also, using multiple data sources requires that app users have at least Read-Only access to all supporting data sources. Some connectors allow using a technical account (or system account) to access data sources, which can slightly ease the management of access permissions. However, regarding the initial planning, we recommend creating an Access Permission Diagram to accompany the technical architecture of any app or flow using multiple data sources.

Workaround/Solution
Using multiple data sources in an app usually harms performance and increases the complexity of an app significantly. Although there is no specific workaround or solution for this, if we work with clients on creating a multi-sourced app, these are our recommendations:

• Review the source data repositories and look for options to consolidate data items (e.g., by joins or linking) to reduce the number of internal API calls required to retrieve a complete set of data
• Work with Business Analysts and data administrators on a Data Process Diagram that -once approved- can be used by the developers to retrieve data from multiple
• If data is used to prepopulate choice fields, this data could potentially be cached within the app rather than being read each time a new data set is displayed

Coherent app users
If an organization decides to create a PowerApp shared with a broader audience, consider a few topics. Although Microsoft reduced licensing costs significantly (Reference 1), license costs might become an issue if an app is shared with hundreds or thousands of users. In addition, if an app is shared with many users, the app and the data repositories need to handle concurrent access requests. This scenario means that the number of users an app or flow is shared with is not the problem, but the number of simultaneous users can become an issue.

Workaround/Solution
The main problems here are performance and data integrity. Still, depending on the app and used connectors, license costs can also become an important topic. As there is no specific workaround or solution, there are recommendations that help with planning and designing an app to avoid the mentioned problems:

• Re-evaluate the anticipated audience. It might be sufficient if just team leads work with an app rather than every employee
• Re-evaluate the utilized data repositories. Instead of using a single repository for all employees, create multiple repositories (based on location, team or business)
• Implement a lock feature or use a transactional approach to avoid data integrity issues. This approach ensures that one specific user can only update a particular data set.

Offline usage
Although the concept of cloud computing is all about enabling accessibility anytime from anywhere, this does not mean there are no requirements around offline usage. Those requirements range from tolerating a short internet disruption on mobile devices up to offline work and synchronizing updates back once online again.

Workaround/Solution
The main problems with offline scenarios are data integrity and up-to-dateness. Before designing offline scenarios, organizations should first consider how the app works with data. Apps and flows primarily access data through a set of connectors that the platform provides, such as SharePoint, Office 365, SQL Server or Dataverse. When dealing with offline scenarios, these are our recommendations:

• Evaluate requirements with stakeholders thoroughly to check if there is a requirement that justifies the increased amount of effort to implement offline usage
• Instead of thinking about offline usage, check if mobile data (4G or 5G) can be used instead
• If offline usage is a requirement, implement a check-out/check-in mechanism to ensure data integrity
• Offline usage means that data is kept within the app until uploading to a corporate data repository. Although this can be implemented using internal collections and tables, the amount of data (means the number of data items) should be limited to manage storage capacity on mobile devices

Offline usage also requires that additional scenarios are evaluated. For example, offline data can be kept in internal collections and tables, but what if the app is closed accidentally or the mobile device crashes or reboots? Offline data can also be saved to internal storage (e.g., using an Excel spreadsheet), but managing offline data stored in local files can add not little complexity to the app.

Contact one of our PowerApps experts today!