Microsoft stellt vibe.powerapps.com und den App Builder Agent in Microsoft 365 Copilot zum 30. November 2026 ein. Im deutschsprachigen Raum scheint die Meldung bisher fast vollständig untergegangen.

Das Abschalten einer Preview ist für sich keine Nachricht. Interessant ist der Nachfolger: Eine neue App-Plattform mit eigener Verwaltung, eigenem Abrechnungsmodell – und einem Verständnis von „Produktion“, das aktuell mit allem bricht, was wir in der Power Platform bisher als gute Praxis gelernt haben.

Ich habe ihn diese Woche in unserem eigenen Tenant ausprobiert. Dieser Artikel fasst zusammen, was in der Dokumentation steht – und was man erst sieht, wenn man selbst klickt.

Was abgeschaltet wird

Laut Message-Center-Meldung MC1505609:

Ab Mitte Oktober 2026 lassen sich über den App Builder Agent und vibe.powerapps.com keine neuen Apps mehr anlegen.
Zum 30. November 2026 werden beide Oberflächen eingestellt. Nicht migrierte Apps sind darüber nicht mehr erreichbar.
Die Migration liegt bei euch.

Prüft den Wortlaut im eigenen Message Center.

Wer vibe nie freigegeben hat, ist fein raus. Es gab gute Gründe dagegen: Vibe war Preview, lief nicht in der Default-Umgebung und war nur in den Regionen USA, Australien, Asien und Indien verfügbar. Für einen deutschen Tenant hieß eine Freigabe also: Umgebung außerhalb der EU.

Achtung beim App Builder Agent: Der lief in Microsoft 365 Copilot, nicht in Power Apps. Seine Apps liegen in einer versteckten, für den Tenant reservierten Umgebung, ihre Daten in SharePoint-Listen. Ob es solche Apps gibt, zeigt das Power Platform Admin Center unter Manage → Power Apps → App Inventory.

Der Nachfolger: Drei Wege, eine Plattform

Microsoft konsolidiert das App-Bauen per natürlicher Sprache:

Weg	Für wen	Status
Apps in Copilot Studio	Maker	Public Preview, standardmäßig an
App-Skill in Copilot Cowork	Business-User	Nur im Frontier-Programm
CLI `ms`	Entwickler, code-first	Preview, standardmäßig aus

Alle drei erzeugen dasselbe: Eine App auf der Copilot Managed Runtime. Das ist keine Power App. Sie wird im Microsoft 365 Admin Center verwaltet, läuft unter managedapps.cloud.microsoft und wird über Copilot Credits abgerechnet. Das Planen, Bauen, Benutzen. Alles.

Ausprobiert: Was im Test passiert ist

1. Ohne Credits baut niemand

Mein erster Prompt endete mit:

„No usage quota is available for your account … Your organization hasn't set up a pool of credits yet.“

„Standardmäßig an“ heißt in der Praxis: Solange niemand im Tenant Copilot Credits bereitstellt, kann auch niemand bauen. Eine eingebaute Bremse – die allerdings verschwindet, sobald jemand Credits für irgendeinen Copilot-Studio-Zweck bereitstellt. Bauen kostet übrigens ab dem ersten Prompt, nicht erst nach der Veröffentlichung.

2. In Minuten eine brauchbare App

Nachdem Pay-as-you-go für meine Umgebung eingerichtet war, habe ich eine Fuhrpark-App beschrieben: Fahrzeuge mit VIN und Kaufdatum, HU/AU-Fristen, interne Wartungen, Fahrerzuordnung.

Wenige Minuten später stand eine App mit Wartungsplan-Ansicht, Fahrzeugdetails und Formularen. Ehrlich gesagt: Beeindruckend. Und ein bisschen beunruhigend, wie schnell das geht.

Ein paar Details, die man kennen sollte:

Die erste Version speichert Daten nur lokal im Browser. Erst auf Nachfrage schlägt der Agent SharePoint vor.
Er legt die Listen auf einer bestehenden SharePoint-Site an – auf jeder Site, auf der der Maker Rechte hat. Ohne IT-Prozess.
An einer Nachschlage-Spalte ist er zweimal gescheitert und hat mir dann eine Klick-Anleitung gegeben. Von 18 Beispieldatensätzen kamen 8 an. Prototyp ja, saubere Datenmodellierung nein.

3. Die Leitplanken greifen

