12 Min. Lesezeit

Power Platform Governance 2026: Vom CoE Starter Kit ins Admin Center

Power Platform Governance 2026: Vom CoE Starter Kit ins Admin Center

Über Jahre war das CoE Starter Kit das Schweizer Taschenmesser für Power-Platform-Governance. Microsoft baut diese Funktionen jetzt nativ ins Power Platform Admin Center ein – und das Juni-2026-Feature-Update setzt mit Connector-Governance und KI-Leitplanken noch einen drauf. Wir ordnen die Migration ein und zeigen, warum das nicht nur ein Admin-Thema ist, sondern direkt eure Projektarbeit und euer Projekt- und Portfoliomanagement (PPM) betrifft.

Das Wichtigste in Kürze

  • Das CoE Starter Kit wird nicht mehr weiterentwickelt; seine Kernfunktionen stehen nativ im Power Platform Admin Center bereit – in den Bereichen Inventory, Usage, Monitor und Actions.
  • Advanced Connector Policies (allgemein verfügbar seit Juni 2026) steuern einzelne Connector-Aktionen und MCP-Server; BYO MCP und die MCP-Zertifizierung regeln, welche Werkzeuge Agenten überhaupt nutzen dürfen.
  • Microsoft Entra Agent ID für Dataverse (Public Preview seit 6. August 2026) gibt jedem Agenten eine eigene Identität mit eng geschnittener Security-Rolle.
  • Zentrale Authentifizierungsrichtlinien für Agenten (Public Preview seit 31. Mai 2026) und das Agentic CoE waren laut Release Plan für September 2026 angekündigt; Stand 1. Oktober 2026 führt Microsoft die Authentifizierungsrichtlinie weiterhin als Preview.
  • Seit September 2026 sind die Connector-Rechte eines Copilot-Studio-Agenten als API-Berechtigungen an seiner Entra Agent ID sichtbar und per Conditional Access steuerbar – vorerst nur für Agenten in Microsoft Teams.
  • Seit Oktober 2026 (Preview) lassen sich Governance-Fragen zum Tenant im Klartext über das Plugin Power Platform Admin in Microsoft Copilot Cowork stellen – lesend, mit Freigabe vor sensiblen Aktionen und mit Copilot-Credit-Verbrauch.
  • PPM-Lösungen wie Altus PPM und Projectum xPM laufen als Model-driven Apps auf Dataverse und erben diese Governance, sobald sie in einer Managed Environment betrieben werden.

Das CoE Starter Kit hat ausgedient – Governance wird zum Produkt

Das Center of Excellence (CoE) Starter Kit war nie ein offizielles Produkt, sondern eine Sammlung von Apps, Flows und Power-BI-Dashboards, die ein Unternehmen selbst installieren, betreiben und aktuell halten musste. Genau das ändert sich jetzt: Microsoft pflegt das Kit nicht mehr aktiv weiter – es gibt keine neuen Features und keine Bugfixes mehr, und auch gemeldete Issues werden nicht mehr bearbeitet. Stattdessen verlagert Microsoft die Kernfunktionen direkt in das Power Platform Admin Center (PPAC) als native In-Product-Erlebnisse.

Für Plattform-Verantwortliche ist das eine gute Nachricht: Governance hört auf, ein selbst gebautes Nebenprojekt zu sein, und wird zu einer gewarteten, supporteten Plattform-Fähigkeit. Wer das CoE Starter Kit heute noch produktiv nutzt, sollte zeitnah einen Migrationsplan in Richtung PPAC aufsetzen – das Kit bleibt zwar lauffähig, läuft aber ohne Weiterentwicklung auf eine technische Sackgasse zu.

Die vier nativen Governance-Erlebnisse im Admin Center

Die ehemaligen CoE-Kernaufgaben finden sich heute in vier Bereichen des Admin Centers wieder:

Inventory – ein tenant-weiter Überblick über alle Apps, Flows und Agents. Die Inventory-Experience hat die alten CoE-Inventory-Flows abgelöst und zeigt Canvas-, Model-driven-, Code- und Vibe-Apps, Cloud Flows sowie Agents aus Copilot Studio und dem Microsoft 365 Copilot Agent Builder – inklusive Besitzer und genutzter Connectoren.

