Übersicht über die Konnektoren für Canvas-Apps

Daten sind der Kern der meisten Apps, einschließlich Apps, die Sie in Power Apps erstellen. Sie speichern Daten in einer Datenquelle, und Sie bringen diese Daten in Ihre App, indem Sie eine Verbindung erstellen. Die Verbindung verwendet einen bestimmten Konnektor, über den mit der Datenquelle kommuniziert wird. Power Apps verfügt über Connectors für viele gängige Dienste und lokale Datenquellen, u. a. SharePoint, SQL Server, Office 365, Salesforce und Twitter. Die ersten Schritte zum Hinzufügen von Daten zu einer Canvas-App werden unter Hinzufügen einer Datenverbindung in Power Apps beschrieben.

Ein Connector kann Tabellen mit Daten oder Aktionen bereitstellen. Einige Konnektoren stellen nur Tabellen bereit, andere nur Aktionen und wiederum andere bieten beides. Bei Ihrem Connector kann es sich außerdem um einen standardmäßigen oder einen benutzerdefinierten Connector handeln.

Notiz

Halten Sie die Anzahl der Connectors in einer Canvas-App bei maximal 10 und die Anzahl der Verbindungsreferenzen bei nicht mehr als 20. Das Überschreiten dieser Grenzwerte kann zu längeren Ladezeiten für Benutzer beim Starten der App führen und beim Speichern der App zu Problemen führen.

Tabellen

Wenn Ihr Konnektor Tabellen bereitstellt, fügen Sie Ihre Datenquelle hinzu und wählen dann die Tabelle in der Datenquelle aus, die Sie verwalten möchten. Power Apps ruft die Tabellendaten in Ihre App ab und aktualisiert die Daten in Ihrer Datenquelle automatisch. Sie können z.B. eine Datenquelle hinzufügen, die eine Tabelle namens Lektion enthält, und dann in der Formularleiste die Artikel-Eigenschaft eines Steuerelements, etwa einen Katalog oder ein Formular, auf diesen Wert festlegen:

Sie können die Daten angeben, die von Ihrer App abgerufen werden, indem Sie die Artikel-Eigenschaft des Steuerelements anpassen, das Ihre Daten anzeigt. Als Fortführung des vorherigen Beispiels können Sie die Daten in der Tabelle Lektion sortieren oder filtern, indem Sie diesen Namen als Argument für die Funktionen Suche und SortByColumn verwenden. In dieser Abbildung wird durch die Formel, auf die die Artikel-Eigenschaft festgelegt ist, angegeben, dass die Daten basierend auf dem Text in TextSearchBox1 sortiert und gefiltert werden sollen.

Weitere Informationen zum Anpassen Ihrer Formel mit Tabellen finden Sie in den folgenden Artikeln:

Grundlegendes zu Datenquellen in Power Apps
Generieren einer App aus Excel-Daten
Eine App ganz neu erstellen
Grundlegendes zu Tabellen und Datensätzen in Power Apps

Notiz

Zum Herstellen einer Verbindung mit Daten in einer Excel-Arbeitsmappe hosten Sie sie in einem Cloudspeicherdienst wie OneDrive. Weitere Informationen finden Sie im Artikel zum Verbinden mit Cloudspeicher aus Power Apps.

Aktionen

Wenn Ihr Konnektor Aktionen bereitstellt, müssen Sie trotzdem weiterhin wie oben die Datenquelle auswählen. Sie wählen allerdings als nächsten Schritt keine Tabelle aus, sondern stellen manuell eine Verbindung zwischen einem Steuerelement und einer Aktion her, indem Sie die Artikel-Eigenschaft des Steuerelements bearbeiten, das Ihre Daten anzeigen soll. Die Formel, auf die Sie die Artikel-Eigenschaft festlegen, gibt die Aktion an, die Daten abruft. Die App ruft beispielsweise keine Daten ab, wenn Sie eine Verbindung mit Yammer herstellen und dann die Eigenschaft Items auf den Namen der Datenquelle festlegen. Um ein Steuerelement mit Daten aufzufüllen, geben Sie eine Aktion an, wie z.B. GetMessagesInGroup(5033622).messages.

Wenn Sie benutzerdefinierte Datenupdates für Aktionsconnectors verarbeiten müssen, erstellen Sie eine Formel, die die Pflaster-Funktion enthält. Geben Sie in der Formel die Aktion und die Felder an, die an die Aktion gebunden werden.

