Power Platform Processes

Introduction

If Governance concerns managing platforms like Power Platform, there is indeed a strong need for processes. Modern online platforms like Power Platform offer a large number of options and configuration items, and changes of any kind need to be managed and logged. Managing any change or update requires established processes.

Why Processes?

What first comes to mind when thinking about processes are requests from developers or stakeholders. Let's look at a familiar example: the request to approve a new (or blocked) connector. Let's assume a corporate entity wants to create a new Power Automate workflow, that is intended to make the daily business of users easier. but requires a connector, that is currently blocked. No platform administrator would enable a blocked connector just like that. If a blocked connector should be made available, usually a few committees (or corporate teams) have a say - like IT Security, OCM or corporate communications. The best way to involve those teams, collect their feedback and plan the entire procedure is to establish a process. A process makes updates to the platform traceable and helps with documenting the initial request, all involved decisions and the final outcome, including the potential change to the platform's configuration.

Types of processes

Usually, multiple types of processes need to be established

1. Requests / Demands: These processes are usually triggered by developers and stakeholders before or during the development phase of an artifact. They often require the consultation or cooperation of multiple corporate teams and, therefore, thorough planning before they are published and made available. Software support during all phases of these processes is strongly recommended. It's not unlikely that existing software for support tickets (e.g., ServiceNow or Jira, just to name a few) can be reused.
2. Permissions/Access: those demands are around establishing access to a data repository, access to environments or access to artifacts. The main difference compared to the previous type is, that most (if not any) access requests involve not only the mentioned corporate teams (like IT or IT Security) but also data owners. Another difference is, that the previous type of request can be resolved by a platform administrator. Those permission-related requests often are triggered by users of Power Platform but have to be resolved outside of Power Platform (like providing access to a SQL-Server database for a Power Automate flow). This is a good example of why processes need to be created to support the collaboration of multiple corporate entities.
3. Managing Process: those processes are around managing the platform and/or the platform usage. They are not requests but describe a list of actions and activities that need to be followed when applying updates or changes to the platform. Those activities can be around additional support after a platform update is rolled out. Another example is how a Power Platform administrator scans the platform for non-compliant artifacts and how to reach out to the artifact owners to make the artifacts compliant again. In other words: those processes are needed to define a sequence of steps and activities that have to be followed and documented to achieve a specific goal. As mentioned before, this is all about repeatability, documentation and avoidance of errors.

Establishing Processes

Although I don't think any Power Platform administrator will have problems convincing the C-Level management to establish processes around platform usage, the "how" is important. As explained in my previous posts on this topic, it is advisable to start small and learn from experiences. A reasonable first step is to find gaps and look for areas where processes could not just be helpful, but are required. The next step is to look for corporate entities that should be involved. As they should be involved in the process, it makes sense to involve them at an early stage - while defining the process!

Although required, processes should support employees and make complex things easier by providing a repeatable procedure and documentation. This should always stay top of mind defining and implementing processes. When I think back to when I supported organizations as a SharePoint expert during migrations, metadata and Content-Types come to mind: although undoubtedly beneficial, nobody likes to apply metadata tags when adding a new document to a SharePoint document library. It's the same with processes: they are undoubtedly beneficial, but nobody wants to get slowed down by an over-complicated process with way too many electronic forms to fill or too many subprocesses that require coordination.

Conclusion

Only by creating and publishing at least the most important processes can modern online platforms like Power Platform be managed. However, as processes should support employees, they should be as user-friendly as possible while providing the required guidance and bureaucracy to fulfill their raison d'être (e.g., meet corporate requirements).

References:

1. Power Platform Governance
2. Power Platform Monitoring
3. Power Platform Processes
4. Power Platform Tools
5. Power Platform Integration