Usage – Adoptionsdaten, um Top-Ressourcen und ihre Owner zu erkennen. Monitor – der operative Gesundheitszustand stark genutzter Ressourcen. Actions – eine zentrale Stelle, um Risiken zu erkennen, Best Practices durchzusetzen und Governance-Maßnahmen auszulösen.

Wichtig für die Berechtigungsplanung: Diese Erlebnisse setzen eine tenant-weite Entra-Rolle voraus. Global Administrator, Power Platform Administrator, Dynamics 365 Administrator und Global Reader sehen den vollständigen Bestand; die Rollen AI Administrator und AI Reader sind auf die KI-bezogenen Ressourcen beschränkt. Die rollenbasierten Power-Platform-Rollen (RBAC) genügen dafür nicht, und reine Environment-Admins oder Endanwender sehen die Erlebnisse nicht.

Im direkten Vergleich:

AspektCoE Starter KitPower Platform Admin Center
BereitstellungSelbst installierte Sammlung aus Apps, Flows und Power-BI-DashboardsNative In-Product-Erlebnisse, von Microsoft betrieben
WeiterentwicklungKeine neuen Features, keine Bugfixes, Issues werden nicht mehr bearbeitetLaufende Investitionen von Microsoft
BestandsübersichtEigene Inventory-FlowsInventory für Apps, Flows, Agents und Connectoren; Änderungen innerhalb von 15 Minuten sichtbar
Nutzung, Betrieb, MaßnahmenDashboards und Apps des KitsUsage, Monitor und Actions
AutomatisierungAnpassung der Kit-FlowsPower Platform CLI, Power Platform API, Inventory API, Power Platform for Admins V2 Connector

Neu im Juni 2026: Connector-Transparenz und Advanced Connector Policies

Das Juni-2026-Update macht Governance spürbar schärfer. Seit Anfang Juni erfasst das Inventory in der Public Preview jeden genutzten Connector und jede Connector-Operation – über Canvas- und Model-driven Apps, Cloud Flows, Agent Flows und Agents hinweg. Eine neue Connector-Spalte erscheint dafür in allen Inventory-Grids, auch in den ressourcenspezifischen Ansichten unter Power Apps, Power Automate und Copilot Studio. Ein Opt-in ist nicht nötig – die Daten fließen automatisch ein.

Das verändert die Praxis: Bei einer Connector-Deprecation, einem Security-Vorfall oder einer geänderten Lizenzstufe lässt sich in Sekunden ermitteln, welche Ressourcen betroffen sind. Dieselben Daten sind zudem programmatisch abfragbar – über den Power-Platform-for-admins-V2-Connector, die Inventory-API und Azure Resource Graph –, sodass tenant-weite Analysen zu einer einzigen Abfrage werden.

Parallel sind die Advanced Connector Policies (ACP) jetzt allgemein verfügbar. Damit lässt sich nicht mehr nur ein Connector als Ganzes erlauben oder sperren, sondern es lässt sich steuern, welche konkreten Aktionen und MCP-Server innerhalb eines Connectors von Apps und KI-Tools genutzt werden dürfen – ein wichtiger Baustein, sobald Agents externe Dienste ansprechen.

Neu im Juli 2026: MCP-Governance für Agenten-Tools

Mit dem Model Context Protocol (MCP) verbinden sich Copilot Studio, Microsoft 365 Copilot und Coding-Agents zunehmend über einen einheitlichen Standard mit internen Systemen und Partner-Tools. Im Juli-2026-Update zu Dataverse als Agenten-Datenplattform zieht Microsoft die Governance-Klammer um diese wachsende MCP-Landschaft enger: Mit Bring Your Own MCP (BYO MCP) können Unternehmen eigene, interne MCP-Server – etwa für proprietäre Systeme oder Fachanwendungen – registrieren und unter denselben Governance-Regeln betreiben wie den offiziellen MCP-Katalog: mit Admin-Freigabe, Sichtbarkeit und zentraler Kontrolle. Parallel schafft die MCP-Zertifizierung für ISVs und Partner einen vertrauenswürdigen Weg in das Microsoft-Ökosystem, sodass zertifizierte Partner-MCPs in Copilot Studio und Azure AI Foundry auffindbar, geprüft und governance-konform nutzbar werden.