Anmerkung

Bei aktionsbasierten Connectors laden Kataloge und andere Steuerelemente nicht wie bei tabellarischen Connectors automatisch mehr Daten nach. Wenn Sie z.B. eine tabellarische Datenquelle an eine Galerie binden, ruft sie die erste Gruppe oder Seite von Datensätzen ab (z.B. 100 Datensätze), und sie lädt bei Bedarf weitere Daten nach, wenn das Steuerelement sie anfordert. Bei einem aktionsbasierten Connector wird eine „Seite“ mit Daten abgerufen, aber wenn die angeforderten Daten die Seitengröße überschreiten, ruft das Steuerelement nicht automatisch die nächste Seite ab.

Weitere Informationen zum Anpassen Ihrer Formel für benutzerdefinierte Updates finden Sie in den folgenden Artikeln:

Patch
Collect
Update

Dynamische Schemata sind ein häufiger Ergebnistyp für aktionsbasierte Konnektoren. Dynamisches Schema bezieht sich auf die Möglichkeit, dass dieselbe Aktion eine Tabelle mit unterschiedlichen Spalten zurückgeben kann, je nachdem, wie sie aufgerufen wird. Bedingungen, die dazu führen können, dass sich die Spalten in der Tabelle unterscheiden, sind Eingabeparameter, der Benutzer oder die Rolle, die die Aktion ausführt, und die Gruppe, in der der Benutzer arbeitet, unter anderem. Beispielsweise können gespeicherte SQL Server-Prozeduren unterschiedliche Spalten zurückgeben, wenn sie mit unterschiedlichen Eingaben ausgeführt werden, oder eine Azure DevOps-Instanz kann benutzerdefinierte Felder verwenden, die nicht standardmäßig verfügbar sind.

Notiz

Die Connector-Dokumentation zeigt dynamische Schema-Ergebnisse mit der Nachricht „Die Ausgaben dieses Vorgangs sind dynamisch“ als Rückgabewert.

Weitere Informationen über die Arbeit mit dynamischen Schemata in Power Apps finden Sie unter Mit dynamischen Werten arbeiten, das Ihnen einen Überblick über das Thema gibt, und Mit Azure DevOps von Power Apps aus verbinden, das ein detailliertes Beispiel enthält.

Gängige Connectors

Diese Tabelle enthält Links zu weiteren Informationen zu den am häufigsten verwendeten Konnektoren. Eine vollständige Liste finden Sie unter Alle Konnektoren.

Microsoft Dataverse	Cloudspeicher **
Dynamics AX	Excel
Microsoft Translator	Office 365 Outlook
Office 365-Benutzer	Oracle
Power BI	SharePoint
SQL Server	Twitter

** Gilt für Azure Blob, Box, Dropbox, Google Drive und OneDrive.

Standardmäßige und benutzerdefinierte Konnektoren

Power Apps bietet Standard-Connectors für viele häufig verwendete Datenquellen. Wenn Power Apps einen Standard-Connector für den von Ihnen gewünschten Datenquellentyp bietet, verwenden Sie diesen Connector. Wenn Sie eine Verbindung mit anderen Arten von Datenquellen herstellen möchten, z.B. mit einem von Ihnen erstellten Dienst, finden Sie weitere Informationen unter Registrieren und Verwenden von benutzerdefinierten Konnektoren.

Alle Standardconnectors

Standard-Connectors erfordern keine spezielle Lizenzierung. Weitere Informationen finden Sie auf der Power Apps-Pläne.

Stellen Sie in den Power Apps-Foren Fragen zu einem bestimmten Connector und schlagen Sie unter Power Apps-Ideen Connectors zum Hinzufügen oder andere Verbesserungen vor.

Sicherheit und Authentifizierungarten

Wenn Sie Ihre App erstellen und eine Verbindung zu einer Datenquelle erstellen, sehen Sie möglicherweise, dass Ihre Auswahl des Connectors verschiedene Möglichkeiten zur Authentifizierung bietet. Mit dem SQL Server-Connector können Sie beispielsweise die integrierte Microsoft Entra, die SQL Server-Authentifizierung und Windows-Authentifizierung verwenden. Jeder Authentifizierungstyp weist unterschiedliche Sicherheitsstufen auf. Verstehen Sie, welche Informationen und Rechte Sie für Benutzer freigeben, die Ihre Anwendung verwenden. Das primäre Beispiel in diesem Artikel ist SQL Server. Die Grundsätze gelten jedoch für alle Arten von Verbindungen.

