Governance im großen Maßstab: Was unser Webinar-Publikum wirklich wissen wollte
Unser Webinar der vergangenen Woche, „The COE Is Dead. Who’s Governing Your Power Platform Now?”, hat viele Fragen von Teilnehmenden aus Finanzdienstleistung, professionellen Dienstleistungen, Behörden und Enterprise-IT ausgelöst. Die Menge und die Genauigkeit dieser Fragen erzählten ihre eigene Geschichte: Organisationen sorgen sich nicht abstrakt um die Abkündigung des COE. Sie arbeiten gerade jetzt an konkreten operativen Problemen.
Dieser Beitrag behandelt die eingegangenen Fragen, gruppiert nach den Themen, die während der Session immer wieder auftauchten. Wenn Sie zunächst den strategischen Kontext möchten, lesen Sie Who’s Governing Your Power Platform Now That Microsoft’s COE Starter Kit Is Gone?, bevor Sie hier tiefer einsteigen.
Wie tief reicht das Inventar tatsächlich?
Die häufigste Kategorie von Fragen betraf das Inventar in Rencore Governance: was es erfasst, wie aktuell es ist und ob es die Teile des Microsoft-Ökosystems abdeckt, auf die es am meisten ankommt.
Zur Aktualität: Das Inventar in Rencore ist nicht in Echtzeit. Rencore Governance nutzt dieselben Graph-API-Endpunkte, die jede mit Microsoft verbundene Anwendung verwendet, und Microsoft wendet auf diese Aufrufe Drosselungsgrenzen an. Da Rencore Governance sehr viele Informationen bis auf die Ebene einzelner Dateien über viele verschiedene Dienste hinweg sammelt (Teams, SharePoint, OneDrive, Entra ID, Power Apps, Power Automate, Power BI, Copilot, Copilot Studio usw.), ist es für größere Microsoft 365 Tenants für keinen Anbieter außer Microsoft technisch möglich, all diese Daten live zu beziehen. Was ein Inventar in Governance-Qualität von einem einmaligen Scan unterscheidet, ist der Umgang mit Aktualisierungen. Rencore liest Audit-Logs und Änderungsereignisse fortlaufend, sodass die Daten aktuell bleiben, ohne für die Datenaktualität auf vollständige Neuscans angewiesen zu sein, und das im Rahmen der verfügbaren API-Aufrufe. In der Praxis ist dies für Governance-Zwecke keine Einschränkung, die die Ergebnisse beeinflusst. Bei Governance geht es darum, Leitplanken automatisch durchzusetzen, nicht darum, einen Live-Feed zu beobachten. In der Realität sind die Daten in der Regel bis zu 24 Stunden alt, selbst in Tenants mit mehr als 100.000 Nutzern. Anders als andere Lösungen in diesem Bereich erlaubt Ihnen Rencore, die Aktualisierungsfrequenz sehr granular zu konfigurieren, damit die relevantesten Daten so frisch wie möglich sind.
Zur Tiefe: Ein Teilnehmer fragte, ob die Datenquelle dieselbe ist wie beim COE. Das ist sie. Beide Werkzeuge lesen aus der Graph API. Der Unterschied liegt im Datenmodell, das aus dieser Quelle entsteht. Rencore erfasst Metadaten in einer viel feineren Granularität, einschließlich Berechtigungen und zugehöriger Metadaten in anderen Objekten, und bildet die Beziehungen zwischen Objekten auch dienstübergreifend ab. Das bedeutet, dass eine Administratorin oder ein Administrator nicht nur sieht, dass ein Flow existiert, sondern auch, wem er gehört, in welcher Umgebung er läuft, welche Connectors er nutzt, aus welcher SharePoint-Site er liest und ob auf diese Site eine Vertraulichkeitsbezeichnung angewendet ist.
Zur Abdeckung von Agenten: Zwei Fragen kamen ausdrücklich zu Agenten. Copilot Studio Agents werden heute vollständig unterstützt, einschließlich Metadaten zur Erstellung, Wissensquellen, Topics, Actions und Konversationsaktivität. Besonders nützlich wird das Beziehungsmodell bei der dienstübergreifenden Risikoerkennung: Ein Agent, der eine SharePoint-Site mit einer vertraulichen Vertraulichkeitsbezeichnung nutzt und über einen Teams-Kanal mit externen Gästen zugänglich ist, ist ein Compliance-Risiko, das das Zusammenführen von Datenpunkten über drei verschiedene Dienste hinweg erfordert. Genau das soll das Datenmodell von Rencore sichtbar machen.
Microsoft Scout Agents und Microsoft Cowork werden noch nicht unterstützt, weil Microsoft dafür keine öffentlichen APIs veröffentlicht hat. Allerdings hat Microsoft etwa drei Wochen vor dem Webinar eine API für Agent Builder Agents veröffentlicht, und Rencore ergänzt diese Abdeckung derzeit aktiv. Während Microsoft sein Agenten-Ökosystem weiter ausbaut, wächst die Governance-Reichweite mit. Das Muster, dass Microsoft neue Fähigkeiten veröffentlicht, bevor die Governance-Werkzeuge nachziehen, ist nicht neu, aber es beschleunigt sich.
Richtlinien, Automatisierungen und Erweiterbarkeit
Mehrere Teilnehmende kamen aus Organisationen, die auf dem COE Starter Kit eigene Governance-Aktionen aufgebaut hatten, und wollten wissen, ob sich diese Workflows nachbilden lassen. Die Antwort ist ja, und der Mechanismus ist die Automatisierungs-Engine von Rencore.
Die Rencore-Engine baut nicht auf Power Automate auf. Das war eine bewusste Architekturentscheidung. Power Automate zu nutzen, um die Power Platform zu regeln, erzeugt eine Abhängigkeit von genau der Plattform, die geregelt werden soll, was zu Komplikationen bei Zuverlässigkeit und Lizenzierung führt sowie das Risiko birgt, dass die Erkennung eines Richtlinienverstoßes und dessen Behebung auseinanderfallen. Die Automatisierungs-Engine von Rencore Governance ist unabhängig, benötigt keine Power-Platform-Lizenzen und kann Power-Automate-Flows per Webhook auslösen, wenn eine Organisation die beiden Systeme verbinden möchte.
Zur Frage, ob sich von Erstellern verlangen lässt, sich zu registrieren oder eine Freigabe einzuholen, bevor sie etwas bauen: Das ist über eine Kombination aus Richtlinien und der Rencore Teams App erreichbar. Wird eine neue App oder ein neuer Flow erkannt, kann eine Richtlinie eine Automatisierung auslösen, die den Ersteller benachrichtigt, eine Freigabeanfrage weiterleitet und die Antwort erfasst. Was nicht möglich ist, ist das Abfangen der Erstellung genau in dem Moment, in dem sie in Power Apps oder Power Automate stattfindet, da Microsoft dieses Ereignis nicht für Drittwerkzeuge zugänglich macht. Das Provisioning von Flows und Apps über Rencore, das eine Freigabe vor der Erstellung erlauben würde, steht auf der Roadmap, ist aber produktiv noch nicht verfügbar.
Benachrichtigungen können per E-Mail, Teams-Nachricht oder Webhook an jedes externe System gesendet werden. Der Nachrichteninhalt unterstützt dynamische Platzhalter, die mit Inventar-Metadaten gefüllt werden, sodass Benachrichtigungen konkrete Details zu der Ressource enthalten können, die die Richtlinie ausgelöst hat. Für alles, was nicht nativ abgedeckt ist, schließt ein Webhook oder eine HTTP-Anfrage an eine Azure Function die Lücke.
Eine öffentliche API für Rencore Governance ist in Entwicklung. Die erste Version erlaubt externen Systemen, Automatisierungen auszulösen, was den Anwendungsfall abdeckt, den ein Teilnehmer schilderte: ein Registrierungssystem in einer externen Plattform, das einen Compliance-Workflow in Rencore anstößt, sobald ein Asset dort freigegeben wurde. Drosselung ist hier eine praktische Erwägung, die Rencore aus denselben Gründen betrifft wie Microsoft, weshalb die API zunächst auf Automatisierungsauslöser beschränkt startet, nicht auf direkten Inventarzugriff. Dieser Umfang wird mit der Zeit wachsen.
Ownership, Lebenszyklus und das Offboarding-Problem
Eine Frage, die zu weiterer Diskussion führte, war, ob Flows und Apps übertragen werden können, wenn ein Nutzer die Organisation verlässt. Ownership kann bei Standard-Power-Automate-Flows (nicht nur bei lösungsbewussten Flows) über eine Automatisierung ergänzt oder geändert werden. In Kombination mit einer Lebenszyklus-Richtlinie bedeutet das, dass eine Organisation automatisch Flows erkennen kann, deren Besitzer nicht mehr aktiv sind, eine Anfrage zur Neuzuweisung an einen bestimmten Admin oder eine Gruppe weiterleiten und die Lösung ohne manuelles Eingreifen der Administration dokumentieren kann. Dieselbe Logik gilt für jede Ressource mit einem Besitzer: Teams, SharePoint-Sites, Power Apps, Agenten.
Ein weiteres praktisches Szenario war die Abhängigkeitsprüfung vor dem Löschen. Bevor eine SharePoint-Site entfernt wird, muss eine Administratorin oder ein Administrator wissen, welche Flows, Berichte oder Agenten von ihr abhängen. Dieser Abhängigkeitsgraph ist in Rencore abfragbar, und es lässt sich eine Richtlinie bauen, die diese Verbindungen sichtbar macht und eine Bestätigung oder Freigabe verlangt, bevor eine Außerbetriebnahme fortgesetzt wird.
Die Frage nach der Kritikalität von Apps ist es wert, im Detail behandelt zu werden, weil sie eine echte Reifegrad-Herausforderung in der Governance widerspiegelt. Rencore kann Metadaten über eine App oder einen Flow erfassen, und eine Automatisierung lässt sich so konfigurieren, dass sie den Besitzer mit einer strukturierten Frage anspricht, etwa ob der Prozess geschäftskritisch ist, und die Antwort in ein benutzerdefiniertes Metadatenfeld zurückspeist. Diese benutzerdefinierten Metadaten können dann als Bedingung in künftigen Richtlinien verwendet werden. Das erfordert Konzeptionsarbeit, aber die Fähigkeit ist vorhanden. Derselbe Mechanismus lässt sich nutzen, um die Zuordnung zu Kostenstellen, die Zugehörigkeit zu Geschäftsbereichen oder jede andere organisatorische Taxonomie zu erfassen, die auf das technische Inventar abgebildet werden muss.
Das Lebenszyklus-Management für Power-Platform-Umgebungen, einschließlich Provisioning, wird aktiv entwickelt. Das Provisioning von Teams, SharePoint, Viva Engage und Planner ist live. Das Provisioning von Power-Platform-Umgebungen kommt. Die Zuweisung von Kapazität zu Umgebungen, etwa die Zuteilung von Copilot-Credits oder Dataverse-Speicher, ist noch nicht verfügbar und hängt davon ab, dass Microsoft die relevanten APIs bereitstellt.
Daten zur Ausführungshistorie von Power Automate Flows werden von Rencore unbegrenzt aufbewahrt. Microsofts native Ausführungshistorie in Power Automate wird nach 30 Tagen gelöscht. Für Organisationen, die Audit-Anfragen über Zeiträume von mehr als einem Monat erfüllen müssen, macht dieser Unterschied erheblich etwas aus.
Datenresidenz, Sicherheit und Self-Hosting
Mehrere Teilnehmende fragten, ob Daten ihren Tenant verlassen und wo sie gespeichert werden. Diese Frage kam von Teilnehmenden aus dem Finanz- und Behördensektor, was damit übereinstimmt, wo Anforderungen an die Datenresidenz tendenziell am strengsten sind.
Rencore Governance sammelt ausschließlich Metadaten. Keine Dateiinhalte, keine Nachrichtentexte, keine von Nutzern erstellten Inhalte werden übertragen. Die erfassten Metadaten wandern in eine dedizierte Azure-Ressourcengruppe pro Kunde, verschlüsselt mit einem kundenspezifischen Schlüssel. Das Zustimmungsmodell ist granular: Administratoren können zunächst je Dienst lesenden Zugriff gewähren und Schreibberechtigungen schrittweise ergänzen, während sie ihren Einsatz von Automatisierungen und Lebenszyklus-Aktionen ausweiten. Speziell für die Power Platform stellt Microsoft für Drittwerkzeuge noch keine Anwendungsberechtigungen bereit, weshalb für diesen Dienst ein dediziertes Power-Platform-Administratorkonto erforderlich ist, getrennt von jeder globalen Administratorrolle.
Zu den Hosting-Regionen gehören derzeit die USA, Deutschland, die Schweiz, die Niederlande und Australien, weitere Regionen kommen hinzu. Für Organisationen mit regulatorischen Anforderungen, die das Anbinden an einen SaaS-Dienst gänzlich untersagen, wird Self-Hosting in der eigenen Azure-Subscription des Kunden unterstützt. Das ist vor allem für Finanzinstitute und Behörden relevant, die unter Datensouveränitätsauflagen arbeiten, einschließlich derjenigen, die DORA- oder NIS2-Pflichten unterliegen.
Multi-Tenant, Lizenzierung und die Frage nach dem Umfang
Für Managed Service Provider ist Rencore Governance multi-tenant-fähig. Jeder Kunde kann ein eigener Workspace sein, und innerhalb eines Workspace lassen sich mehrere Tenants gemeinsam verwalten. Die Person, die das Werkzeug betreibt, muss kein Nutzer in den verwalteten Tenants sein, da Rencore über Anwendungsberechtigungen arbeitet, die in jedem Kunden-Tenant gewährt werden. Das bedeutet, dass ein MSP-Administrator sich mit dem eigenen Organisationskonto in Rencore anmelden und zwischen Kundenumgebungen wechseln kann, ohne in jeder ein Konto zu besitzen. Richtlinien, Berichte, Dashboards und Automatisierungskonfigurationen lassen sich aus einer Umgebung exportieren und in eine andere importieren, was das Erstellen standardisierter Governance-Vorlagen über ein Kundenportfolio hinweg praktikabel macht.
Ein Teilnehmer brachte einen Punkt vor, der hervorzuheben ist: Das Werkzeug fühle sich nach mehr an als nach einer Power-Platform-Lösung. Das ist es auch. Dasselbe Rahmenwerk aus Inventar, Richtlinien und Automatisierung deckt Teams, SharePoint, Exchange, Entra, OneDrive, Viva Engage, Planner, Power BI, Copilot Studio und die gesamte Power Platform ab. Die Governance-Probleme, die die Abkündigung des COE zutage fördert, sind real, aber sie sind auch Symptome einer breiteren Herausforderung: Mit zunehmender Komplexität von Microsoft 365 wird der Bedarf an einer einheitlichen Governance-Ebene über alle seine Dienste hinweg, nicht nur die Power Platform, immer schwerer zu ignorieren.
Die Lizenzierung erfolgt pro Microsoft 365 lizenziertem Nutzer und ist in drei Modulen strukturiert: ein Collaboration-Paket für die zentralen M365-Dienste, ein Power-Platform-Modul, das Power Apps, Power Automate und Power BI ergänzt, und ein Copilot-und-Agenten-Modul für Copilot Studio und Agent Builder. Funktionen wie Provisioning können je nach Anforderung ergänzt oder ausgenommen werden. Für einen Richtwert, der zur Größe Ihrer Organisation passt, wenden Sie sich direkt an uns.
Wenn Sie die Live-Session verpasst haben, sind Aufzeichnung und Folien hier verfügbar. Falls Sie teilgenommen haben und eine Frage nicht beantwortet wurde, kontaktieren Sie uns direkt.
Weiterführende Lektüre: Für die strategische Begründung, warum die Abkündigung des COE zählt und was zu tun ist, lesen Sie Who’s Governing Your Power Platform Now That Microsoft’s COE Starter Kit Is Gone? Bereit, Rencore Governance in Ihrer eigenen Umgebung zu sehen? Buchen Sie ein 30-minütiges Gespräch.
Zuletzt aktualisiert am 23. Juni 2026