Für die Governance-Praxis schließt das eine Lücke, die die Advanced Connector Policies allein nicht abdecken: Es geht nicht mehr nur darum, welche Connector-Aktionen ein Agent nutzen darf, sondern auch darum, welche selbst betriebenen oder von Partnern stammenden MCP-Server als Werkzeuge für Agenten überhaupt zugelassen sind. Wer PPM-Lösungen oder eigene Agenten auf Dataverse betreibt und diese perspektivisch an weitere Tools anbinden will, sollte BYO MCP und MCP-Zertifizierung von Anfang an in die Governance-Strategie einplanen.

Neu im August 2026: Jeder Agent bekommt eine eigene Identität

Am 6. August 2026 hat Microsoft mit Microsoft Entra Agent ID für Dataverse den nächsten Baustein in die Public Preview gebracht – und damit die vielleicht grundlegendste Frage der Agenten-Governance beantwortet: Wer ist der Agent eigentlich? Bisher greifen Agenten häufig über eine geteilte App-Registrierung oder eine generische Automatisierungs-Identität auf Geschäftsdaten zu. Mit Entra Agent ID erhält stattdessen jeder Agent eine eigene, richtlinienkontrollierte Identität mit eigenen Berechtigungen und eigenem Audit-Trail.

Das Gegenstück auf Datenebene sind die neuen Dataverse-Agent-Users: Der Admin legt im Ziel-Environment einen Agent-User an, verknüpft ihn mit der Entra-Identität des Agenten und weist ihm eine dedizierte Security-Rolle nach dem Least-Privilege-Prinzip zu. Damit lassen sich fünf Dinge sauber trennen, die bisher verschwammen – die Authentifizierung des Agenten als eigenständiger Akteur, die Autorisierung auf genau die benötigten Tabellen und Felder, die Funktionstrennung gegenüber menschlichen Nutzern und klassischen Integrationen, die Nachvollziehbarkeit einzelner Datenänderungen sowie der Lebenszyklus vom Anlegen bis zur Außerbetriebnahme.

Mitte September 2026 hat Microsoft zudem dokumentiert, wie die Connector-Rechte eines Agenten an seiner Identität sichtbar werden: Beim Veröffentlichen eines Copilot-Studio-Agenten hängt die Plattform für jeden konfigurierten Power-Platform-Connector eine API-Berechtigung an dessen Entra Agent ID – für den ganzen Connector oder nur für die tatsächlich genutzten Aktionen. Entra- und Microsoft-365-Admins sehen damit im Entra Admin Center, was ein Agent aufrufen kann, und können diese Berechtigungen per Conditional Access an Netzwerkstandort, Gerätekonformität oder Risikostufe knüpfen. Was zur Laufzeit erlaubt ist, entscheiden weiterhin die Advanced Connector Policies und Data Policies, gegen die die Connector-Plattform jeden Aufruf erneut prüft. Zwei Einschränkungen gehören in die Planung: Conditional Access auf der Agenten-Identität greift derzeit nur, wenn der Agent in Microsoft Teams läuft, und Custom Connectors, MCP-Server und REST-API-Tools erzeugen noch keine solchen Berechtigungen.

