First of all, we have to establish an understanding of some important terminology when it comes to Power Platform. Those terms will be used throughout the rest of the book.

Tenant

A tenant defines the boundaries of everything an organization is doing with Microsoft. It can contain Azure components, Power Platform components, SharePoint, and a lot more.

Multiple tenants

Some organizations do have multiple tenants. This can have several reasons, such as separation for dev, test, and prod, or because parts of the company were acquired, for example.

Environment

In Power Platform, an environment is a space where one can store, manage, and share data, as well as business logic in the form of, for example, apps, flows, or chatbots.

There can be several environments within a Microsoft tenant.

Organizations can choose to have different environments for different countries, Apps, departments, or stages in a development process. We will learn more about environments...

ALM in Power Platform is not fundamentally different from “normal” ALM, as described in Chapter 1, but in addition to what already has been described, there are some things to watch out for.

The main problem people have a hard time wrapping their heads around is the fact that in a “normal” implementation project, everything is done through some form of code, which is controlled through source control. In Power Platform, configuration and customization are done in an environment, which, on its own, isn’t directly related to any form of source control.

Source code

There is a new feature in the current Release 2024 Wave 2 Plan, which describes a native Git integration to Azure DevOps. This is a promising feature that could solve parts of the problems we have when it comes to ALM in Power Platform.

In Chapter 7, we will learn an approach for establishing such a connection to source control...

While planning a solution, selecting the correct solution is crucial. It also tremendously affects the ALM process, which must be established. In this section, we will explain different solution levels. The idea is to always select the lowest level when possible and only go to the next level in case we can’t implement a requirement with the current level. This means for every requirement we would start with the question “Can I implement this using Configuration?” if the answer is no we ask “Can I implement this using noncomplex Customization?” and so on.

Configuration

Configuration is, as mentioned, everything we can configure in the environment with out-of-the-box features without changing existing features or creating new ones.

This can be, for example, system settings or server-side sync.

Configuration is the first level and whenever a requirement can be implemented with “just” configuration, that should...

In this chapter, we learned about important terminology when it comes to Power Platform.

We also talked about the difference between “normal” ALM and ALM in Power Platform. The biggest problem is to understand where which change is done and how it relates to a proper development process.

Lastly, we learned about different solution levels and why they are important for laying out a matching ALM process for a project.

The next chapter will go into detail about environments in Power Platform and why they are a crucial part of the ALM process.

1. What is the first solution level?
   1. Development
   2. Noncomplex customization
   3. Configuration
2. What describes the upcoming features for Power Platform?
   1. Release wave
   2. Release plan
   3. Early access
3. Which difference between “normal” ALM and Power Platform ALM is usually the hardest to understand?
   1. Most changes are not done in code
   2. A Power Platform solution only contains a small amount of custom code
   3. Challenges associated with how Microsoft has implemented some features

Connect your environment to source control: https://learn.microsoft.com/en-us/power-platform/release-plan/2024wave1/power-apps/connect-environment-source-control