Getting Started with the Power Platform

Microsoft Power Platform: From then to now

In the old world, we had InfoPath and SharePoint Designer workflows which centered on SharePoint. There was also SQL Server Reporting Services to report on the data that is collected from InfoPath forms and stored in SharePoint lists or other sources.

InfoPath is dead and now we have a new model with the Power Platform. It is designed to be part workflow engine, part data visualization, part low-code no-code solution. It is meant to be independent of SharePoint where InfoPath relied on the SharePoint data stores. With the Power Platform, you can connect to many sources inside or outside the Microsoft 365 ecosystem. This was a larger shift for Microsoft as they began to work more closely with external systems.

Overview of Power Apps, Power BI, & Power Automate

Power Apps

While PowerApps is considered a “forms” toolset, it’s really a business process front end. It is the successor to InfoPath. You can build a lot of your business logic into forms, as long as your logic is taking place while you are filling out these forms and adding data. You can also fire off Power Automate flows from a PowerApp so the boundaries between these solutions are getting a bit fuzzier. They are meant to work together. Some easy connections to common Microsoft 365 data sources include: SharePoint, Dataverse for Teams, OneDrive, Excel, Outlook, etc.

Power Automate

Power Automate can be used for any repeatable process that you want to kick off and have execute. There are multiple native connectors to the Microsoft 365 ecosystem to interact with data within the system, including Forms, Outlook, SharePoint, Lists, and OneDrive.

Keep in mind, the HTTP action is your friend. It can be used to access REST data for non-native connectors, call other flows, Azure functions, and provide an incoming webhook. It’s also helpful to follow the process of encapsulation when using Power Automate.

Power BI

Power BI is your analysis tool. What does all of the data mean? It’s much easier to find trends and patterns when the data is collected and used in a visual process. The connector here is very powerful because data can be pulled from multiple different sources to analyze data in one place which can then be embedded directly into SharePoint to remove friction from colleagues’ ability to consume this information as well.

Solution Example - Tools Working Together

The Power Platform apps and services are strongest when used together. Users can collect information through PowerApps, process that information through Power Automate and then analyze the information through Power BI.

Lessons We’ve Learned

Administration is lacking

When these products were developed, it was done with the end users in mind. All the focus was on usage, not administration. Controlling who can use it, how you can get in, what is out there is very difficult as there is no administration module. You can use some PowerShell modules or some of the CLIs to cobble this together.

Start with Outcome Objectives

There is a lot of pre-work that needs to be done for these solutions, so you are focused on the right top tasks for your end users and are creating a clear backend structure. Having a messy backend creates a nightmare when connecting to all these solutions. Your data model is critical in the ability to succeed in collecting, managing, and presenting the data you need.

Don’t mess up the owner

The connectors use delegated permissions so whoever the connector is created by are the rights of that connector. You can create an elevated permission guideline by creating a separate licensed user that is your solution user that can be the one with the elevated permissions to complete the things you want to do. Just be cautious in using yourself as the user as once that account is closed, there will be issues with whatever was built. The connector is always connected to the creator though it can be transferred.

Separate Your Logic

If you are going to have a lot of data manipulation logic, decide if it will be in Power Apps or Power Automate, don’t mix and match. For example, if you build your logic into the Power App and then use Power Automate for notifications that is a good break. If you mix and match will have a harder time debugging issues and managing things later on.

What are you building in the Power Platform? Continue the conversation on Twitter with the hashtag #AskSympraxis and mention @SympraxisC.