Damit schließt sich die Governance-Kette der vergangenen Monate: Die Advanced Connector Policies regeln, welche Aktionen ein Agent aufrufen darf; BYO MCP und die MCP-Zertifizierung, welche Werkzeuge zugelassen sind – und Entra Agent ID beantwortet, wer handelt und welche Daten dieser Akteur sehen und ändern darf. Für PPM-Umgebungen auf Dataverse ist das unmittelbar relevant: Sobald Agenten Projektstatus auswerten, Risiken bewerten oder Zeitbuchungen anstoßen, sollten sie nicht mit den weitreichenden Rechten ihres Erstellers laufen, sondern mit einer eng geschnittenen eigenen Rolle. Weil die Funktion noch Preview ist, empfiehlt Microsoft den Einstieg in einer Nicht-Produktivumgebung mit einem klar abgegrenzten Szenario – ein guter Anlass, Fachverantwortung, Zweck und Außerbetriebnahme jedes Agenten von Anfang an zu dokumentieren.

Ebenfalls im August 2026: Die Datenebene gehört zur Agenten-Governance

Kurz darauf hat Microsoft am 11. August 2026 den Blick von den Agenten auf die Daten gelenkt, auf die diese Agenten zugreifen. Der Kern des Arguments: Sobald Agenten Datensätze nicht mehr nur lesen, sondern laufend anlegen und ändern, wird schlechte Datenhygiene zum Risiko. Veraltete, inaktive oder unvollständige Datensätze verursachten früher vor allem Speicherkosten – jetzt fließen sie in Antworten und automatisierte Aktionen ein.

Microsoft benennt fünf Dataverse-Stellschrauben, die Administratoren bewusst setzen sollten: das Kapazitäts-Reporting im Admin Center, um Wachstum auf einzelne Environments und Tabellen zurückzuführen; Long-Term Retention für Datensätze, die aus Audit- oder Compliance-Gründen verfügbar bleiben müssen, ohne aktiv mitzulaufen; ein Wiederherstellungsfenster von 1 bis 30 Tagen für gelöschte Datensätze als Sicherheitsnetz vor Aufräumaktionen; Security-Rollen nach dem Least-Privilege-Prinzip; und Dataverse-Auditing als Nachweis wesentlicher Änderungen. Dazu kommt ein klares Betriebsmodell: Die Plattform-Administration definiert die Richtlinie je Datensatztyp und Verwendungszweck, die Fachverantwortlichen klassifizieren Zweck, Sensibilität und Aufbewahrungsbedarf.

Für PPM-Umgebungen auf Dataverse ist das keine graue Theorie. Projektakten, Aufgaben, Risiken und Zeitbuchungen wachsen über Jahre, unterliegen häufig einer Aufbewahrungspflicht und enthalten personenbezogene Daten. Wer Agenten auf diesen Bestand loslässt, sollte vorher geklärt haben, welche Projektdaten aktiv bleiben, welche in die Langzeitaufbewahrung wandern, wer sie sehen darf und wie sich eine versehentliche Massenlöschung rückgängig machen lässt.

Neu im September 2026: Zentrale Authentifizierungsrichtlinien für Agenten

Ergänzend zur Frage "Wer ist der Agent?" beantwortet eine neue Sicherheitsfunktion im Admin Center, wie sich ein Agent überhaupt anmelden darf. Unter Security > Identity and access > Authentication for agents legen Administratorinnen und Administratoren je Environment oder Environment-Gruppe zentral fest, welche Authentifizierungsmethoden Ersteller ihren in Copilot Studio konfigurierten Agenten zuweisen dürfen – von „No authentication" (anonymer Zugriff erlaubt) über „Require Microsoft authentication" und „Require Entra authentication" bis „Allow all supported authentication methods" (Microsoft- oder manuelle Entra-ID-Anmeldung, aber kein anonymer Zugriff). Die Richtlinie greift sowohl beim Publizieren als auch zur Laufzeit: Ein bereits veröffentlichter Agent, der nicht mehr der aktuellen Vorgabe entspricht, wird für weitere Veröffentlichungen gesperrt und antwortet Nutzenden nicht mehr, bis die Authentifizierung wieder konform ist.

