In this post we'll explore the key areas you will want to consider if you are to create a location where your teams can be creative with the Power Platform but also avoid the likely sprawl and confusion that comes with poor or no control.
Im going to give you a 4-Step Guide to gain mastery over your products and rollout plans. None of which require you to elevate licences, install new tools or take overly complex admin steps. Ready? Let's go!
The Bit Where People Need Convincing to Read On
Your first question might be "do I need control? Surely making apps is meant to be easy. Why add red tape and start thinking about processes and "control"?
I've written this post because when you start to use the Power Platform, you'll quickly realise it's possible to create business solutions VERY quickly. Take our Power Automate JumpStart challenge for example. Inside 10 minutes you have a flow up and running that can add real value.
Scale that across a team of people, all with ideas and all willing to get creative to create solutions. Imagine the volume of new apps and flows you could create. Imagine the business benefits you can generate very quickly - even with a small team.
HOWEVER, the downside of lots happening fast and in an organic manner is that everyone will have their own ideas. That can lead to confusion, apps for production and testing apps all in the same place. Different naming conventions. Use of connections that are premium without any control. No oversight on where new products are created and more. Having no process or agreement at all almost always means there will be confusion and problems somewhere down the line - usually sooner than later.
Why Not Just Develop in the Default Environment?
Doing nothing just means you leave the Power Platform setup to whatever Microsoft have set you up with for a new tenant deployment.
In terms of people creating Power Platform Products, the standard setup is that everyone who is licenced to make apps and flows get's granted permission to what is called the 'Default' Power Platform environment.
Here, anyone can create and delete flows or apps so long as they have either made them or have had them shared with them (Shared Flows and your own appear in your list for both Power Apps and Power Automate Flows).
Default Environments Let All Members Edit and Create
Anyone can edit someone else's app or flow if granted permission which is great. So from a development perspective, it's a collaboration tick to leave as-is.
However, it gets more sticky when we want to make Apps and Flows 'operational' (to use them for an important business process). If anyone can edit, potentially anyone can change and break a flow that an important business process may rely upon.
This is maybe fine in a small team where people talk lots but even then, mistakes can happen and fixing breakages might incur cost or a customer impact.
Space Is Limited In the Default Environment
You may also limited in how many Power Platform apps or flows you can create. Default environments have a 3GB limit on storage (for data and files). This is fine if you are using SharePoint lists to store data for your products but if you build apps or flows that use the Dataverse capacity (this can be aligned to your Environments), you may run out of space really quickly thus limiting the volume of business applications you may be able to create.
Not All Products Are Meant To Be Experiments
Another potential pitfall of the 'everything, everywhere all at once' method is simply the nature of people. We sometimes half create a product and leave it, moving onto another experiment or solution. Knowing what apps or flows are there because of an experiment, what is intended for a colleague to check and validate (maybe work on), what needs to be left alone because a critical business process relies upon it may not be that easy if you just default to having no process.
Naming conventions could solve this but in a list of dozens of Power Apps, do you really want to have to go hunting for that App which just failed when your customer is on the phone to you asking for help?
Separation of Concerns Is Hard When You All Create In 1 Location
There's a by-product of leaving processes to one side which happens when owners or makers for flows leave the team. How do you deal with support and maintenance if they have not shared their work with anyone else in this 'Default' environment?
Again, it is not difficult to solve in and of itself but when seen along with some of the other gotchas mentioned it starts to make having a process sound like a positive step. By process, we mean having a shared and common understanding around what gets built, for what reason, where it is located for quick access and who can change and update or change work that has become important.
Settings That Work For 1 App May Not Work For All
In some cases, the app itself may require something in the settings relating to an Environment to allow it to function correctly. This may not be something you want to be available across all apps.
An example is when you perhaps want to enable Co-Authoring between 2 parties on a Power App (for a specific proof of concept purpose where collaboration is essential in tight timelines). There are various settings to work with both in the App itself but also at the Environment level. You can update these for the 1 app but they may conflict with something present in another app causing it to malfunction.
An example is enabling the Power FX Formula bar in power apps for an environment. That may have a role in making the correct co-authoring features in your app behave poorly - leaving you thinking this isn't working - when in fact, it is an environment setting that is the issue, not the process you are working with.
If You Want To Know How To Start Your Power Platform Governance, Read On ...
The perfect state for all creators of apps or flows to work in is one where there is autonomy but there is also clarity, control and alignment. Achieve this, and as a business or team you can be confident that the right products are getting created in the best way to make use of your precious licence spend and also you are not going to get muddled as to what a flow or app is there for.
(Nb: We've adding new blog posts to support each topic below in the hope it will encourage you to find a framework and a balance that suits your organisation. Keep checking back on this post as links will be added to this foundational post.)
Join 11,000+ in the Collab365 Academy
Master Microsoft 365, Power Apps, Power Automate, Power BI, SharePoint with Exclusive Access to 450+ Hours of Expert Training and a Wealth of Resources!
Step 1 - Begin With a Conversation With Your Team
It's tempting to believe an expert can give you THE solution to what to do to set up your Power Platform environment for success. But this isn't realistic. Every organisation and every team are different. Finding YOUR way is important.
However, there are some common elements you'll need to consider before putting fingers on keyboards.
- Education: Ensures that every team member has a thorough understanding of the tools they can and should not use and the processes you want to foster in ALM.
- Effective communication: Allows for the sharing of ideas, feedback, and concerns, fostering a collaborative environment where all voices are heard and respected.
- Collaboration: Leverages the diverse skills and perspectives within the team to create a more robust and adaptable ALM strategy.
Without these elements, implementing a process in isolation can lead to misunderstandings, resistance, and inefficiencies, as team members may not fully understand or agree with the approach, leading to a lack of commitment and potential failure in execution.
3 Ways To Get You Started Developing Your Power Platform Control
To initiate a productive conversation and engage team members in understanding the "why" behind the ALM strategy, consider the following ideas:
- Host an Educational Workshop: Organize a session where team members are introduced to the key concepts of ALM in the context of the Power Platform. Use this opportunity to explain how a well-structured ALM process can streamline development, improve quality, and reduce risks.
- Facilitate a Team Discussion: Create a safe space for team members to voice their experiences, concerns, and suggestions related to ALM. Encourage sharing past challenges and successes, which can be invaluable in shaping a practical and agreeable ALM strategy.
- Present Case Studies or Scenarios: Use real or hypothetical case studies to illustrate the impacts of effective and ineffective ALM practices. This approach helps in visualizing the potential outcomes and reinforces the importance of a collaborative and well-thought-out strategy.
By engaging a team, you not only foster a sense of ownership and commitment but also build a foundation for a more effective and cohesive ALM strategy tailored to your team's unique dynamics and the specifics of the Power Platform.
One of the first conversations you should have with a team regarding setting up an ALM is around how you want to transition your products from development to your customers. Typically, a central component of this discussion is whether you want to have Development environments, Test environment and Live or Production environments (or a host of other variations).
Because the Power Platform offers none of these out of the box (you get the 'Default' environment only up front), it is an important step to take. Call the resulting decisions and agreements "having an Environment Strategy".
Having a well-thought through and defined environment strategy is crucial when setting up Application Lifecycle Management (ALM) for the Power Platform, as it lays the foundation for a structured, efficient, and controlled development process.
The Power Platform offers various types of environments (such as development, sandbox testing, and production environments), each serving a specific purpose in the application development lifecycle. Here are several key reasons why an environment strategy is essential:
- Separation of Concerns: Different environments allow for the separation of development, testing, and production activities. This separation is vital to prevent untested or in-development features from impacting the live production environment. It ensures that any development or testing activities do not interfere with the ongoing operations of the business.
- Controlled Development and Testing: An environment strategy allows for a controlled and systematic approach to development and testing. Developers can work in a dedicated development environment without the risk of affecting the live system. Similarly, a separate testing environment enables thorough testing of new features and bug fixes under conditions that closely mimic the production environment, without any risk to the live system.
- Risk Mitigation: By segregating environments, you can significantly reduce the risk of accidental changes or data breaches in the production environment. It provides a safety net, ensuring that only fully tested and approved changes are deployed to production.
- Compliance and Governance: A well-defined environment strategy aids in meeting compliance requirements and maintaining governance standards. It allows for better tracking of changes, auditing of actions, and control over who has access to sensitive data and critical systems.
- Streamlined Deployment and Rollback: With distinct environments, deploying changes becomes more manageable and less risky. If any issues are detected in the testing or staging environments, they can be addressed before reaching production. Additionally, if something goes wrong in the production environment, the previous stable version can be quickly reinstated, minimizing downtime and impact on business operations.
- Scalability and Flexibility: An effective environment strategy is scalable, accommodating the growth of your applications and processes. It provides the flexibility to adapt to changing business requirements and integrate new features or technologies without disrupting existing operations.
An environment strategy is not just a component of ALM in the Power Platform; it is a fundamental aspect that ensures development processes are efficient, controlled, and aligned with business objectives. It enhances the quality of the end product, reduces risks, and ensures that the deployment of new features and updates is a smooth, well-governed process.
Use Developer Environments To Foster 'Safe' Creativity
As someone looking to implement a level of control, it's vital to create an environment where creative thinking and experimentation is not stifled.
This first step could be to put aside the Default environment (maybe rename this to 'Personal Productivity') and create Development Environments for ever Power Platform maker. If you want to read more about how, go here.
Developer Environments unlock the ability for people to freely explore and experiment with the Power Platform tools and services or build proof of concepts and prototypes without impacting production or end users. They also carry the added benefit of zero licence costs (because they are not being used for production purposed) and allow people to create and explore without boundaries. Where licences are needed, trials can be utilised and can be extended to prove a concept or check if spend is really going to be required.
The only downside to this is that its quite easy to accidentally build and rely upon a Premium Connector (like the Power Automate one to connect to ChatGPT) without fully acknowledging the fact. However, as a trade off, with god communication around your stance on licences as a team, it is possible to minimise this risk.
Step 3 - Use Solutions
Another tool you can consider encouraging is the use of Solutions. We've got a great workshop about the what, how and why here. In short, using solutions in the Power Platform, as opposed to creating separate apps and flows, offers several key benefits that enhance the efficiency, manageability, and scalability of your applications.
Solutions in Power Platform are like containers that hold and manage all the components of a business process, offering a more holistic and integrated approach. Here are five key benefits of using solutions:
- Streamlined Management: Solutions allow you to group related components such as apps, flows, entities, and more into a single package. This unified management makes it easier to oversee, update, and maintain these components as they are not scattered but organized under one umbrella.
- Easier Deployment and Transportability: With solutions, you can easily move a set of related components from one environment to another (such as from development to testing, or testing to production). This simplifies the deployment process and ensures consistency across environments, reducing the likelihood of errors or omissions that might occur when moving components individually.
- Version Control and Tracking: Solutions support versioning, enabling you to keep track of changes, updates, and the history of your application components. This feature is crucial for maintaining control over the development lifecycle and for auditing purposes.
- Dependency Management: When you use solutions, dependencies between components are automatically managed. This ensures that all necessary components are included when a solution is moved or deployed, preventing issues related to missing dependencies that can occur in standalone apps and flows.
- Enhanced Collaboration and Governance: Solutions facilitate better collaboration among team members working on different parts of the application. It also supports governance by allowing administrators to control who can add or modify components within the solution, thereby maintaining the integrity and security of the application.
By opting for solutions over separate apps and flows, you are essentially choosing a more structured, efficient, and risk-mitigated approach to building and managing your business applications on the Power Platform. This integrated approach not only streamlines development and deployment processes but also significantly enhances the manageability and scalability of your applications.
As products and solutions mature, you may well opt to to promote them into 'higher' environments like ones dedicated to Test and Production. This creates separation for your efforts as mentioned in the environment strategy section.
This is where Power Platform "Pipelines" are a valuable tool in managing the controlled movement of Solutions between environments.
You COULD simply export and import Solutions as zip files in and out of environments but in doing so, you are missing out on some key benefits. In short, Pipelines offer a more sophisticated, reliable, and scalable approach to managing application lifecycles. Note: At the time of writing, there is a requirement for the use of Pipelines to have your target environment set up as a Managed Environment. This means there is additional control over that location. However, putting this in place is only possible with the right licence position also being in place. Find out more HERE. Put simply, if you are embarking on more formal ALM using the tools available, you will need Per User or Per App licences for your flows or Apps and to enable this feature.
A pipeline, typically part of DevOps practices, automates the deployment process, ensuring consistency, efficiency, and error reduction. This automated process is crucial for complex or frequent deployments.
Here are 3 key limitations of manual importing and exporting that a pipeline addresses:
- Lack of Continuous Integration and Continuous Deployment (CI/CD): Without a pipeline, you miss out on the benefits of CI/CD practices. Pipelines automate the integration of new products and resources. You don't have to manually select updates and re-apply them. Instead, the pipeline will move your changes to the chosen Environment without the need for much additional work. This automation not only speeds up the process but also reduces the risk of human error and ensures that changes are systematically implemented, and if you choose - tested - before deployment.
- Inefficient Environment Management: Manually importing and exporting solutions do not provide an efficient way to manage different environments (development, testing, production). A pipeline allows for a seamless and controlled flow of changes across these environments. It creates an audit trail, enforces consistency and ensures that each environment is updated in a controlled manner, following your agreed ALM process.
- Lack of Automated Testing and Quality Checks: When you manually import solutions, you bypass the opportunity for automated testing and quality checks that are part of a robust pipeline. Pipelines can be configured to automatically run tests and quality assurance checks, ensuring that only solutions that meet specific criteria are promoted to the next stage. This reduces the risk of deploying faulty or suboptimal solutions.
For point 3. It is important to say that at the time of writing, the automated Power Platform (Apps specifically) Test suit is far from perfect. However, as this matures or other options are found, having this capability can drastically reduce drag when pushing your developed products to Live and into the hands of keen customers.
When To Move To A More Mature Governance
As adoption and solution complexity increases, you may look to implement more controls or checks and balances to help you monitor how your Environment Strategy is being used. You may begin to look for anomalies or challenges to help you talk about future enhancements.
Implementing tools to monitor and measure usage should ideally be considered an ongoing process rather than a one-time effort. There are lots of tools out there to help but one we hear a lot about at the Academy - and happens to be provided by Microsoft is the "The Center of Excellence (CoE) toolkit".
This advertises itself as a comprehensive set of tools designed to help organizations maximize the value of their Power Platform investment. It can provide insights into the environments you are using, what is going on in those environments and more. The idea being that it can enable better governance and unlock continous improvement.
Being a small organisation, we have not implemented these tools ourselves but we do invite people to share their experiences and pitfalls in the Microsoft 365 Forum we offer.
Our belief however is that the CoE toolkit should be implemented once you have a basic understanding of the Power Platform environment and have started developing solutions.
It's not necessarily the first step, as initial efforts might focus more on setting up environments, basic governance, and understanding platform capabilities. However, it shouldn't be the last step either. As your organization’s use of the Power Platform matures, the CoE toolkit may become increasingly valuable so we'd recommend exploring alongside setting in motion all the other aspects we recommend in this post.
The reason being, in the middle stages of your Power Platform journey, it is likely that the number of apps and automations will grow fast. Something like the CoE toolkit could then become crucial for monitoring usage patterns, compliance, and performance metrics. It can help identify popular solutions, potential areas for optimization, and governance issues that might arise with increased usage via it's analytics.
The key lessons we wanted to share around Power Platform governance and ALM in general are:
- Start early before solutions become an intricate entanglement
- Communicate early and often to foster engagement and collaboration
- Have a Strategy for Your Environments and use Developer environments promote exploration
- Use controlled Pipelines along with Solutions to facilitate movement across phases
- Consider your more advanced oversight needs - possibly through the CoE
With the right foundation, Power Platform allows teams to build transformative solutions creatively. And innovative governance keeps things in line so you can sleep at night! Let me know if you have any other questions and get posting in the Academy with your wins!