Jede Schreibaktion verlangt ein Approve, mit Risikokennzeichnung.
Beim Start der App fragt sie den Nutzer ausdrücklich nach Zustimmung zur Datenverbindung. Gearbeitet wird mit der Identität des Nutzers.
Als ich zum Test Basecamp anbinden wollte, kam ein sauberes Nein mit Begründung: Datenrichtlinie.

Der Grund für das Nein ist interessant. Microsoft legt automatisch eine „Default Environment Group“ an – mit vier Regeln: Routing, Connectors & MCP-Server, Sharing, Content Security Policy. Die Connector-Regel ist eine von Microsoft kuratierte Allow-List (Advanced Connector Policy): nur Microsoft-Connectoren, allgemein verfügbar, ausschließlich Entra-Authentifizierung, Daten bleiben im Tenant. Alles andere ist blockiert – auch jeder neue Connector. Bestehende klassische DLP-Richtlinien greifen zusätzlich, die strengere Regel gewinnt.

Im Power Platform Admin Center ist diese Regel read-only und verweist auf das Microsoft 365 Admin Center. Dort lässt sie sich bearbeiten – mit einer Warnung: Wer bearbeitet, übernimmt die Pflege. Automatische Updates durch Microsoft enden.

Für den Start ist das eine gute Nachricht. Wer das Feature im Tenant hat, ist nicht schutzlos.

4. Wo die App landet

Die Konversation habe ich in Copilot Studio in der Default-Umgebung begonnen. Oben rechts stand der Hinweis, die App werde in meiner persönlichen Developer Umgebung gebaut.

Dort ist sie dann – aber in keinem Maker-Portal sichtbar. Weder in Power Apps noch sonst wo. Sie taucht auf:

im Microsoft 365 Admin Center unter Apps → All apps,
im Power Platform Admin Center unter Manage → Inventory, Typ Copilot Managed Runtime, mit der ID meiner persönlichen Entwicklerumgebung,
unter einer eigenen URL: play.preview.managedapps.cloud.microsoft/apps/….

Eine Power-Platform-Umgebung also – aber mit Inhalten, die die bisherigen Studios nicht anzeigen.

Wer bisher bewusst auf persönliche Entwicklerumgebungen verzichtet hat (etwa: alle Maker in einer gemeinsamen Sandbox), muss umdenken. Die Managed Runtime routet über ihre eigene Regel in persönliche Umgebungen. Das klassische Environment Routing im Power Platform Admin Center blieb in unserem Tenant davon unberührt.

5. Das Initial-Setup ist die Weiche

Bevor ich gebaut habe, habe ich im Microsoft 365 Admin Center das Initial-Setup unter Apps durchgeführt. Viel einzustellen gibt es nicht: Es legt ein Default-Routing an, danach lässt sich kaum noch etwas ändern.

Laut Microsoft-FAQ initialisiert schon das Öffnen der App-Governance durch einen Admin – oder die erste App eines Makers – diese Governance. Ab dann lässt sich die Routing-Regel „Everyone“ weder löschen noch ändern. In einem Kunden-Tenant sollte das eine bewusste Entscheidung sein, kein Neugier-Klick.

6. Wo ist der Code?

In einem Git-Repository, das die Plattform verwaltet. Einsehen lässt es sich über die CLI (ms app clone). Ein eigenes GitHub-Repository geht nur bei der Erstellung per CLI, nur mit GitHub Enterprise Cloud – Azure DevOps wird nicht unterstützt – und ist für die Lebensdauer der App fix. Eine App aus Copilot Studio bleibt beim plattformverwalteten Repo.

Solutions, Export oder Import gibt es für diesen App-Typ nicht.

7. How-to: App-Erstellung auf eine Sicherheitsgruppe begrenzen

Nachtrag vom 15.10.2026 – Schritt für Schritt in unserem Tenant durchgespielt.

Im Microsoft 365 Admin Center unter Apps → Overview („Choose where people can create apps“) gibt es für jeden Erstellungsweg nur An oder Aus. Eine Sicherheitsgruppe lässt sich dort nicht auswählen. Das geht nur per PowerShell über das Tenant-Setting enabledGroupsManagedAppsMcsPreview.

Voraussetzungen

Rolle Global Administrator oder Power Platform Administrator
PowerShell mit dem Modul Microsoft.PowerApps.Administration.PowerShell (ich habe Windows PowerShell genutzt)
Die Object-ID der Sicherheitsgruppe: Entra Admin Center → Groups → Gruppe öffnen → Object ID