Die Funktion befindet sich seit dem 31. Mai 2026 in der Public Preview; die allgemeine Verfügbarkeit war laut Release Plan für September 2026 vorgesehen. Stand 1. Oktober 2026 kennzeichnet die Microsoft-Dokumentation die Funktion weiterhin als Preview – vor dem Einsatz in produktiven PPM-Umgebungen lohnt daher ein Blick auf den aktuellen Status. Für PPM-Umgebungen schließt das eine Lücke, die Entra Agent ID allein nicht abdeckt: Entra Agent ID regelt, mit welcher Identität und welchen Berechtigungen ein Agent auf Dataverse zugreift – die neue Authentifizierungsrichtlinie stellt zusätzlich sicher, dass niemand anonym oder über einen nicht genehmigten Anmeldeweg mit einem Agenten interagiert, der Projektstatus, Risiken oder Zeitbuchungen verarbeitet.

Neu im Oktober 2026: Governance-Fragen im Klartext mit Power Platform Admin in Cowork

Microsoft beschreibt in einer dreiteiligen Anleitung, wie Administratoren Governance-Fragen zum Tenant in natürlicher Sprache stellen können: Das Plugin Power Platform Admin in Microsoft Copilot Cowork (Preview) liefert Inventar-, Nutzungs- und Eigentümerdaten über alle Environments hinweg – etwa zu Apps ohne Nutzung in den letzten 30 Tagen oder zu Ressourcen, deren Besitzer das Unternehmen verlassen hat. Cowork kann die Antwort in einen Bericht überführen, eine Nachricht an den Ressourcenbesitzer entwerfen oder die Frage regelmäßig wiederholen und fragt vor sensiblen Aktionen wie dem Versand einer E-Mail nach Freigabe. Das Plugin liefert ausschließlich lesende Einblicke und führt keine Administrationsaktionen selbst aus; Microsoft versteht den Ansatz als Ergänzung zur bestehenden Governance-Strategie (Agentic governance with Power Platform Admin in Cowork).

Für die Planung: Zugriff haben Global-, Power-Platform- und Dynamics-365-Administratoren, Managed Environments sind für die Fragen nicht erforderlich. Jede Frage verbraucht Copilot Credits – Microsoft empfiehlt einen einmonatigen Pilot mit zwei bis drei Szenarien und Ausgabenrichtlinien im Microsoft 365 Admin Center. Die Antworten sind KI-generiert und können variieren; sie sollten geprüft werden, bevor Richtlinien geändert oder Maker kontaktiert werden.

Managed Environments, Security und DLP als Fundament

Unter den vier Erlebnissen liegt das Fundament aus Managed Environments, Data-Loss-Prevention-Richtlinien (DLP) und dem Security-Bereich des Admin Centers. Managed Environments bündeln Sicherheits- und Monitoring-Fähigkeiten auf Plattformebene – von DLP-Policies über Sharing-Limits bis zu Nutzungs-Insights. Der Security-Bereich liefert zusätzlich datengetriebene Empfehlungen, um die Sicherheitslage gezielt zu verbessern.

Für die Praxis heißt das: Governance ist kein einzelnes Dashboard mehr, sondern ein zusammenhängender Stack – Inventarisierung, Connector-Transparenz, Identität, Daten, Nutzung, Betrieb, Maßnahmen und Sicherheit greifen ineinander.

Besonderer Fokus: Model-driven Apps und KI-Agenten

Spannend wird es dort, wo Microsoft 2026 am stärksten investiert: bei Model-driven Apps und generativer KI. Microsoft 365 Copilot Chat in Model-driven Apps erlaubt es Anwendern, direkt in der App Fragen zu stellen, über In-App-Daten zu reasonieren und Erkenntnisse aus Dokumenten und Kommunikation zu verbinden – ohne die Anwendung zu verlassen. Dabei lassen sich First-Party-Agents wie Researcher und Analyst ebenso einbinden wie eigene Copilot-Studio-Agents. Governance-seitig ist das sauber gedacht: Admins konfigurieren das Feature pro Environment, Maker entscheiden anschließend pro App, ob Copilot Chat aktiv ist.

