Power Platform: Verwaltete vs. nicht verwaltete Lösungen – der vollständige Leitfaden

Von Mirko Peters · 2026-10-21

Erfahren Sie die entscheidenden Unterschiede zwischen verwalteten und nicht verwalteten Power Platform-Lösungen, die Regeln für die Bereitstellung und die ALM-Best Practices für Ihre Apps.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Der Unterschied zwischen verwalteten und nicht verwalteten Power Platform-Lösungen ist entscheidend, um katastrophale Löschungen von Apps und fehlgeschlagene Bereitstellungen zu verhindern. Dieser Leitfaden zeigt, wie nicht verwaltete Ebenen als bearbeitbarer Arbeitsbereich dienen, während verwaltete Lösungen als eingefrorene, bereitstellbare Pakete über Entwicklungs-, Test- und Produktionsumgebungen hinweg funktionieren.

Das Wichtigste in Kürze

• Nicht verwaltete Lösungen sind Ihre Arbeitskopie in Entwicklungsumgebungen, in denen Sie aktiv entwickeln, bearbeiten und experimentieren.
• Verwaltete Lösungen sind eingefrorene, bereitstellbare Kopien, die ausschließlich für Test- und Produktionsumgebungen gedacht sind, um die Stabilität zu gewährleisten.
• Das Löschen einer nicht verwalteten Lösung entfernt nur den Container, die Komponenten bleiben erhalten. Das Deinstallieren einer verwalteten Lösung dagegen löscht die zugehörigen benutzerdefinierten Tabellen und Daten.
• Sie können eine verwaltete Lösung nicht in dieselbe Entwicklungsumgebung zurückimportieren, in der ihre nicht verwaltete Ausgangslösung erstellt wurde.
• Wenn Sie nicht verwaltete Lösungen wie Quellcode und verwaltete Lösungen wie Build-Artefakte behandeln, richtet sich Ihr Power Platform-ALM nach gängigen Praktiken der Softwareentwicklung aus.

Die Kernunterschiede zwischen verwalteten und nicht verwalteten Lösungen

Wenn Sie beginnen, Anwendungen, Flows und Tabellen in Microsoft Power Platform zu erstellen, liegt es nahe, Umgebungen wie riesige digitale Notizblöcke zu behandeln. Sie klicken sich durch, erstellen benutzerdefinierte Entitäten und verknüpfen Cloud-Flows direkt in einer Standardumgebung oder einem gemeinsam genutzten Arbeitsbereich. Sobald Ihr Projekt jedoch die Phase des Machbarkeitsnachweises hinter sich lässt, führt dieser lockere Ansatz schnell zu schwer wartbarem Code und versehentlichem Datenverlust. Um zuverlässige Anwendungen zu entwickeln, müssen Sie den grundlegenden Unterschied zwischen nicht verwalteten und verwalteten Lösungen beherrschen.

Im Kern ist eine Lösung schlicht ein Container, eine Art Versandliste, die Ihre App-Komponenten bündelt, damit sie sauber zwischen Umgebungen verschoben werden können. Innerhalb dieses Containerprinzips gibt es jedoch eine klare Zweiteilung: nicht verwaltet versus verwaltet. Dieser einfache Satz hilft, ihre unterschiedlichen Zwecke zu verstehen: Nicht verwaltet dient zum Bearbeiten hier, verwaltet dient zum Bereitstellen dort.

Nicht verwaltete Lösungen: Ihr Entwicklungsarbeitsbereich

Eine nicht verwaltete Lösung ist Ihre aktive, bearbeitbare Arbeitskopie. Immer wenn Sie eine Canvas-App entwerfen, Geschäftsregeln schreiben oder Dataverse-Tabellen ändern, arbeiten Sie in Ihrer Entwicklungsumgebung innerhalb einer nicht verwalteten Lösung. Jede Anpassung, jede Farbänderung und jede Schemaänderung wirkt sich sofort auf die zugrunde liegende App aus.

Was passiert, wenn Sie eine nicht verwaltete Lösung löschen?

Eine der wichtigsten Sicherheitseigenschaften nicht verwalteter Lösungen ist das Verhalten beim Löschen. Wenn Sie eine nicht verwaltete Lösung aus Ihrer Entwicklungsumgebung löschen, verschwindet nur der Container selbst. Die eigentlichen Anpassungen, Apps und Tabellen, die Sie erstellt haben, bleiben erhalten; sie werden stattdessen unbemerkt in die Standardlösung übernommen. Das verhindert zwar eine versehentliche vollständige Zerstörung während der Entwicklung, kann Ihren Standardarbeitsbereich aber unübersichtlich machen, wenn Sie nicht aufpassen.

