Microsoft’s Power Platform is a powerful set of tools that provide the opportunity to empower Citizen Developers to create robust business applications and automation. The potential provided by the Power Platform is immense, and organizations across the world are embracing it, with varying results. What many clients are quickly finding, is that without proper planning and governance, the Power Platform can become a hassle to manage and control, particularly while trying to maintain that control without sacrificing the freedom of your Citizen Developers to achieve their goals.

At Bloom Software, we are often engaged well after the Power Platform is in use, to advise clients on how they can structure their Power Platform usage to enable the organization, while protecting it from accidental catastrophe. This includes a component of change management, since the existing behaviour will need to change to fit the needs of the governance plan.

It is often so easy to get started with building solutions in the Power Platform that proper considerations aren’t given to things like data governance, deployment processes, or anything involved in a traditional enterprise development model. This is for good reason, since those who are often the first to pick up the tools are power users who may not necessarily have a development background at all.

Have you asked these questions?

"Who should be allowed to build Power Apps or Flows in Power Automate?"

By default, in the default environment, every licensed user can build solutions. Since licensed users have Power Apps and Power Automate for Office 365, this means that in many organizations, everyone can build whatever they want, good or bad, regardless of skill.

"Should all data stay in Office 365?"

Are there other data sources outside of Office 365 that your users might want/need to include? Here at Bloom Software, we use Harvest to track time and projects, making that data critical to certain specific solutions. Allowing users to leverage Harvest data, which is outside of Office 365, requires additional licensing, at a higher cost.

"Should we allow business data to mix with non-business data in a solution?"

We don’t want Bob accidentally sending the top-secret launch date for our next product out to our competitors via Twitter, do we? Perhaps we should remove the ability for users to build a solution that connects business data (SharePoint) and Gmail? But, we also have to consider the Marketing department, who love the idea of logging Tweets with a specific hashtag to a SharePoint list in their Team Site so they can take action.

"What happens if one of our Citizen Developers leaves?"

Bob did a fantastic job of building dozens of small workflows that really helped things run smoothly around the Accounting department. Unfortunately, Bob won the lottery (I guess fortunately, if you’re Bob) and is currently relaxing on a beach in Aruba. When his account was disabled as part of normal employee off boarding, all of those workflows broke. How do we prevent this, by making sure an administrator can take control of a solution to keep it running, enhance it, or shut it down?

"How do we keep multiple people from spending time building the same solution? How do we make sure that knowledge is shared, so we all get better?"

I’ve paired these two together because they both go to the need to establish a learning culture within the organization if you truly want to succeed with the Power Platform. Establishing the role of Citizen Developer, championing them to learn, evolve, and share their knowledge, and ensuring that they are aware of the best practices required from a governance level helps to avoid lost time, poorly developed solutions, and duplicated effort.

Planning for the future

If you need help figuring out the answers to any of these questions, or how things like multiple environments, Data Loss Prevention Policies, and licensing work in your specific context, Boom Software can help.