Onboarding isn’t just about signing forms and introducing a new member to your team; it’s about integrating them into your build environment, processes, practices and tools in the most effective way.
Having a process to allow a new member to become familiar with your approaches without disrupting the current flow of other work is invaluable as their learning curve to becoming a productive member of the team in your context will be much shorter and there is likely to be less friction.
When it comes to Power Apps on the Power Platform, one of the more important decisions where a new team member should start to work. You will need to decide your environment strategy for this case.
As a team leader, you have the power to define and streamline this process. Let's explore how.
1. Power Platform: A Quick Recap for Team Leaders
Power Platform is Microsoft’s integrated no code/low code application platform, allowing teams to build, analyse, and automate. Power Apps, a key component, empowers teams to create custom business apps without the heavy coding. In the same way, Power Automate is one of the more often used services and allows workflow and task automation using a simple drag and drop interface. But where should your new member begin their development?
2. One Way - 'Here's Our Default Environment'
Whenever a new team member wants to do some work with the Power Platform, they will be working within what's called an Environment.
"Environments represent space to store, manage, and share your organization's business services and data".
Environments might have different roles, security requirements, and target audiences. Individual environments aren't created by the product you build in the Power Platform, instead; they're created in a separate location.
After you have created an individual environment, your Power Platform products can be created and effectively coupled to that environment. You can have different "Types" of environment as well.
The main ones used to be:
Default - the default location where all your Apps and Flows are created as a team unless you take other specific actions. Every tenant will have one and only one of these (hence you dont see them as an option on the right).
Sandbox - Intended as an "Integration environment" where work from different people comes together to be tested or worked upon.
Production - This is where your live Production ready apps and flows should go. Whatever is here needs to be robust, governed and above all secure.
Developer - Now as you see at the top of the list, we have a new great option. More on why in a moment.
Previously, the simplest route was to add new members to a "Default" environment or a shared "Sandbox". These both have perks:
- Immediate Integration: Members got a quick feel of existing projects. They can explore freely. It is easy to follow the flow of existing work from one App to the Flow it links to and so forth.
- Collaboration: New members could directly collaborate with other team members and effectively share a workspace.
However, these shared and combined locations have pitfalls:
- Conflict Risks: Multiple developers in a sandbox for example might overwrite or conflict with each other’s work.
- Limited Exploration: New people may hesitate to experiment in shared spaces, fearing they might break something The sheer volume of what's there might make navigating a little daunting also (especially if you are a mature team).
3. The New & Improved Way: Developer Environments
Here's where Microsoft have given us a new tool to help. Developer Environments. These can shine by giving new starters a safe place to begin, explore and help you assess where they are up to. Other people can be added to these as well if you require a 'mentor' style overview or solution reviews.
Here's what you, as a team leader, would need to do:
- Navigate to the Power Platform admin center.
- Create a new 'Developer' environment.
A few pointers here to get the maximum benefit:
- Tip: Choose a US Region. They tends to get new changes first.
- Tick the box to Create on behalf if you want to open up unfettered access to all the Power Platform can offer without it being tied to your normal licence.
- This is effectively giving a new developer licence to someone. Ideal for training and development. (note: solutions made here may not be compatible with your own main tenant licence position to beware).
Once the environment has been given a name and provisioned.
- Assign your new team member.
- As you do this, you'll note the option to do this under a developer licence. This is an awesome new addition as it essentially lets you create without limits. Of course there is a trade off. Whatever you make here will not necessarily be compatible with the licences you own in the 'real' world but its a great place to begin, to assess and learn.
Benefits:
- Personalized Workspace: Your new member gets a personal space to build, test, and learn.
- No Overlaps: Say goodbye to the risk of conflicting changes.
- Freedom to Experiment: New team members can try out features without any reservations.
- Isolation: Mistakes won’t cascade into your production or main testing environment.
5. Making the Decision: Which Environment is Right?
As a team leader, consider:
- Nature of the Project: If it's a mature project, a Developer Environment allows the new member to get acquainted without disruptions.
- Experience Level: For absolute beginners, the isolation of Developer Environments is invaluable. They can fiddle, break things, and learn – all without consequences.
- Team Size: Larger teams mean higher chances of conflicts in shared environments. Developer Environments can alleviate this.
Conclusion:
Your decision on the onboarding environment can significantly impact a new team member's confidence, productivity, and integration. By understanding the benefits of Developer Environments, you can ensure they start on the right foot, equipped with the best tools at their disposal