Power Platform - an initial look
Having spent the initial part of my career within the SharePoint space, the concept of low code development is something that is somewhat close to me. Starting with Microsoft InfoPath and SharePoint Designer and then escalating to the likes of Nintex and K2, I quickly saw the power (no pun intended) of what could be achieved with nothing more than just a visual designer and some logical expressions.
Fast forward a few years and the low code landscape has obviously shifted significantly, with InfoPath and SharePoint Designer 2010 workflows (original darlings of Microsoft) both being earmarked for end of life. Instead, what has risen from their ashes to take over the Microsoft low code mantel is the Power Platform or more specifically, PowerApps, Power Automate (ex. MS Flow + some newer RPA elements e.g. WinAutomation), Power BI and Power Virtual Agents. Whilst there is still much debate over feature parity with it's predecessors, one thing which cannot be denied is the ever increasing library of connectors in which Microsoft has made available as part of the Power Platform.
Connectors are classified as either Standard or Premium connectors. Standard connectors are free to use (at least for now or until Microsoft decides to move them to premium) and then there's premium connectors which incur a cost. You can find out more about the different licensing options from Microsoft but the point I would like to make here is that the availability of these connectors make it significantly easier to build solutions that needs to 'talk' to other systems, all without needing to code.
But the connector's are only one side of the story of Power Platform's success. One movement which has been bubbling away in the background is the concept of the citizen developer. The concept of citizen development is to provide IT-approved tools to enable business users with little or no programming experience to start building simple applications. Popularised by Gartner a few years back, organisations are starting to embrace the promise of increase agility as more and more workplaces become increasingly digital and decentralised (as witnessed in the current global situation).
But it doesn't come without it's challenges. Whilst it is easy to have visibility and control over a single or even a handful of business developed applications but what happens when those handful multiply to quickly become 20, 50 or 100? How do you ensure proper governance by ensuring applications are designed, documented and supported and that the proper security controls are in place to prevent sensitive data from exiting the organisation from right under their nose. There are also many other considerations which are more specific to Power Platform which I will also not get into like for example updates introducing breaking changes, the Excel like syntax, performance due to the running with the PowerApps app and the deprecation of features with little notice, some of which could lead to an organisation having a very bad day.
Well, there probably isn't a silver bullet for now and much of it would necessitate the need for a framework whereby IT can work hand in hand with the business and ensure the necessary guardrails are in place to address any surprises which will inevitably happen one day. I say guardrails and not gates as the former is designed to enable whilst the latter is designed to hinder. At the end of the day, everyone within an organisation should be heading in the same direction for a common cause.
With this said, one thing which I have been looking into lately is the concept of a Data Loss Prevention policy or commonly known as DLP policy. A DLP policy is a set of rules within the Power Platform to help organisations protect and secure their data by restriction how and when these connectors can be used. I mentioned the two classes of connectors earlier but that is more related to pricing tiers than anything as the Power Platform itself won't be able t distinguish whether the data source you are connecting from or to is sensitive or not.. The latest update to DLP now enables organisations to group any connectors into three buckets either at the environment or tenant level.
- Business - connectors you add to this group are those which you tell Power Platform contains sensitive data. If you use a business connector within an application or flow, you can only use it in conjunction with other business connectors.
- Non Business - connectors you add to this group are those which you tell Power Platform does not contain non sensitive data (and should not be used in conjunction with a business connector) within the same application or flow
- Blocked - connectors you add to this group are those which you tell Power Platform you want to prevent your users from using. Some connectors are not able to be blocked and falls under the below two categories. For more info, please refer to Microsoft here:
- Office Enterprise Plan standard connectors (with no additional licensing implications).
- Microsoft Power Platform–specific connectors that are part of the base platform capabilities. Within this, Common Data Service connectors are the only premium connectors that can't be blocked, because Common Data Service is an integral part of Microsoft Power Platform.
The process flow of creating a DLP policy is as follows:
- Access the Power Platform Admin Centre - you will need either M365 global admin permission or Power Platform admin permission.
- Assign the policy a name
- Group your connectors into Business, Non Business and Blocked
- Specify the scope of the policy (tenant vs environment) and if the latter the environments it should be applied to
- Review and apply the policy
Once a policy is applied, the blocked connectors will still be visible to the developer but when they try to configure and save the connection, they will see a generic message indication violation of a DLP policy. It would be nice to be able to customise this message in the future to be a tad more user friendly and/or direct them to IT for a further discussion.
All in all, the Power Platform provides a robust set of tools to enable simple applications to be built with little or no code. With the proper guardrails in place, there is a potential for organisations to be more agile and better equipped to meet the challenges of new ways of working and new ways of doing business with their customers.
For more information and a step by step guide, please refer to the Microsoft website here.