This is a continuation of a series of articles on Microsoft Azure from an operational point of view that surveys the different services from the service portfolio of the Azure public cloud. The most recent article  discussed the Dataverse and solution layers. This document talks about managing the application lifecycle using Power Apps, Power Automate, and Microsoft Dataverse in the organization. 

Microsoft Dataverse is a data storage and management system for the various Power Applications so that they are easy to use with Power Query. The data is organized in tables some of which are built-in and standard across applications, but others can be added on a case-by-case basis for applications. These tables enable applications to focus on their business needs while providing a world-class, secure, and cloud-based storage option for the data that are 1. Easy to manage, 2. Easy to secure, 3. Accessible via Dynamics 365, has rich metadata, logic, and validation, and comes with productivity tools. Dynamics 365 applications are well-known for enabling businesses to quickly meet their business goals and customer scenarios and Dataverse makes it easy to use the same data across different applications. It supports incremental and bulk loads of data both on a scheduled and on-demand basis. 

Solutions are used to transport applications and components from one environment to another or to add customizations to an existing application. It can comprise applications, site maps, tables, processes, resources, choices, and flows. It implements Application Lifecycle management and powers Power Automate. There are two types of solutions (managed and unmanaged) and the lifecycle of a solution involves creating, updating, upgrading, and patching.  

Managed and unmanaged solutions can co-exist at different levels within a Microsoft Dataverse environment. They form two distinct layer levels. What the user sees as runtime behavior, comes from the active customizations of an unmanaged layer which in turn might be supported by a stack of one or more user-defined managed solutions and system solutions in the managed layer.  Managed solutions can also be merged. The solution layers feature enables one to see all the solution layers for a component. 

The foremost scenario for Application Lifecycle Management strategy is one that involves creating a new project.  The task involved include 1) determining the environments that are needed and establishing an appropriate governance model, 2) creating a solution and a publisher for that solution, 3) setting up the DevOps project that involves one or more pipelines to export and to deploy the solution, 4) creating a pipeline to export an unmanaged solution to a managed solution 5) configuring and building applications within the solution 6) adding any additional customizations 7) creating a deployment pipeline and granting access to the application and 8) granting access to the application. With these steps, it becomes easy to get started with dataverse solutions and applications.

The next scenario targets the legacy app makers and flow makers in Power Apps and Power Automate, respectively, who work in a Microsoft dataverse environment without a Dataverse database. The end goal, in this case, is a successful migration to a managed ALM model by creating apps and flows in a Dataverse solution. Initial app migration can target the default Dataverse environment but shipping the entities and data model require a robust DevOps with multiple environments each dedicated to the development, testing, and release of applications. It will require the same steps as in the creation of a new project but it requires the business process and environment strategy to be worked out first.