Bei der Agent-Governance des Release Wave 1 2026 zieht Microsoft die Zügel weiter an. Im Rollout sind unter anderem: Admin-Kontrollen für die Agent-Sicherheit, Echtzeit-Risikobewertung schon in Copilot Studio (statt erst nach dem Deployment), das Tracking inaktiver oder unveröffentlichter Agents, das Monitoring von Entra App IDs gegen Identity-Sprawl sowie ein Copilot-Credit-Tracking pro Environment mit Pay-as-you-go-Caps, um Kostenrisiken einzudämmen. Hinzu kommt das Agentic Center of Enablement (Agentic CoE), das laut Release-Plan im September 2026 in die Public Preview gehen sollte (Stand 1. Oktober 2026 ist die Auslieferung dort noch nicht als erfolgt markiert): Drei KI-Agents im Admin Center – Highlights, Insights und Action Plan – liefern tägliche Tenant-Snapshots, priorisieren Governance-Risiken automatisch und schlagen Remediation-Pläne mit vollständigem Audit-Trail vor, die Admins vor der Ausführung freigeben. Das Agentic CoE gehört zur Managed Platform und wird für Administratoren mit mindestens einer Managed Environment im Tenant automatisch aktiviert – ein Opt-in gibt es nicht. Der rote Faden: KI wird in der Power Platform nicht als Spielwiese, sondern als kontrolliert verwaltete Unternehmensfähigkeit behandelt – inventarisiert, identifizierbar, abgesichert und budgetiert wie jede andere Ressource.

Ein Hinweis zur Planung: Den Release-Plan in dieser Form gibt es zum letzten Mal. Ab September 2026 veröffentlicht Microsoft neue Funktionen für Power Platform, Dataverse und Dynamics 365 nicht mehr in halbjährlichen Release Waves, sondern fortlaufend in der AI at Work Roadmap; die bestehenden Release-Pläne bleiben nur noch als historische Referenz erreichbar. Was das für die Planung im PMO bedeutet – und welche Einstellung im Admin Center daraus folgt –, steht in Microsoft Retires Release Waves: How Your PMO Plans Platform Change in 2026 (in englischer Sprache).

Warum das ein PPM-Thema ist – zwei Perspektiven

Auf den ersten Blick klingt das nach reinem Plattform-Admin-Stoff. Tatsächlich entscheidet diese Governance-Architektur aber darüber, wie tragfähig eure Projektarbeit auf der Power Platform ist. Zwei Blickwinkel lohnen sich.

Perspektive 1: Vom Tool-Wildwuchs zur integrierten Projektsteuerung

Die typische Realität im IT-Projektmanagement: Für die operative Arbeit laufen Planner, Azure DevOps und Jira parallel, Projektanträge stecken in Excel-Dateien oder SharePoint-Listen, und die Ressourcenplanung verteilt sich auf weitere Dokumente. Das Ergebnis ist Tool-Wildwuchs ohne den übergreifenden Überblick – weder über das Portfolio noch über die Auslastung der Teams.

Genau hier setzen professionelle PPM-Lösungen auf der Power Platform an. Altus PPM und Projectum xPM laufen als Model-driven Apps auf Dataverse, integrieren Planner, Azure DevOps und Jira und überführen die bislang dokumentenbasierten Bausteine – von Projektanträgen bis zur Ressourcenplanung – in die Power Platform. Damit werden die verstreuten Insellösungen zu einem zusammenhängenden, governance-fähigen Portfolio-Management. Und weil die Lösung in einer Managed Environment läuft, erbt sie automatisch Inventory, Connector-Transparenz, DLP und die KI-Leitplanken aus dem Admin Center – Governance muss nicht nachgerüstet werden, sondern ist von Anfang an das Fundament.

Perspektive 2: Unterschiedliche Abteilungen, ein gemeinsamer Rahmen

Selten lassen sich die Anforderungen aller Abteilungen mit einem einzigen Werkzeug abdecken. Microsoft Planner ist bewusst einfach gehalten und wird deshalb von vielen Fachabteilungen bevorzugt – für die Softwareentwicklung ist es aber zu schlank; dort spielen Jira und Azure DevOps ihre Stärken aus. Dazu kommen klassische Projektpläne, Anträge und Ressourcenübersichten, die jeweils eigene Tools mitbringen. Diese Heterogenität ist normal und sinnvoll – jedes Team arbeitet mit dem, was zu seiner Arbeitsweise passt.

