Model-driven Lab 01 — IT Service Desk

Part 01: Understanding Dataverse Solutions, Publishers, and Application Lifecycle Management (ALM)

1. Introduction

Microsoft Power Apps Model-driven applications provide a structured and metadata-driven approach to developing enterprise business applications using Microsoft Dataverse as the underlying data platform.

Unlike Canvas apps, where developers control the positioning and behavior of individual interface elements, Model-driven apps generate much of their interface from Dataverse metadata, including tables, columns, relationships, forms, views, and business processes.

This architecture makes Model-driven apps particularly suitable for enterprise applications involving structured business information, complex data relationships, role-based security, and standardized business processes.

In this technical laboratory series, we will develop an IT Service Desk application from scratch, gradually exploring the native capabilities of Microsoft Dataverse and Model-driven apps before introducing more advanced customization using JavaScript, C#, and Power Automate.

The application will eventually support incident registration, ticket assignment, prioritization, status tracking, service management, and operational reporting.

Before creating tables or designing forms, however, we must understand how Microsoft Power Platform organizes, manages, and deploys application components.

Three fundamental concepts form the foundation of this architecture:

• Solutions
• Publishers
• Application Lifecycle Management (ALM)

2. Understanding Microsoft Power Platform Solutions

A Solution is a logical container used to organize, transport, and manage application components within Microsoft Power Platform.

Solutions can include Dataverse tables, columns, relationships, forms, views, Model-driven apps, business rules, business process flows, cloud flows, security roles, JavaScript web resources, and C# plugin assemblies.

A Solution does not represent a separate database. Its components exist within a Power Platform environment, and the Solution provides a mechanism for organizing and managing them throughout the application lifecycle.

Conceptual architecture:

Power Platform Environment
│
├── Dataverse Database
│
└── IT Service Desk Solution
    │
    ├── Dataverse Tables
    ├── Columns and Relationships
    ├── Model-driven Application
    ├── Forms and Views
    ├── Business Rules
    ├── Business Process Flows
    ├── JavaScript Web Resources
    └── C# Plugins

This diagram represents logical organization rather than separate physical storage.

By grouping application components into a Solution, developers can manage changes, track dependencies, and prepare components for deployment between environments.

3. Managed and Unmanaged Solutions

Microsoft Power Platform supports two primary Solution types: Managed and Unmanaged.

Unmanaged Solutions are primarily used during development. They allow developers to create and modify components directly within the development environment.

Managed Solutions are primarily used to distribute and deploy applications into controlled environments, such as testing and production.

For the IT Service Desk laboratory, we will begin with an Unmanaged Solution.

Later, when exploring ALM, we will study how to export a Managed Solution and deploy it to another environment.

4. Understanding Publishers

Every Solution is associated with a Publisher.

A Publisher identifies the organization or developer responsible for the solution’s customizations and establishes important naming conventions.

One of its most important properties is the Customization Prefix.

For example, consider the following Publisher configuration:

If we create a Dataverse table named Ticket using this Publisher, the resulting schema name might be:

itsd_Ticket

Its logical name would typically be:

itsd_ticket

The customization prefix provides several benefits:

• Identifies custom components created by a particular Publisher.
• Reduces naming conflicts between solutions.
• Establishes consistent naming conventions.
• Helps distinguish custom components from standard Dataverse components.
• Improves maintainability in environments containing multiple business applications.

Important: Changing the Publisher later does not automatically rename previously created Dataverse components.

For this reason, Publisher configuration should be considered an architectural decision rather than a minor administrative setting.

For our laboratory, we will use the proposed prefix itsd.

5. Understanding Application Lifecycle Management (ALM)

Application Lifecycle Management refers to the processes used to develop, test, deploy, maintain, and evolve business applications.

In Microsoft Power Platform, ALM includes:

• Environment management
• Solution management
• Source control
• Versioning
• Dependency management
• Automated deployment
• Testing and validation
• Security and governance

A typical enterprise application lifecycle involves three environments:

DEVELOPMENT
    │
    │ Unmanaged Solution
    │
    ▼
Solution Export
    │
    ▼
TEST
    │
    │ Managed Solution
    │
    ▼
Validation and Approval
    │
    ▼
PRODUCTION
    │
    │ Managed Solution
    │
    ▼
Business Users

In this architecture, developers create and modify application components in the Development environment.

Changes are packaged and deployed to Test for validation before being promoted to Production.

Microsoft Power Platform also provides Pipelines to support structured deployment processes.

6. Understanding Solution Versioning

Solutions use a four-part version number.

For example:

1.0.0.0

A recommended versioning convention is:

This interpretation is a recommended convention rather than a meaning automatically enforced for each position.

Versioning becomes increasingly important when applications involve multiple developers, environments, releases, and deployment cycles.

7. Applying These Concepts to Our IT Service Desk

Our first implementation will establish the technical foundation for the application.

We will create the Publisher and Solution before introducing custom Dataverse tables.

This approach will help keep the application organized and prepare the project for future ALM exercises.

As the laboratory progresses, we will explore how Dataverse metadata controls the Model-driven interface, how JavaScript extends client-side form behavior, and how C# plugins implement server-side business logic.

8. Official Microsoft Documentation

The following Microsoft Learn resources provide the technical foundation for this article.

Solutions Overview
https://learn.microsoft.com/en-us/power-apps/maker/data-platform/solutions-overview

Create a Solution
https://learn.microsoft.com/en-us/power-apps/maker/data-platform/create-solution

Application Lifecycle Management Overview
https://learn.microsoft.com/en-us/power-platform/alm/overview-alm

Solution Concepts for ALM
https://learn.microsoft.com/en-us/power-platform/alm/solution-concepts-alm

Model-driven App Overview
https://learn.microsoft.com/en-us/power-apps/maker/model-driven-apps/model-driven-app-overview

9. Conclusion

Solutions are a foundational element of professional Microsoft Power Platform development.

They provide a structured mechanism for organizing application components, supporting deployment between environments, and establishing the foundation for Application Lifecycle Management.

Publishers complement this architecture by defining customization naming conventions and identifying the origin of custom components.

For our IT Service Desk project, understanding these concepts before creating the first Dataverse table will help us build a maintainable application with a clear path from development to production.

In the next part of this series, we will explore the creation of a custom Publisher and an Unmanaged Solution through the Power Apps Maker Portal, examining the available configuration options and their architectural implications.