Notiz

• Ausführliche Informationen zu Sicherheitsüberlegungen bei der Verwendung eines relationalen Datenbankservers, wie z. B. Microsoft SQL Server oder Oracle, als Datenquelle für eine App, finden Sie unter Microsoft SQL Server sicher mit Power Apps verwenden.
• Power Apps unterstützt keine Externen Mitglieder-Identitäten. Weitere Informationen finden Sie unter Eigenschaften eines Microsoft Entra-B2B Collaboration-Benutzers.
• Die Gatewayauswahl wird für benutzerdefinierte Connectors, die den anonymen Authentifizierungstyp verwenden, nicht unterstützt.

Microsoft Entra ID

Diese Authentifizierung ist eine sichere Verbindung. SharePoint verwendet zum Beispiel diese Art der Authentifizierung. SQL Server ermöglicht auch diese Art der Authentifizierung. Wenn Sie eine Verbindung herstellen, identifiziert der Microsoft Entra-Service Sie separat in Ihrem Namen an SharePoint. Sie müssen weder einen Benutzernamen noch ein Kennwort angeben. Als Autor können Sie die Datenquelle mithilfe Ihrer Anmeldeinformationen erstellen und damit arbeiten. Wenn Sie Ihre Anwendung veröffentlichen, meldet sich der Anwendungsbenutzer mit seinen Anmeldeinformationen an. Wenn die Daten auf einem Back-End angemessen gesichert sind, können Ihre Benutzenden nur das anzeigen, was sie basierend auf ihren Anmeldeinformationen anzeigen dürfen. Mit dieser Art von Sicherheit können Sie die Rechte für bestimmte Anwendungsbenutzende im Back-End Datenquelle ändern, nachdem die Anwendung veröffentlicht wurde. Sie können beispielsweise den Zugriff gewähren, den Zugriff verweigern oder verfeinern, was ein Benutzer oder eine Gruppe von Benutzern im Back-End Datenquelle sehen kann.

Open-Standard-Autorisierung (OAuth)

Dies ist auch eine sichere Verbindung. Twitter verwendet zum Beispiel diese Art der Authentifizierung. Wenn Sie eine Verbindung herstellen, müssen Sie Ihren Benutzernamen und Ihr Kennwort angeben. Als Autor können Sie die Datenquelle mithilfe Ihrer Anmeldeinformationen erstellen und damit arbeiten. Wenn Sie Ihre Anwendung veröffentlichen und sich der Anwendungsbenutzer anmeldet, müssen sie auch ihre Anmeldeinformationen angeben. Daher ist diese Art der Verbindung sicher, da Ihre Benutzer ihre eigenen Anmeldeinformationen verwenden müssen, um auf den Dienst Datenquelle zuzugreifen.

Freigegebene Verbindungen und sichere implizite Verbindungen

In einer freigegebenen Verbindung stellt der Power Apps-Autor den Benutzernamen und das Kennwort für die Verbindung bereit, wenn die Datenquelle in der Anwendung erstellt wird. Die Verbindungsauthentifizierung mit der Datenquelle wird dann implizit für Endbenutzer freigegeben . Nachdem die Anwendung veröffentlicht ist, ist auch die Verbindung veröffentlicht und für Ihre Benutzer verfügbar.

Vor Januar 2024 können Ihre Endbenutzer die Verbindung herstellen, die Sie für sie freigegeben haben, und separate neue Anwendungen erstellen. Ihre Benutzer können den Benutzernamen oder das Kennwort nicht sehen, aber die Verbindung steht ihnen zur Verfügung. Nach Januar 2024 werden jedoch alle neu erstellten freigegebenen Verbindungen gesichert. Um vorhandene Apps zu sichern, veröffentlichen Sie sie erneut. Die Verbindung wird nicht mehr mit Endbenutzern geteilt. Die veröffentlichte Power App kommuniziert mit einem Verbindungsproxy. Der Verbindungsproxy kommuniziert nur mit der Power App, mit der er verknüpft ist. Der Verbindungs-Proxy beschränkt die Aktionen, die an die Verbindungen gesendet werden, auf diejenigen in Power App {Get, Put/Patch, Delete} für eine bestimmte Datenquelle. Wenn Sie eine App haben, die Verbindungen verwendet, die vor Januar 2024 veröffentlicht wurden, veröffentlichen Sie Ihre Anwendung erneut und heben Sie die Freigabe aller Verbindungen für Endbenutzer auf, die sie nicht haben sollten.