Was fehlt, ist die Ebene darüber: ein Werkzeug, das diese Daten zusammenführt und einen einheitlichen Rahmen schafft – eine echte Project Governance über alle Abteilungen hinweg. Genau das leisten Altus PPM und Projectum xPM. Als Model-driven Apps auf Dataverse konsolidieren sie die Informationen aus den verschiedenen operativen Tools zu einem gemeinsamen Portfolio-Bild und legen einheitliche Standards für Status, Priorisierung, Ressourcen und Reporting darüber.

Weil das auf Dataverse läuft, fügt sich diese Governance-Ebene nahtlos in den Stack ein, den das Admin Center jetzt bereitstellt: tenant-weites Inventory, Connector-Transparenz, Agenten-Identitäten, Managed Environments, DLP und Security-Empfehlungen greifen ebenso wie für jede andere Power-Platform-Lösung. Für IT-Verantwortliche heißt das: Die PPM-Lösung ist keine weitere Insel, sondern der integrierende Baustein – und gleichzeitig sauber in das bestehende Microsoft-Verwaltungs- und Sicherheitsmodell eingebettet. Das vereinfacht auch die Ablösung von Project Online und das Gespräch mit Datenschutz, Security und Lizenzmanagement.

Fazit

Die Migration des CoE Starter Kits ins Power Platform Admin Center ist mehr als Aufräumen: Governance wird zur gewarteten Plattformfähigkeit – und mit Connector-Transparenz, Advanced Connector Policies, MCP-Governance, schärferen KI-Leitplanken, eigenen verwalteten Identitäten für KI-Agenten und zuletzt einer geordneten Datenebene darunter reift sie von Juni bis August 2026 sichtbar weiter. Wer seine Projektarbeit und sein PPM auf Dataverse und Managed Environments stellt, baut nicht gegen diese Entwicklung, sondern auf ihr auf – und gewinnt eine Governance-konforme PPM-Lösung mit Kontrolle, Sicherheit und Zukunftsfähigkeit in einem.

Häufige Fragen zur Power-Platform-Governance

Muss ich das CoE Starter Kit sofort deinstallieren?
Nein. Es bleibt lauffähig, wird aber nicht mehr weiterentwickelt und erhält keine Bugfixes mehr. Ein Migrationsplan in Richtung Power Platform Admin Center sollte trotzdem zeitnah aufgesetzt werden, weil die nativen Erlebnisse Inventory, Usage, Monitor und Actions inzwischen mehr leisten als das Kit.

Welche Berechtigung brauche ich, um Inventory, Usage, Monitor und Actions im Admin Center zu sehen?
Eine tenant-weite Entra-Rolle: Global Administrator, Power Platform Administrator, Dynamics 365 Administrator oder Global Reader für den vollständigen Bestand, AI Administrator bzw. AI Reader nur für die KI-bezogenen Ressourcen. Reine Environment-Admins oder Endanwender sehen diese Erlebnisse nicht.

Was regelt die neue Authentifizierungsrichtlinie für Agenten, und wie unterscheidet sie sich von Entra Agent ID?
Sie legt je Environment fest, welche Anmeldemethoden ein Agent überhaupt nutzen darf – etwa kein anonymer Zugriff –, während Entra Agent ID die Identität und Berechtigungen des Agenten selbst regelt. Beide Kontrollen ergänzen sich: Die eine entscheidet, wie sich jemand anmeldet, die andere, was der angemeldete Agent darf.

Was passiert mit Projektdaten in Dataverse, wenn Agenten sie laufend verändern?
Microsoft empfiehlt Kapazitäts-Reporting, Long-Term Retention für aufbewahrungspflichtige Datensätze, ein Wiederherstellungsfenster von 1 bis 30 Tagen, Security-Rollen nach dem Least-Privilege-Prinzip und Dataverse-Auditing als Nachweis wesentlicher Änderungen. Die Fachverantwortlichen klassifizieren dabei Zweck, Sensibilität und Aufbewahrungsbedarf je Datensatztyp.

