Power Platform Managed vs Unmanaged Solutions: The Complete Guide Hmm, wait — the title must be translated. Let me correct that in the output below.

By Mirko Peters · 2026-10-21

Ontdek de belangrijkste verschillen tussen beheerde en onbeheerde Power Platform-oplossingen, implementatieregels en ALM-best practices voor je apps.

Automatically translated with AI from the original post. Read the English original

Het verschil tussen beheerde en onbeheerde Power Platform-oplossingen begrijpen is essentieel om catastrofale verwijderingen van apps en mislukte implementaties te voorkomen. In deze gids lees je hoe onbeheerde lagen fungeren als je bewerkbare werkomgeving, terwijl beheerde oplossingen dienen als bevroren, implementeerbare pakketten over ontwikkel-, test- en productieomgevingen heen.

Belangrijkste punten

• Onbeheerde oplossingen zijn je werkkopie in ontwikkelomgevingen, waar je actief bouwt, bewerkt en experimenteert.
• Beheerde oplossingen zijn bevroren, implementeerbare kopieën die uitsluitend bedoeld zijn voor test- en productieomgevingen om de stabiliteit te waarborgen.
• Het verwijderen van een onbeheerde oplossing verwijdert alleen de container en laat de componenten intact, terwijl het verwijderen van een beheerde oplossing de bijbehorende aangepaste tabellen en gegevens wist.
• Je kunt een beheerde oplossing niet terug importeren in dezelfde ontwikkelomgeving waarin de bovenliggende onbeheerde oplossing is aangemaakt.
• Onbeheerde oplossingen behandelen als broncode en beheerde oplossingen als buildartefacten sluit je Power Platform-ALM aan op gangbare softwareontwikkelingspraktijken.

De kernverschillen tussen beheerde en onbeheerde oplossingen

Wanneer je begint met het bouwen van apps, flows en tabellen in Microsoft Power Platform, is het verleidelijk om omgevingen te zien als enorme digitale kladblokken. Je klikt wat rond, maakt aangepaste entiteiten aan en koppelt cloudflows rechtstreeks in een standaard- of gedeelde werkruimte. Zodra je project echter voorbij de proof-of-conceptfase komt, leidt deze losse aanpak snel tot onbeheerbare code en onbedoeld gegevensverlies. Om betrouwbare applicaties te bouwen, moet je het fundamentele onderscheid tussen onbeheerde en beheerde oplossingen beheersen.

In de kern is een oplossing simpelweg een container, een verzendmanifest dat je appcomponenten bundelt zodat ze netjes tussen omgevingen kunnen worden verplaatst. Binnen dat containerconcept zit echter een strikte tweedeling: onbeheerd versus beheerd. Deze eenvoudige zin helpt de verschillende doeleinden te onthouden: onbeheerd is om hier te bewerken, beheerd is om daar te implementeren.

Onbeheerde oplossingen: je ontwikkelwerkruimte

Een onbeheerde oplossing is je actieve, bewerkbare werkkopie. Wanneer je een canvas-app ontwerpt, bedrijfsregels schrijft of Dataverse-tabellen wijzigt, werk je binnen een onbeheerde oplossing in je ontwikkelomgeving. Elke aanpassing, kleurwijziging en schemawijziging komt meteen terecht in de onderliggende app.

Wat gebeurt er als je een onbeheerde oplossing verwijdert?

Een van de belangrijkste veiligheidskenmerken van onbeheerde oplossingen is de manier waarop ze met verwijdering omgaan. Als je een onbeheerde oplossing uit je ontwikkelomgeving verwijdert, verdwijnt alleen de container zelf. De daadwerkelijke aanpassingen, apps en tabellen die je hebt gebouwd, verdwijnen niet; ze vallen stilletjes terug in de standaardoplossing. Dit voorkomt weliswaar onbedoelde totale vernietiging tijdens de ontwikkeling, maar het kan je standaardwerkruimte vervuilen als je er niet op let.

Microsoft raadt aan om je unmanaged oplossingen rechtstreeks in een broncodebeheersysteem zoals GitHub of Azure DevOps op te slaan. Door je unmanaged oplossing als je echte broncoderepository te behandelen, houd je een volledig, historisch auditspoor bij van elke wijziging die je ontwikkelteam heeft doorgevoerd.

Managed oplossingen: je productiedeploymentpakket

Managed oplossingen zijn de afgeronde, gecompileerde en bevroren versie van je applicatie. Je bewerkt een managed oplossing niet rechtstreeks. In plaats daarvan exporteer je je unmanaged oplossing als managed en deploy je dat pakket naar omgevingen die verderop in het traject liggen, zoals User Acceptance Testing (UAT), System Integration Testing (SIT) en uiteindelijk productie.

De grote risico's van het verwijderen van een managed oplossing

Anders dan hun unmanaged tegenhangers zijn managed oplossingen bij ontwerp streng afgeschermd. Je kunt onderdelen binnen een managed oplossing niet rechtstreeks bewerken. En wat nog belangrijker is: het verwijderen van een managed oplossing heeft precies het omgekeerde effect van een unmanaged oplossing. Omdat alles in het pakket aan die specifieke deployment is gekoppeld, verwijdert het verwijderen van de oplossing al haar onderdelen.

Deze verwijdering bij het de-installeren omvat ook alle gegevens die zijn opgeslagen in aangepaste tabellen die deel uitmaakten van de oplossing, evenals gegevens in aangepaste kolommen die aan bestaande tabellen zijn toegevoegd. Zodra een managed oplossing uit een omgeving is verwijderd, zijn de bijbehorende gegevens definitief weg. Er is geen ingebouwde ongedaan-knop, waardoor het begrijpen van je deploymentarchitectuur een cruciale beheertaak is.

Omgevingsarchitectuur en testregels

De technische werking van Power Platform dwingt strikte grenzen tussen omgevingen af als het gaat om hoe je met deze twee typen oplossingen omgaat. Zo kun je een managed oplossing niet terugimporteren in dezelfde ontwikkelomgeving die de unmanaged oplossing bevat waarmee je haar hebt gebouwd. Een managed deployment testen vereist een volledig aparte omgeving. Daarom schrijven best practices voor om vanaf dag één een speciale pipeline met meerdere omgevingen op te zetten.

Een gezonde ALM-opzet (Application Lifecycle Management) bestaat uit minimaal drie afzonderlijke omgevingen:

• Ontwikkeling: Hier bouwen makers unmanaged oplossingen en passen ze die aan.
• Test (UAT): Hier importeer je de managed oplossing om aan te tonen dat zowel het deploymentproces als de werking van de app correct verlopen.
• Productie: Hier vertrouwen echte gebruikers elke dag op de stabiele, bevroren managed oplossing.

Je Power Platform-deploymentstrategie onder de knie krijgen

Een strikte scheiding tussen unmanaged ontwikkelwerkruimten en managed productiedeployments maakt van je Power Platform-strategie geen verzameling fragiele oplossingen, maar professionele softwareontwikkeling op enterprise-niveau. Door oplossingsgrenzen te respecteren, je productieomgevingen te beschermen tegen ad-hocwijzigingen en gezonde gewoonten voor broncodebeheer aan te houden, zorg je ervoor dat je bedrijfskritieke applicaties stabiel en veerkrachtig blijven naarmate ze groeien.

Wil je nog dieper ingaan op de werking van Power Platform-onderdelen, uitgevers, prefixen en oplossingslagen? Luister de volledige aflevering en abonneer je op de podcast voor doorlopende inzichten in het Microsoft-cloudecosysteem.