In SQL Server ist ein Beispiel für diese Art von Verbindung die SQL Server-Authentifizierung. Viele andere Datenbankdatenquellen bieten eine ähnliche Funktion. Wenn Sie Ihre Anwendung veröffentlichen, müssen Ihre Benutzer keinen eindeutigen Benutzernamen und kein Kennwort angeben.

Notiz

Ihre Endbenutzer können auf die Fehlermeldung stoßen , dass Sie nicht über die richtigen Berechtigungen verfügen, um diese Verbindung im Zustimmungsdialogfeld zu verwenden. Dieser Fehler kann in zwei Situationen auftreten. Erstens verfügt die Anwendung möglicherweise über eine freigegebene implizite Verbindung, die keine sichere implizite Verbindung ist . Die Freigabe der Verbindung an den Endbenutzer behebt dieses Problem, wird jedoch nicht empfohlen, da alle freigegebenen Verbindungen sichere implizite Verbindungen sein sollten. Der Autor sollte alle Verbindungen in der Anwendung in sichere implizite Verbindungen konvertieren, um dieses Problem zu beheben. Zweitens ist die Verbindung möglicherweise bereits eine sichere implizite Verbindung. Die erneute Veröffentlichung kann dieses Problem beheben. Ist dies nicht der Fall, sollte ein Produktfehler gemeldet werden.

Benachrichtigung zur Aktualisierung Ihrer Apps (sichere implizite Verbindungen)

Wenn Sie über Anwendungen verfügen, die möglicherweise für die Verwendung dieses Features aktualisiert werden, wird auf der Seite "Apps " eine Meldung angezeigt. Sie zeigt die Anzahl der Apps an, die Ihre Aufmerksamkeit erfordern.

Wählen Sie den Link aus und es wird ein Seitenbereich mit allen Apps geöffnet, die Aufmerksamkeit erfordern.

Wählen Sie das Symbol Öffnen rechts neben dem Namen der App aus, um sie zu öffnen und erneut zu veröffentlichen. Folgen Sie den folgenden Anweisungen.

Sichere implizite Verbindungen für eine bestehende App aktivieren

Öffnen Sie eine vorhandene App, die zur Bearbeitung geöffnet ist, in der implizit freigegebene Verbindungen bereits veröffentlicht sind:

1. Wählen Sie in der Befehlsleiste Einstellungen aus und suchen Sie nach „Sicher“.
2. Aktualisieren Sie den Funktionsschalter entsprechend, um sichere implizite Verbindungen zu ermöglichen.
3. Sichern und veröffentlichen Sie die App.

Freigabe aufheben

Nachdem Sie die App veröffentlicht haben, führen Sie die folgenden Schritte aus, um zu überprüfen, ob das Teilen ordnungsgemäß funktioniert:

• Überprüfen Sie, ob Verbindungen an Mitbesitzern freigegeben werden. Wenn Sie nicht möchten, dass ein Endbenutzer eine Verbindung erhält, deaktivieren Sie Mitbesitzer.

• Um zu überprüfen, ob das Feature ordnungsgemäß funktioniert, geben Sie die App für einen anderen Benutzer frei, der kein Besitzer ist. Nachdem Sie die App freigegeben haben, gehen Sie zur Liste Verbindungen auf der Registerkarte Dataverse in Power Apps für diesen Benutzer. Vergewissern Sie sich, dass keine Verbindung für den Benutzer verfügbar ist.

• Öffnen Sie das Fenster Freigabe, um die Berechtigung des Endbenutzers auf die Verbindung zu ändern. Wählen Sie das X aus, um den Zugriff des Benutzers auf die Verbindung zu entfernen.

Apps mit einer neuen sicheren impliziten Verbindung verwenden

Wenn Sie Ihre App erneut veröffentlichen und freigeben, haben Endbenutzer keinen Zugriff auf die Verbindung, arbeiten aber mit der ausgeblendeten Proxyverbindung. Benutzer können basierend auf Ihrer ursprünglichen Verbindung keine neue App erstellen.

Einschränkungen