Schritt 1: Modul installieren und anmelden

Install-Module Microsoft.PowerApps.Administration.PowerShell -Scope CurrentUser
Add-PowerAppsAccount -Endpoint prod

Add-PowerAppsAccount öffnet die Anmeldung. Mit dem Admin-Konto anmelden.

Schritt 2: Ist-Zustand lesen, bevor du etwas änderst

$s = Get-TenantSettings
$s.powerPlatform.powerApps | Format-List *ManagedApps*

Ausgabe in unserem Tenant:

enableManagedAppsCliPreview : DefaultOff
enableManagedAppsMcsPreview : DefaultOn

Der Copilot-Studio-Weg steht auf DefaultOn, die CLI auf DefaultOff. Das Feld für die Gruppe existiert noch nicht. (Auf die Sternchen links und rechts von ManagedApps achten.)

Schritt 3: Gruppe setzen – nur das eine Feld als Teil-Objekt

$body = @{ powerPlatform = @{ powerApps = @{ enabledGroupsManagedAppsMcsPreview = "<<Sec Group Object-ID>>" } } }
Set-TenantSettings -RequestBody $body

Wichtig: nur dieses Teil-Objekt senden. Das in der Doku übliche Muster „ganzes Objekt holen, ändern, zurückschreiben“ scheitert hier mit HTTP 400 (InvalidManagedAppsPreviewValueInTenantSettings), weil Get-TenantSettings die Werte DefaultOn/DefaultOff liefert, Set-TenantSettings aber nur On/Off akzeptiert.

Der Aufruf gibt die komplette Liste der Tenant-Settings zurück – das ist die Erfolgsmeldung. Mehrere Gruppen werden als kommagetrennte Object-IDs in einem String angegeben.

Schritt 4: Prüfen

Technisch:

(Get-TenantSettings).powerPlatform.powerApps | Format-List *ManagedApps*

enableManagedAppsCliPreview        : DefaultOff
enableManagedAppsMcsPreview        : DefaultOn
enabledGroupsManagedAppsMcsPreview : <<Sec Group Object-ID>>

Die beiden Default-Werte sind erhalten geblieben – das Teil-Objekt wird zusammengeführt, nicht überschrieben. Wichtig: enableManagedAppsMcsPreview muss eingeschaltet bleiben. Die Gruppe schränkt nur ein, wer den eingeschalteten Weg nutzen darf.

Funktional: Ein Nutzer außerhalb der Gruppe sieht in Copilot Studio die Kachel App (Preview) nicht mehr. Mitglieder bauen weiter. Bei uns wirkte das nach kurzer Zeit.

In der Oberfläche: nichts. Die Gruppe ist im Microsoft 365 Admin Center nirgends zu sehen – weder unter Set up noch sonst unter Copilot oder Apps. Dort steht weiter „On“.

Zurücknehmen

Nach demselben Prinzip als Teil-Objekt, mit leerem Wert:

$body = @{ powerPlatform = @{ powerApps = @{ enabledGroupsManagedAppsMcsPreview = $null } } }
Set-TenantSettings -RequestBody $body

Danach mit Schritt 4 prüfen. Auch hier nicht das ganze Objekt zurückschreiben, das scheitert am HTTP-400-Fehler.

Was das für die Governance heißt

Wer nur in die Oberfläche schaut, hält die App-Erstellung für offen für alle – obwohl sie auf eine Gruppe beschränkt ist. Umgekehrt kann jemand die Einschränkung per PowerShell setzen oder entfernen, ohne dass es im Admin Center auffällt. Diese Einstellung gehört deshalb in die Governance-Dokumentation und ins regelmäßige Review per Get-TenantSettings.

Die Frage, auf die es noch keine gute Antwort gibt

Ich habe den Agenten gefragt, wie die App in Produktion kommt. Sie läuft ja in meiner persönlichen Entwicklerumgebung – dort gehört eine produktive App nicht hin.

Seine Antwort, sinngemäß: Diese Apps werden ausdrücklich in persönlichen Entwicklerumgebungen gehostet. Die Umgebung bedeutet bei diesem App-Typ nicht „Prototyp“. Einen dokumentierten Umzug in eine andere Umgebung gibt es nicht. Wer getrennte Dev-, Test- und Prod-Umgebungen braucht, solle eine klassische, solution-fähige Power App bauen.

