PowerLeap Logo

Copilot Studio Friction

Bei Änderungen an diesem Eintrag benachrichtigt werden

Eine E-Mail, wenn sich Status oder Lösung ändert — Double-Opt-in, kein Tracking, Abmeldelink in jeder E-Mail.

Flow schlägt mit Berechtigungsfehlern des Benutzers fehl trotz „Maker-provided credentials"

Abgemildertseit 8. Juli 2026

Zuletzt verifiziert

Details & Verwandtes

Einschätzung

Vertrauensstufe
Offiziell bestätigtDurch Microsoft-Dokumentation oder eine offizielle Aussage bestätigt.
Schweregrad
Blockierend
Typischer Zeitverlust
Stunden

Identifikation

Agent-FlowsAlle Kanäle

Verifikation & Änderungen

  1. Änderung

    Pipeline: neue Evidenz aus m365-roadmap — Prüfung erforderlich.

  2. Verifiziert

    Doku-Check durch Mensch: CAT blog post and official flow-tool doc re-read during seed migration; the two-level credentials model is still documented.

  3. Änderung

    Vorläufig durch den Product Owner genehmigt; externe LLM-Qualitätsprüfung ausstehend.

  4. Änderung

    Erster Eintrag aus dem Seed-Dossier erstellt (Migrationswelle 1).

Verwandt

Automatisch übersetzte Fassung — massgeblich ist das englische Original.

Sind Sie hier richtig?

  • Sie haben die Anmeldeinformationen des Flow-Tools in Copilot Studio auf „Maker-provided credentials" gesetzt.
  • Der Agent-Flow startet, wenn der Agent ihn aufruft.
  • Einzelne Aktionen innerhalb des Flows schlagen mit Berechtigungsfehlern des Endbenutzers fehl.
  • Alles funktioniert, wenn Sie den Flow selbst als Maker auslösen.

Falls Benutzer stattdessen „Unable to provision connection"-Aufforderungen sehen → siehe Unable to provision connection. Falls stattdessen der gesamte Aufruf mit FlowActionBadRequest fehlschlägt → siehe Flow fails with "FlowActionBadRequest". Falls der Flow stattdessen nie als Tool erscheint → siehe Your flow doesn't show up as a tool.

Was passiert

Die Anmeldeinformationseinstellung am Tool steuert nur den Aufruf — also wie der Agent den Flow startet. Innerhalb des Flows erfolgt die Authentifizierung auf einer zweiten, separaten Ebene. Jede Aktion verwendet ihre eigene Verbindungsreferenz: einen gespeicherten Verweis auf eine Anmeldung für einen Connector. Diese Referenzen behalten die Verbindung bei, mit der sie erstellt wurden — die Einstellung berührt sie nicht. Der Flow startet also unter der Identität des Makers, aber eine Aktion darin verlangt weiterhin die Berechtigungen des Endbenutzers. Stellen Sie sich einen Besucherausweis vor: Er öffnet die Lobby, aber jede Bürotür braucht weiterhin ihren eigenen Schlüssel. Die Einstellung händigt den Ausweis aus; die Türschlüssel werden pro Aktion innerhalb des Flows konfiguriert.

Für Techniker

Dies ist ein Zwei-Ebenen-Modell: Anmeldeinformationen auf Aufrufebene (die Tool-Einstellung in Copilot Studio) gegenüber Verbindungsreferenzen auf Aktionsebene (im Flow). Ein Wechsel zu „Maker-provided credentials" verdrahtet nur Ebene eins neu. Die Fehler zeigen sich tief im Ausführungsverlauf, an den spezifischen Connector-Aktionen, deren Verbindung auf den aufrufenden Benutzer aufgelöst wird.

So beheben Sie es

Lösung 1

Offizieller Workaround

Die Verbindungen des Flows auf die Verbindungen des Makers ausrichten

  1. Öffnen Sie den Agent-Flow im Flow-Designer.
  2. Öffnen Sie den Ausführungsverlauf und wählen Sie eine fehlgeschlagene Ausführung aus.
  3. Notieren Sie jede Aktion, die mit einem Berechtigungsfehler fehlgeschlagen ist.
  4. Öffnen Sie für jede dieser Aktionen deren Verbindungseinstellungen.
  5. Wechseln Sie die Verbindung zu einer Verbindung im Besitz des Makers.

✅ Sie sollten jetzt sehen: Jede Aktion im Flow führt die Verbindung des Makers auf, nicht die des Endbenutzers.

  1. Speichern Sie den Flow.
  2. Bestätigen Sie, dass die Anmeldeinformationseinstellung des Tools in Copilot Studio weiterhin „Maker-provided credentials" anzeigt.

Prüfen, ob es funktioniert hat

Bitten Sie eine Kollegin oder ein Testkonto ohne Berechtigungen auf dem Zielsystem, den Flow über den veröffentlichten Agent auszulösen. Erwartet: Die Ausführung ist erfolgreich, und der Ausführungsverlauf zeigt, dass die Aktionen die Verbindung des Makers verwenden.

Falls es nicht funktioniert hat

  • Eine Verbindung wurde übersehen. Flows enthalten oft mehrere Verbindungen über ihre Aktionen hinweg. Prüfen Sie jede Aktion erneut, auch solche innerhalb von Verzweigungen.
  • Der Verbindung des Makers fehlt die Berechtigung selbst. Das Maker-Konto benötigt echten Zugriff auf das Zielsystem. Testen Sie den Flow eigenständig mit diesem Konto.
  • Der Kanal führt weiterhin Ihre alte Agent-Version aus. Veröffentlichung und Propagierungsverzögerung sind ein üblicher Verdächtiger. Siehe Teams answers with an old version.
  • Die Tool-Einstellung ist zurückgesprungen. Öffnen Sie das Tool in Copilot Studio erneut und überprüfen Sie die Anmeldeinformationseinstellung.

So verhindern Sie es künftig

  • Halten Sie die Zwei-Ebenen-Regel in Ihrer Team-Dokumentation fest: Die Tool-Einstellung steuert den Aufruf, Verbindungsreferenzen steuern die Aktionen.
  • Überprüfen Sie jede Verbindung innerhalb eines Flows, bevor Sie den Agent für Endbenutzer freigeben.
  • Testen Sie jeden neuen Flow einmal mit einem Konto, das keine besonderen Berechtigungen hat.

Belege

  • Microsoft-Aussagemicrosoft.github.io

    Das CAT-Team von Microsoft erklärt, dass die Anmeldeinformationseinstellung nur beeinflusst, wie der Agent den Flow aufruft, während sich jede Aktion über ihre eigene Verbindungsreferenz authentifiziert.

  • Offizielle Dokumentationlearn.microsoft.com

    Die offizielle Dokumentation beschreibt das Hinzufügen eines Flows als Tool, einschliesslich der Konfiguration der Anmeldeinformationen, unter denen der Flow-Aufruf ausgeführt wird.

  • Offizielle Dokumentationmicrosoft.com

    Eine offizielle Roadmap-Funktion zum direkten Blockieren von Maker-provided credentials adressiert die Grundursache des bestehenden Eintrags, bei dem Flows trotz Verwendung von Maker-provided credentials mit Berechtigungsfehlern fehlschlagen.