1. Alle Typen von implizit freigegebenen Verbindungen funktionieren, z. B. Aktions- und Tabellenverbindungen.
2. Server- und Datenbanknamen sind in Netzwerkprotokollen ausgeblendet, aber im Einwilligungsdialog sichtbar. Spaltennamen werden nicht ausgeblendet.
3. Bei tabellarischen Verbindern schränkt das Feature nur CRUD-Aktionen wie "Abrufen", "Posten", "Put" oder "Löschen" ein. Wenn Sie Berechtigungen für Put haben, dann haben Sie Zugriff auf Post.
4. Grenzwerte für aktionsbasierte Connectors basierend auf der spezifischen API, die in der Anwendung verwendet wird.
5. Warnungen sind beim Teilen weiterhin aktiviert. Die Warnung bei implizit freigegebenen Verbindungen warnt auch während der Vorschauversion. Ihre Verbindung mit diesem Feature ist jedoch trotz der Warnung sicher.
6. Die Veröffentlichung an einen gesamten Mandanten, im Gegensatz zu bestimmten Gruppen oder Einzelpersonen, wird nicht unterstützt.
7. Es gibt ein bekanntes Problem beim Importieren einer implizit freigegebenen sicheren Verbindung über eine Verbindungsreferenz. Die Sicherheit ist in der Zielumgebung nicht korrekt eingestellt.
8. Es ist ein bekanntes Problem, dass beim Importieren einer Lösung mithilfe eines Dienstprinzipals ein Importfehler auftritt. Eine Problemumgehung besteht darin, die Verbindung mit dem Dienstprinzipal zu teilen.

Windows-Authentifizierung

Diese Art der Verbindung ist nicht sicher, da sie nicht auf der Endbenutzerauthentifizierung basiert. Verwenden Sie die Windows-Authentifizierung, wenn Sie eine Verbindung zu einer Datenquelle herstellen müssen, die lokal ist. Ein Beispiel für diese Art der Verbindung ist ein lokaler Server mit einem SQL Server. Die Verbindung muss über ein Gateway erfolgen. Da es über ein Gateway geht, hat der Konnektor Zugriff auf alle Daten in dieser Datenquelle. Daher sind alle Informationen, auf die Sie mit den von Ihnen bereitgestellten Windows-Anmeldeinformationen zugreifen können, für den Connector verfügbar. Wenn Sie die Anwendung veröffentlichen, veröffentlichen Sie auch die Verbindung und stellen sie Ihren Benutzern zur Verfügung. Dieses Verhalten bedeutet, dass Ihre Endbenutzer Anwendungen mithilfe derselben Verbindung erstellen und auf die Daten auf diesem Computer zugreifen können. Verbindungen zum Datenquelle sind ebenfalls Implizit geteilt mit Benutzern, mit denen die App geteilt wird. Diese Art der Verbindung ist möglicherweise gültig, wenn Ihre Datenquelle nur auf einem lokalen Server gespeichert ist und die Daten in dieser Quelle frei gemeinsam genutzt werden können.

Datenquellen in Lösungen

Lösungen helfen bei der Verwaltung des Anwendungslebenszyklus und bieten andere Möglichkeiten, den Lebenszyklus von Datenquellen zu verwalten. Wenn sich eine Canvas-App in einer Lösung befindet, können Sie Verbindungsverweise und Umgebungsvariablen erstellen, um Informationen zu den Datenquellen zu speichern. Diese Einrichtung erleichtert das Ändern oder erneute Verbinden von Datenquellen, wenn Sie Lösungen in andere Umgebungen verschieben.

Datenquellen in Apps umbenennen

Erfahren Sie, wie Sie Datenquellen in einer App umbenennen und wo der Unterschied zwischen tabellarischen und aktionsbasierten Datenquellen liegt. Weitere Informationen finden Sie unter Aktionsbasierte Power Apps-Datenquellen umbenennen.

Verbindungseinwilligungsdialog

Wenn Benutzer eine App öffnen, die Connectors zum ersten Mal verwendet, wird ein Dialogfeld für die Verbindungsgenehmigung zu den folgenden Zwecken angezeigt.

1. Um Benutzer über die Datenquellen zu informieren, auf die die App zugreift.
2. Um die Aktionen zu skizzieren, die ein Connector möglicherweise in einer App ausführt oder möglicherweise nicht ausführt. Bei Apps, die zum Beispiel den Connector für Office 365-Benutzer verwenden:

• Diese App kann:
  • Ihr vollständiges Benutzerprofil lesen
  • Das vollständige Profil aller Benutzer lesen