Ersetzt eine PPM-Lösung wie Altus PPM oder Projectum xPM das CoE Starter Kit?
Nein, beide adressieren unterschiedliche Ebenen. Das Admin Center governt die Power-Platform-Umgebung als Ganzes; Altus PPM und Projectum xPM sind Model-driven Apps auf Dataverse, die als Fachanwendung von dieser Governance profitieren, sie aber nicht ersetzen.

Wie Holert beim Thema Power-Platform-Governance unterstützt

In der Praxis scheitert Power-Platform-Governance selten an den Funktionen im Admin Center, sondern an der Zuständigkeit. Inventory-Auswertungen, Connector-Richtlinien, Agenten-Identitäten und Aufbewahrungsregeln setzen Entscheidungen voraus, die zwischen IT-Betrieb, Security, Datenschutz und PMO liegen – keine dieser Rollen kann sie allein treffen. Wird das nebenbei erledigt, entsteht ein halb konfigurierter Tenant: Apps, Flows und Agents laufen weiter, aber niemand kann ihr Risiko belastbar beurteilen.

Genau für diese Aufgabe haben wir unser Paket Power Apps Governance & Managed Services geschnürt – entweder als einmaliges Governance-Setup oder als laufenden Managed Service. Holert begleitet IT- und PMO-Teams beim Aufbau einer tragfähigen Power-Platform-Governance: vom Governance-Assessment der bestehenden Umgebung über die Definition einer Environment- und ALM-Strategie, die Einrichtung von Managed Environments, DLP- und Connector-Richtlinien bis zur Ablösung des CoE Starter Kits durch die nativen Admin-Center-Erlebnisse. Dazu definieren wir Leitplanken für Model-driven Apps und Copilot-/KI-Agenten – von Agenten-Identitäten und Berechtigungen über Datenaufbewahrung und Credit-Limits bis zum laufenden Monitoring. Methodisch arbeiten wir auf Basis von PMI und SAFe, technisch im Microsoft- und Atlassian-Umfeld; seit über 25 Jahren implementieren wir Projekt- und Portfoliomanagement-Lösungen für PMOs und VMOs – unter anderem für Rohde & Schwarz, KUKA und Amer Sports. Stimmen dieser Kunden findet ihr unter Referenzen.

Auf diesem Fundament richten wir Governance-konforme PPM-Lösungen wie Altus PPM oder Projectum xPM auf Dataverse so ein, dass sie sauber in eure bestehende Microsoft-Architektur passen – inklusive Migration von Project Online und Anbindung an Planner. Mehr dazu auf der Seite Power Apps Governance & Managed Services. Ob einmaliges Assessment, Migrationsfahrplan oder dauerhafte Betreuung: Schreibt uns über unser Kontaktformular, und wir finden gemeinsam den passenden Einstieg.

Projektmanagement mit künstlicher Intelligenz von Microsoft und Atlassian (KI) im PMO

Projektmanagement mit künstlicher Intelligenz von Microsoft und Atlassian (KI) im PMO

Erfahren Sie, wie KI von Microsoft und Atlassian das Projektmanagement revolutioniert und alltägliche Aufgaben für Projektleiter erleichtert.

Read More
Copilot Cowork: Was die neue KI-Funktion für das Projektmanagement bedeutet

Copilot Cowork: Was die neue KI-Funktion für das Projektmanagement bedeutet

Copilot Cowork delegiert mehrstufige Aufgaben an KI-Agenten. Was das für PMOs bedeutet, wie MCP externe Systeme anbindet und warum Altus PPM die...

Read More
Microsoft Scout im PMO: Wenn der Projektassistent autonom mitarbeitet

Microsoft Scout im PMO: Wenn der Projektassistent autonom mitarbeitet

Microsoft Scout – jetzt Microsoft Autopilot – im PMO: Was der autonome Agent übernimmt und wie er per MCP an Altus PPM, xPM, SAP und Personio kommt.

Read More