Das deckt sich mit der Dokumentation: ms app deploy geht immer in die Umgebung, an die die App gebunden ist. Es gibt Preview (jeder Build) und Live (bewusst deployt) – eine Stufe, keine drei Umgebungen.

Microsoft trennt damit die Umgebung vom Lebenszyklus. Governance hängt an der Environment Group und an der App im Admin Center, nicht mehr an der Frage, in welcher Umgebung etwas liegt.

Das kann man so sehen. Aber dann ist die entscheidende Frage eine andere: Die produktive App lebt per Design in der persönlichen Umgebung eines Mitarbeiters. Was passiert mit ihr, wenn dieser Mitarbeiter das Unternehmen verlässt? Eine Übertragung der Ownership habe ich in der Dokumentation bisher nicht gefunden.

Für Flows wissen wir seit Jahren: Kritische Lösungen gehören nicht an das Konto eines Mitarbeiters. Für diese Apps fehlt die Antwort noch.

Ein möglicher Weg – aus der CLI-Dokumentation abgeleitet, von mir noch nicht getestet: Den Code klonen und in einer verwalteten Produktionsumgebung per ms app init --environment-id … als neue App registrieren. Dafür muss die App-Erstellung per CLI für diese Umgebung freigeschaltet sein. Das ergibt eine neue App mit neuer ID und neuer URL, keine verschobene.

Kosten

Bauen verbraucht Copilot Credits – ab dem ersten Prompt, inklusive Vorschau und Test.
Nutzen verbraucht Copilot Credits pro Nutzer – außer der Nutzer hat Power Apps Premium.
Cowork braucht zusätzlich eine Microsoft-Copilot-Lizenz und wird separat über Spending Policies abgerechnet.

Copilot Credits sind in keiner Standardlizenz enthalten.

Checkliste für Admins

Bestand prüfen: Power Platform Admin Center → Manage → Power Apps → App Inventory – gibt es vibe- oder App-Builder-Apps? Wenn ja: Migration bis 30.11. planen, bei App Builder die SharePoint-Listen mitdenken.
App-Erstellung einschränken: Microsoft 365 Admin Center → Apps → Overview („Choose where people can create apps“) – dort gibt es nur An/Aus für den Copilot-Studio-Pfad. Eine Begrenzung auf Sicherheitsgruppen geht nur per PowerShell (Tenant-Setting enabledGroupsManagedAppsMcsPreview, als Teil-Objekt – siehe Abschnitt 7) und ist danach im Admin Center nicht sichtbar.
Nicht „nur mal reinschauen“: Das Initial-Setup der App-Governance fixiert die „Everyone“-Routing-Regel. Vorher entscheiden.
Credits bewusst steuern: Wer Copilot Credits bereitstellt, schaltet faktisch auch das App-Bauen frei. Allokation pro Umgebung, Zugriff auf den Tenant-Pool abschalten, wo nicht gewollt.
Allow-List kennen: Die Connector-Regel der Default Environment Group zunächst nicht bearbeiten, aber in jedes Governance-Review aufnehmen. Microsoft kann sie erweitern.
Produktion definieren: Prototypen ja. Produktive Nutzung erst, wenn Owner, Betrieb und Ablösung geklärt sind.

Einordnung

Previews kommen und gehen. Wer Previews nicht produktiv freigibt, verliert bei einer Abkündigung nichts.

Der Nachfolger ist aber kein Feature-Update. Er bringt eine neue Plattform mit eigener Verwaltung, eigenem Abrechnungsmodell, Voreinstellungen, die man bewusst treffen sollte – und eine Leistungsfähigkeit, die Fachbereiche begeistern wird. Genau deshalb braucht er Leitplanken, bevor die ersten Apps unbemerkt produktiv werden.

Governance ist hier wieder einmal keine Verhinderung. Sie ist die Voraussetzung dafür, dass Fachbereiche diese Möglichkeiten nutzen dürfen. Und dabei ist wihtig zu wissen, dass die Governance - trotz dessen dass es Coding im Low-Code bzw No-Code Umfeld ist - dieses Mal nicht in der Power Platform vorgegeben wird.

Wenn du wissen willst, wo eure Power Platform governance-technisch steht, macht den Power Platform Governance Quick Check.

Quellen (Stand 15.10.2026):

vibe.powerapps.com wird abgeschaltet – ich habe den Nachfolger getestet