• Die App kann Folgendes nicht:
  • Benutzerprofilinformationen ändern oder löschen

1. Um die Einwilligung des Endbenutzers zu erfassen, eine Verbindung zu den Datenquellen herzustellen, die die App verwendet.
2. Um die manuelle Authentifizierung des Endbenutzers bei Bedarf zu erleichtern.

Für einige Verbindungen kann Power Platform einen Benutzer automatisch authentifizieren, um auf eine Datenquelle zuzugreifen. Wenn die automatische Anmeldung jedoch fehlschlägt, werden Benutzer in diesem Dialog aufgefordert, die Probleme bei der Verbindung durch manuelles Anmelden zu beheben. Power Platform kann die automatische Anmeldung für eine Verbindung nur versuchen, wenn eine Datenquelle den Microsoft-Dienstprinzipal für Azure-API-Verbindungen vorab autorisiert und ihm die Berechtigung erteilt, sich mit einmaligem Anmelden für einen Benutzer anzumelden, wenn eine Verbindung erstellt wird. Weitere Informationen zum einmaligen Anmelden finden Sie unter Was ist einmaliges Anmelden (SSO)?

Wen bei modellgesteuerten Apps, die benutzerdefinierte Seiten verwenden, mehrere benutzerdefinierte Seiten in einer App vorliegen, fordert das Einwilligungsdialogfeld Datenberechtigungen für alle Connectors auf allen benutzerdefinierten Seiten an, auch wenn Benutzer sie nicht öffnen.

Das folgende Bild zeigt ein Beispiel für den Verbindungseinwilligungsdialog für eine App, die eine Verbindung zu einer SharePoint-Website herstellt.

Für ausgewählte Connectors können Administratoren dieses Dialogfeld unterdrücken und im Namen der Endbenutzer zustimmen, eine Verbindung mit einer Datenquelle herzustellen. In der folgenden Tabelle wird erläutert, für welche Arten von Connectors der Einwilligungsdialog für eine App unterdrückt werden kann.

Notiz

Wenn ein Administrator das Zustimmungsdialogfeld unterdrückt, die Plattform jedoch kein einmaliges Anmelden für einen Endbenutzer ausführen kann, wird dem Benutzer beim Starten der App das Dialogfeld angezeigt.

Connectortyp	Einwilligungsdialog unterdrückbar?	Verweis
Microsoft-Connectors, die einmaliges Anmelden unterstützen (wie z. B. SharePoint, Office 365-Benutzer)	Ja	Power Apps-Admin-Cmdlet
Connector, der auf einen Partnerdienst, der nicht von Microsoft stammt, wie Salesforce, zugreift	Nein	Nicht zutreffend
Benutzerdefinierte Connectors, die OAuth mit Microsoft Entra ID als Identitätsanbieter verwenden. Dies sind benutzerdefinierte Connectors, die von Organisationen erstellt wurden und auf die nur die Benutzenden innerhalb der Organisation zugreifen können (z. B. erstellt von Contoso nur für Contoso-Benutzende)	Ja	Verbindungen verwalten

Microsoft Power Platform kann das Zustimmungsdialogfeld nur für Verbindungen mit Datenquellen unterdrücken, bei denen alle folgenden Bedingungen erfüllt sind:

1. Für die Datenquelle ist keine explizite Zustimmungs-UI erforderlich.
2. Die Datenquelle autorisiert den Microsoft-Dienstprinzipal für Azure-API-Verbindungen vorab, um einmaliges Anmelden zu ermöglichen.
3. Ein Administrator konfiguriert eine App, um die Einwilligung für die vorherigen Verbindungen zu unterdrücken.

Die Vorabautorisierung des Azure-API-Verbindungs-Dienstprinzipals von Microsoft gilt für die Erstanbieterdatenquellen von Microsoft. Benutzerdefinierte Anwendungen, die in einem Microsoft Entra-Mandanten registriert sind und von benutzerdefinierten Connectors verwendet werden, können diese Vorabautorisierung konfigurieren. Ein Admin verwaltet die Einwilligungsunterdrückung pro App (anstatt auf Connectorbasis), sodass die Unterdrückung auf der Ebene der einzelnen App-Erfahrung verwaltet wird. Diese Granularitätsstufe verhindert, dass die Zustimmungsunterdrückung für die "genehmigten Apps" einer Organisation versehentlich die Zustimmung für Apps unterdrückt, die nicht genehmigt oder überprüft werden.