Microsoft empfiehlt, nicht verwaltete Lösungen direkt in Quellcodeverwaltungssystemen wie GitHub oder Azure DevOps einzuchecken. Wenn Sie Ihre nicht verwaltete Lösung als maßgebliches Quellcode-Repository behandeln, behalten Sie einen vollständigen, lückenlosen Verlauf jeder Änderung, die Ihr Entwicklungsteam vornimmt.

Verwaltete Lösungen: Ihr Bereitstellungspaket für die Produktion

Verwaltete Lösungen sind die fertige, kompilierte und eingefrorene Version Ihrer Anwendung. Sie bearbeiten eine verwaltete Lösung nicht direkt. Stattdessen exportieren Sie Ihre nicht verwaltete Lösung als verwaltete Lösung und stellen dieses Paket in nachgelagerten Umgebungen bereit, etwa für User Acceptance Testing (UAT), System Integration Testing (SIT) und schließlich die Produktion.

Die hohen Risiken beim Löschen einer verwalteten Lösung

Anders als ihre nicht verwalteten Gegenstücke sind verwaltete Lösungen von Haus aus stark gesperrt. Sie können Komponenten innerhalb einer verwalteten Lösung nicht direkt bearbeiten. Entscheidend ist außerdem: Die Deinstallation einer verwalteten Lösung bewirkt das genaue Gegenteil des Verhaltens einer nicht verwalteten Lösung. Da alles im Paket an diese spezifische Bereitstellung gebunden ist, entfernt das Entfernen der Lösung sämtliche ihrer Komponenten.

Wichtig: Zu dieser Entfernung gehören auch Daten in benutzerdefinierten Tabellen, die Teil der Lösung waren, sowie Daten in benutzerdefinierten Spalten, die zu vorhandenen Tabellen hinzugefügt wurden. Sobald eine verwaltete Lösung aus einer Umgebung deinstalliert ist, sind die zugehörigen Daten dauerhaft verloren. Es gibt keine native Rückgängig-Funktion. Deshalb ist das Verständnis Ihrer Bereitstellungsarchitektur eine zentrale administrative Verantwortung.

Umgebungsarchitektur und Testregeln

Die Mechanik der Power Platform erzwingt strikte Umgebungsgrenzen im Umgang mit diesen beiden Lösungstypen. So können Sie beispielsweise eine verwaltete Lösung nicht in dieselbe Entwicklungsumgebung zurückimportieren, in der sich die nicht verwaltete Lösung befindet, aus der Sie sie erstellt haben. Um eine verwaltete Bereitstellung zu testen, benötigen Sie eine völlig separate Umgebung. Deshalb empfehlen bewährte Methoden, von Anfang an eine eigene Pipeline mit mehreren Umgebungen einzurichten.

Ein solides, praxistaugliches ALM-Setup (Application Lifecycle Management) umfasst mindestens drei getrennte Umgebungen:

• Entwicklung: Hier erstellen und ändern Maker nicht verwaltete Lösungen.
• Test (UAT): Hier importieren Sie die verwaltete Lösung, um nachzuweisen, dass sowohl der Bereitstellungsprozess als auch die Funktionalität der App korrekt arbeiten.
• Produktion: Hier verlassen sich die Benutzer täglich auf die stabile, eingefrorene verwaltete Lösung.

Die Power Platform-Bereitstellungsstrategie im Griff

Eine konsequente Trennung zwischen nicht verwalteten Entwicklungsumgebungen und verwalteten Produktionsbereitstellungen verwandelt Ihre Power Platform-Strategie von einer Sammlung fragiler Notlösungen in professionelle Softwareentwicklung auf Unternehmensniveau. Wenn Sie Lösungsgrenzen respektieren, Ihre Produktionsumgebungen vor spontanen Änderungen schützen und saubere Gewohnheiten in der Quellcodeverwaltung pflegen, stellen Sie sicher, dass Ihre geschäftskritischen Anwendungen auch mit wachsenden Anforderungen stabil und belastbar bleiben.

Wenn Sie noch tiefer in die Mechanik der Power Platform-Komponenten, Herausgeber, Präfixe und Lösungsebenen eintauchen möchten, hören Sie sich die vollständige Episode an und abonnieren Sie den Podcast für laufende Einblicke in das Microsoft-Cloud-Ökosystem.