Freigeben über


Validierungsrichtlinien für den Microsoft Teams Store

Wenn Sie diese Richtlinien befolgen, erhöht sich die Wahrscheinlichkeit, dass Ihre App den Microsoft Teams Store-Übermittlungsprozess besteht. Die Teams-spezifischen Richtlinien ergänzen die Zertifizierungsrichtlinien für den kommerziellen Microsoft-Marketplace und werden regelmäßig aktualisiert, um neue Funktionen, Benutzerfeedback und Änderungen der Geschäftsregeln zu berücksichtigen.

Hinweis

  • Einige Richtlinien gelten möglicherweise nicht für Ihre App. Wenn Ihre App beispielsweise keinen Bot enthält, können Sie botbezogene Richtlinien ignorieren.
  • Wir haben diese Richtlinien mit Querverweisen auf die kommerziellen Zertifizierungsrichtlinien von Microsoft versehen und Do's und Don'ts mit Beispielen für erfolgreiche oder nicht erfolgreiche Szenarien in unserem Validierungsprozess hinzugefügt.
  • Bestimmte Richtlinien sind als Muss behoben gekennzeichnet. Wenn Ihre App-Einreichung diese obligatorischen Richtlinien nicht erfüllt, erhalten Sie von uns einen Fehlerbericht mit Maßnahmen zur Behebung des Problems. Ihre App-Übermittlung besteht die Teams Store-Überprüfung erst, nachdem Sie die Probleme behoben haben.
  • Andere Richtlinien sind als Gut zu beheben gekennzeichnet. Für eine optimale Benutzererfahrung wird empfohlen, die Probleme zu beheben. Die Veröffentlichung Ihrer App-Übermittlung im Teams Store ist jedoch nicht blockiert, wenn Sie die Probleme nicht beheben möchten.

Wertbeitrag

Dieser Abschnitt steht im Einklang mit der Kommerziellen Microsoft-Zertifizierungsrichtlinie 1140.1 und bietet Entwicklern von Microsoft Teams-Apps weitere Anleitungen zum Wertversprechen ihres Angebots.

Apps müssen den Benutzern einen Mehrwert bieten, indem sie es ihnen ermöglichen, funktionale Workflows abzuschließen, die die wiederholte Verwendung fördern. Erweitern Sie die folgenden Abschnitte, um mehr über das Wertversprechen zu erfahren:

Tabulatoren

Registerkarten müssen einen Wert bereitstellen, der über das Hosten einer vorhandenen Website hinausgeht. [Muss behoben werden]

Die Grafik zeigt ein Beispiel für eine App mit einem Workflow, der für Kanalmitglieder innerhalb eines Teams nützlich ist.

Die Grafik zeigt ein Beispiel für eine App mit der gesamten Website in einem I-Frame ohne Zurück-Option.


Benachrichtigungsbots Eine Benachrichtigung bietet einen Wert in Teams, wenn:
  1. Die bereitgestellte Karte oder der bereitgestellte Text enthält angemessene Details, die keine weiteren Benutzeraktionen erfordern.
  2. Die bereitgestellte Karte oder der bereitgestellte Text enthält angemessene Vorschauinformationen, damit ein Benutzer Maßnahmen ergreifen oder weitere Details in einem Link anzeigen kann, der außerhalb Teams geöffnet wird.

Apps, die nur Benachrichtigungen mit Inhalten bereitstellen, z. B. Sie haben eine neue Benachrichtigung oder klicken, um anzuzeigen, und der Benutzer muss außerhalb von Teams für alles andere navigieren, bieten keinen signifikanten Wert innerhalb von Teams.

Der Screenshot zeigt ein Beispiel für eine Benachrichtigung, die nur ein Bit mit unzureichenden Informationen in der Vorschau enthält.


Nachrichtenerweiterungen

[Muss behoben werden]

Apps, die aus einer suchbasierten Nachrichtenerweiterung bestehen, bieten Benutzern einen Mehrwert, indem sie Karten freigeben, die kontextbezogene Unterhaltungen ohne Kontextwechsel ermöglichen.

Um die Überprüfung für eine reine suchbasierte Nachrichtenerweiterungs-App zu bestehen, ist Folgendes als Baseline erforderlich, um sicherzustellen, dass die Benutzererfahrung nicht unterbrochen wird. Eine über eine Nachrichtenerweiterung freigegebene Karte bietet einen Mehrwert in Microsoft Teams, wenn:

  1. Die bereitgestellte Karte enthält angemessene Details, die keine weitere Benutzeraktion erfordern.

  2. Die bereitgestellte Karte enthält angemessene Vorschauinformationen, damit ein Benutzer Maßnahmen ergreifen oder weitere Details in einem Link anzeigen kann, der außerhalb von Teams geöffnet wird.

    validation-search-base-messaging-ext-adequete-info

    validation-search-base-messaging-ext-inadequete-info


Link unfurling

Apps, die nur zur Verbreitung von Links dienen, bieten in Teams keinen nennenswerten Mehrwert. Erwägen Sie das Erstellen weiterer Workflows in Ihrer App, wenn Ihre App nur das Entpacken von Links unterstützt und keine andere Funktionalität bietet.


Zurück zum Anfang

App-Name

[Muss behoben werden]

Dieser Abschnitt entspricht der Kommerziellen Microsoft-Zertifizierungsrichtlinie 1140.1.1 und bietet Entwicklern weitere Anleitungen zum Benennen ihrer Apps.

Erweitern, um mehr zu erfahren

Der Name einer App spielt eine wichtige Rolle, wenn es darum geht, wie Benutzer ihn im Teams Store entdecken. Verwenden Sie die folgenden Richtlinien, um eine App zu benennen:

  • Der Name muss für Ihre Benutzer relevante Begriffe enthalten. [Muss behoben werden]

  • Präfixe oder Suffixe von allgemeinen Substantiven mit dem Namen des Entwicklers. Beispielsweise Contoso Tasks anstelle von Tasks. [Muss behoben werden]

  • Teams oder andere Microsoft-Produktnamen wie Excel, PowerPoint, Word, OneDrive, SharePoint, OneNote, Azure, Surface und Xbox dürfen nicht verwendet werden, die fälschlicherweise auf Co-Branding oder Co-Selling hinweisen können. Weitere Informationen zum Verweisen auf Microsoft-Softwareprodukte und -Dienste finden Sie unter Microsoft-Warenzeichen- und Markenrichtlinien. [Muss behoben werden]

  • Der Name einer App, die im Teams Store oder einem anderen Angebot im kommerziellen Marketplace aufgeführt ist, darf nicht kopiert werden. [Muss behoben werden]

  • Darf keine profanen oder abfälligen Begriffe enthalten. Der Name darf auch keine rassische oder kulturell unsensible Sprache enthalten. [Muss behoben werden]

  • Muss eindeutig sein. Wenn Ihre App (Contoso) im Teams Store und in Microsoft AppSource aufgeführt ist und Sie eine andere spezifische App für eine geografische Region wie Contoso Mexico auflisten möchten, muss Ihre Übermittlung die folgenden Kriterien erfüllen:

    • Nennen Sie die regionsspezifischen Funktionen der App in den Abschnitten Titel, Metadaten, First-Response-App-Erfahrung und Hilfe. Der Titel muss z. B. „Contoso Mexiko“ sein. Der Titel der App muss eine bestehende App desselben Entwicklers deutlich unterscheiden, um Verwechslungen beim Endnutzer zu vermeiden. [Muss behoben werden]
    • Wählen Sie beim Hochladen des App-Pakets in Partner Center im Abschnitt Verfügbarkeit die richtigen Märkte aus, in denen die App verfügbar ist. [Muss behoben werden]
  • App-Name darf nicht mit einem kernigen Teams-Feature wie Chat, Kontakte, Kalender, Anrufe, Dateien, Aktivität, Teams und Hilfe führen. Der App-Name wird bei der Installation im linken Navigationsbereich nicht auf Chat, Kontakte, Kalender, Anrufe, Dateien, Aktivitäten, Teams und Hilfe gekürzt. [Muss behoben werden]

  • Wenn Ihre App Teil einer offiziellen Partnerschaft mit Microsoft ist, muss der Name Ihrer App an erster Stelle stehen. Beispiel: Contoso-Connector für Microsoft Teams.

  • Der App-Name darf keinen Verweis auf Microsoft- oder Microsoft-Produkte enthalten. Verwenden Sie Teams oder Microsoft nicht im App-Namen, es sei denn, Ihre App ist in offizieller Partnerschaft mit Microsoft. In einem solchen instance muss der App-Name vor jedem Verweis auf Microsoft an erster Stelle sein. Beispiel: Contoso-Connector für Microsoft Teams. [Muss behoben werden]

  • Verwenden Sie bei der Benennung keine Klammern, um Microsoft-Produkte einzuschließen. [Muss behoben werden]

  • Der Entwicklername muss im App-Manifest (zuvor teams-App-Manifest genannt) und AppSource identisch sein. [Muss behoben werden]

  • Übermittelte App-Manifeste müssen Produktionsmanifeste sein. Dementsprechend darf der App-Name nicht angeben, dass es sich bei der App um eine Präproduktions-App handelt. Beispielsweise darf der App-Name keine Wörter wie Beta, Dev, Vorschau und UAT enthalten. [Muss behoben werden]

  • Der App-Name im App-Manifest und AppSource müssen übereinstimmen. [Muss behoben werden]

Tipp

Das Branding Ihrer App im Teams Store und in AppSource einschließlich App-Name, Entwicklername, App-Symbol, AppSource-Screenshots, Video, Kurzbeschreibung und Website darf nicht als offizielles Microsoft-Angebot angenommen werden, es sei denn, Ihre App ist ein offizielles Microsoft 1P-Angebot.

App duplizieren

  • Apps desselben Entwicklers, die die gleiche Funktionalität bieten, müssen eine App-Auflistung gemeinsam nutzen, es sei denn, die Anforderungen zur Einhaltung des Datenschutzes erfordern separate App-Auflistungen oder eine separate App-Auflistung sind erforderlich, um die Government Cloud zu unterstützen. Sie müssen in Ihre Geschäftslogik integrieren und nur einen Eintrag veröffentlichen. [Muss behoben werden]

    • Um die Unterstützungsanforderung für mehrere Regionen zu erfüllen, müssen Sie in Ihre Geschäftslogik integrieren und nur einen Eintrag veröffentlichen.

    Screenshot: Bestandenes Szenario der Regionsanforderung mit Logik

    • Um mehrere Endpunktanforderungen für die lokale und cloudbasierte Bereitstellung zu erfüllen, müssen Sie in Ihre Geschäftslogik integrieren und nur einen Eintrag veröffentlichen.

Geeignet für den Gebrauch am Arbeitsplatz

[Muss behoben werden]

Dieser Abschnitt entspricht der kommerziellen Microsoft-Zertifizierungsrichtlinie Nummer 1140.1.2, 100.8 und 100.10 und bietet Entwicklern zusätzliche Anleitungen zum Erstellen von apps, die am Arbeitsplatz geeignet sind.

Erweitern, um mehr zu erfahren

App-Inhalte müssen für die allgemeine Nutzung am Arbeitsplatz geeignet sein und alle Einschränkungen einhalten, die in den Zertifizierungsrichtlinien für kommerzielle Marktplätze aufgeführt sind. Inhalte mit Bezug zu Religion, Politik, Glücksspielen und längerer Unterhaltung sind verboten. [Muss behoben werden]

Ihre Anwendung muss die Zusammenarbeit in der Gruppe ermöglichen, die Produktivität des Einzelnen verbessern oder beides. Apps, die für Teambindung und soziale Kontakte gedacht sind, müssen kollaborativ sein und für mehrere Teilnehmer konzipiert sein. Die Apps dürfen keinen erheblichen Zeitaufwand von mehr als 60 Minuten pro Sitzung erfordern oder die Produktivität beeinträchtigen. [Muss behoben werden]

Inhaltsaggregator-Apps müssen über einen Mechanismus verfügen, mit dem Benutzer ein Problem oder unangemessene Inhalte an den Herausgeber der App melden können. [Muss behoben werden]

Screenshot: Übergebenes Szenario der Inhaltsaggregator-App zum Melden von Problemen.

Ähnliche Plattformen und Dienste

[Muss behoben werden]

Dieser Abschnitt entspricht der Kommerziellen Microsoft-Zertifizierungsrichtlinie 1140.1.3.

Apps müssen sich auf die Teams-Erfahrung konzentrieren und dürfen keine Namen, Symbole oder Bilder anderer ähnlicher Chat-basierter Plattformen oder Dienste für die Zusammenarbeit im App-Inhalt oder in den App-Metadaten enthalten, es sei denn, die App bietet eine bestimmte Interoperabilität.

Funktionsnamen

App-Featurenamen in Schaltflächen und anderem Benutzeroberflächentext dürfen keine Terminologie verwenden, die für Teams und andere Microsoft-Produkte reserviert ist. Beispielsweise sind "Besprechung starten", "Anruf tätigen" oder "Chat starten " Featurenamen, die von Microsoft in Microsoft Teams verwendet werden. Geben Sie ggf. den Namen Ihrer App ein, um die Unterscheidung deutlich zu machen, z. B. Start Contoso meeting( Contoso-Besprechung starten).

Authentifizierung

[Muss behoben werden]

Dieser Abschnitt entspricht der kommerziellen Microsoft-Zertifizierungsrichtlinie 1140.1.4 und bietet Entwicklern Anleitungen zur Authentifizierung ihrer Apps bei externen Diensten.

Weitere Informationen zum Implementieren der App-Authentifizierung finden Sie unter Authentifizierung in Teams.

Erweitern, um mehr zu erfahren

Authentifizieren mit externen Diensten

Wenn Ihre App Benutzer mit einem externen Dienst authentifiziert, befolgen Sie die folgenden Richtlinien:

  • Anmelde-, Abmelde- und Registrierungserfahrungen:

    • Apps, die von externen Konten oder Diensten abhängen, müssen eine klare und einfache Anmeldung, Abmeldung und Registrierung ermöglichen. [Muss behoben werden]
    • Wenn sich Benutzer abmelden, müssen sie sich nur von der App abmelden und bei Teams angemeldet bleiben. [Muss behoben werden]
    • Apps, die von externen Konten oder Diensten abhängen, müssen eine Möglichkeit für neue Benutzer bieten, sich zu registrieren oder den App-Herausgeber zu kontaktieren, um mehr über die Dienste zu erfahren und Zugriff auf die Dienste zu erhalten. Way Forward muss im Manifest der App, in der langen AppSource-Beschreibung und im Ersten Ausführen der App (Bot-Willkommensnachricht, Registerkarteneinrichtung oder Konfigurationsseite) verfügbar sein. [Muss behoben werden]
    • Apps, bei denen der Mandantenadministrator die einmalige Einrichtung abschließen muss, müssen die Abhängigkeit vom Mandantenadministrator aufrufen, um die App zu konfigurieren (bevor ein anderer Mandantenbenutzer die App installieren und verwenden kann). Die Abhängigkeit muss im Manifest der App, in der langen AppSource-Beschreibung, bei allen Touchpoints für die erste Ausführung (Bot-Willkommensnachricht, Registerkarteneinrichtung oder Konfigurationsseite), im Hilfetext, wie er als Teil der Botantwort als notwendig erachtet wird, im Verfassen von Erweiterungen oder statischen Registerkarteninhalten hervorgehoben werden. [Muss behoben werden]
  • Erfahrungen beim Teilen von Inhalten: Apps, die für die Freigabe von Inhalten in Teams-Kanälen eine Authentifizierung bei einem externen Dienst erfordern, müssen in der Hilfedokumentation (oder ähnlichen Ressourcen) klar angeben, wie die Verbindung zu Inhalten getrennt oder die Freigabe aufgehoben werden kann, wenn diese Funktion für den externen Dienst unterstützt wird. Dies bedeutet nicht, dass die Möglichkeit zum Aufheben der Freigabe von Inhalten in Ihrer Teams-App vorhanden sein muss.

Audio

  • Wenn die App hauptsächlich musikhören soll, muss sie mindestens einen Bereich für die Zusammenarbeit mit einem end-to-End-Workflow unterstützen, der für die App spezifisch ist. Beispiel: Freigeben einer Wiedergabeliste, Konfigurieren oder Anheften einer Wiedergabeliste und synchrones Hören von Musik. [Muss behoben werden]

  • Apps, die in erster Linie mit der Absicht veröffentlicht werden, Benutzern das Anhören von Musik in Teams zu ermöglichen, werden empfohlen, eine gemeinsame Zusammenarbeit zu ermöglichen. [Gut zu beheben]

Sicherheit

Dieser Abschnitt entspricht der Kommerziellen Microsoft-Zertifizierungsrichtlinie 1140.3.

Zurück zum Anfang

Finanzinformationen

[Muss behoben werden]

Dieser Abschnitt entspricht der kommerziellen Microsoft-Zertifizierungsrichtlinie 1140.3.1 und enthält Anleitungen zur Übermittlung von Finanzinformationen innerhalb der Teams-Schnittstelle und benachrichtigt Entwickler über Szenarien mit eingeschränkten Zahlungen in der mobilen Version (Android und iOS) ihrer Teams-App.

Erweitern, um mehr zu erfahren

Apps dürfen Benutzer nicht auffordern, Zahlungen innerhalb der Teams-Benutzeroberfläche zu leisten und Finanzinformationen über eine Bot-Schnittstelle an Benutzer zu übertragen. [Muss behoben werden]

validation-financial-info

Sie können nur dann einen Link zu sicheren externen Zahlungsdiensten bereitstellen, wenn Sie dies in Ihren Nutzungsbedingungen, Datenschutzrichtlinien, auf Ihrer Profilseite oder auf Ihrer Website bekannt geben, bevor der Nutzer der Nutzung der App zustimmt. [Muss behoben werden]

Erleichtern Sie nicht Zahlungen über eine App für Waren oder Dienstleistungen, die gemäß der allgemeinen Richtlinie Nr. 100.10 „Unzulässige Inhalte“verboten sind. [Muss behoben werden]

Apps, die auf der iOS- oder Android-Version von Teams ausgeführt werden, müssen den folgenden Richtlinien entsprechen:

  • Apps dürfen keine In-App-Käufe, Testangebote oder Ui enthalten, die darauf abzielen, Benutzer in kostenpflichtige Versionen oder Onlineshops zu upsellieren, um andere Inhalte, Apps oder Add-Ins zu kaufen. [Muss behoben werden]

    validation-financial-info-in-app-purchase

    validation-online-store

  • Wenn Ihre App ein Konto erfordert, können sich Benutzer kostenlos für ein Konto registrieren. Die Verwendung des Begriffs kostenlos oder kostenloser Account ist untersagt. [Muss behoben werden]

  • Sie können festlegen, ob ein Konto unbegrenzt oder für einen begrenzten Zeitraum aktiv ist. Wenn das Konto abläuft, darf die App keine Benutzeroberfläche, keinen Text oder keine Links anzeigen, die auf die Notwendigkeit der Zahlung hinweisen. [Muss behoben werden]

  • Die Datenschutzrichtlinien und Nutzungsbedingungen Ihrer App müssen frei von kommerziellen UI oder Links sein. [Muss behoben werden]

Bots

[Muss behoben werden]

Dieser Abschnitt entspricht der Microsoft-Richtlinie für den kommerziellen Marketplace 1140.3.2.

Erweitern, um mehr zu erfahren

Bei Apps, die den Microsoft Azure Bot Service nutzen (z. B. Bots und Nachrichtenerweiterungen), müssen Sie alle in den Microsoft-Nutzungsbedingungen für Onlinedienste definierten Anforderungen erfüllen.

Bots müssen immer die Berechtigung zum Hochladen einer Datei und zum Anzeigen einer Bestätigungsmeldung anfordern.

validation-bot-confirmation

Externe Domänen

[Muss behoben werden]

Dieser Abschnitt entspricht der Microsoft-Richtlinie für den kommerziellen Marketplace 1140.3.3 und enthält Eine Anleitung für Entwickler zur Verwendung von eingeschränkten Domänen in der validDomains App-Manifesteigenschaft.

Erweitern, um mehr zu erfahren

Schließen Sie domänen außerhalb der Kontrolle Ihrer organization (einschließlich Wildcards) und Tunnelingdienste nicht in die Domänenkonfigurationen Ihrer App ein. Zu den folgenden Ausnahmen zählen:

  • Wenn Ihre App auf SharePoint basiert, können Sie die zugehörige SharePoint-Stammsite mithilfe der Kontexteigenschaft {teamSiteDomain} als gültige Domäne einschließen. [Muss behoben werden]

  • Verwenden Sie keine Domänen der obersten Ebene wie .com, .in und .org als gültige Domäne. [Muss behoben werden]

  • Verwenden Sie nicht .onmicrosoft.com oder als gültige Domäne, in der onmicrosoft nicht unter Ihrer Kontrolle steht. Sie können jedoch yoursite.com als gültige Domäne verwenden, in der Ihre Website unter Ihrer Kontrolle steht, obwohl die Domäne einen Wildcard enthält. [Muss behoben werden]

  • Wenn Es sich bei Ihrer App um eine PowerApp handelt, die auf der Microsoft Power Platform basiert, müssen Sie apps.powerapps.com als gültige Domäne einschließen, damit Ihre App in Teams barrierefrei und funktionsfähig ist.

  • Externe Domänen, die für Ihre Übermittlung deklariert wurden, dürfen keine URLs enthalten. Beispiel: www oder https. [Muss behoben werden]

  • Wenn Ihre App die OAuthCard des Azure Bot Service verwendet, müssen Sie token.botframework.com als gültige Domäne einschließen. Andernfalls funktioniert die Schaltfläche Anmelden nicht. Sie dürfen .botframework.com nicht deklarieren, da Mit diesem Domänennamen keine Wildcards zulässig sind. [Muss behoben werden]

  • OpenAPI-URLs müssen sich unter Der Kontrolle des Partners befindet.

  • Folgende externe Domänen sind nicht zulässig: [Muss behoben werden]

    • *.azurewebsites.net
    • *.azureedge.com
    • *.microsoft.com
    • *.microsoftonline.com
    • *.onmicrosoft.com
    • go.microsoft.com
    • teams.microsoft.com

Bei Verwendung von Wildcards (*) gelten die folgenden Regeln:

  • Wenn ein Unterdomänensegment einen Platzhalter enthält, muss es das einzige Zeichen im Segment sein.
  • Jedes Segment, das einem Wildcardsegment vorangeht, muss ebenfalls ein Wildcardsegment sein.

* .*.domain.com ist beispielsweise gültig, aber foo.*.myteam.domain.com ist ungültig.

Vertraulicher Inhalt

[Muss behoben werden]

Ihre App darf keine vertraulichen Daten wie kreditwürdige Karte, Finanzielle Zahlungsdetails, Integrität, Kontaktablaufverfolgung oder andere personenbezogene Informationen (Personally Identifiable Information, PII) an eine Zielgruppe senden, die nicht zum Anzeigen des Inhalts bestimmt ist.

Die App muss die Benutzer warnen, bevor sie Dateien oder ausführbare Dateien (.exe) auf den Computer oder in die Umgebung des Benutzers herunterlädt.

Allgemeine Funktionalität und Leistung

Dieser Abschnitt entspricht der Richtlinie 1140.4 für den kommerziellen Marketplace von Microsoft.

  • Anleitungen zur Vorgehensweise sind sowohl für Administratoren als auch für vorhandene Benutzer obligatorisch. Sie können Anleitungen für die Weiterleitung als Links hinzufügen, um sich zu registrieren, zu beginnen, uns zu kontaktieren, Hilfelinks oder per E-Mail zu erhalten.
  • Das Aufrufen von Kontoabhängigkeiten oder Einschränkungen unter der App-Funktionalität ist nicht erforderlich, ist jedoch obligatorisch, um sie sowohl in der langen Beschreibung des App-Manifests als auch in der AppSource-App-Auflistung hinzuzufügen.
  • Sie müssen jede Abhängigkeit von Mandantenadministratoren für neue Benutzer festlegen. Wenn keine Abhängigkeit besteht, ist es obligatorisch, eine Registrierung anzugeben, uns zu kontaktieren, einen Link zu den ersten Schritten oder eine E-Mail zu senden.

Zurück zum Anfang

Externe Funktionen starten

[Muss behoben werden]

Apps dürfen Benutzer nicht aus Teams für Kernbenutzerszenarien entfernen. App-Inhalte und -Interaktionen müssen innerhalb von Teams-Funktionen erfolgen, z. B. Bots, adaptive Karten, Registerkarten und Dialoge (in TeamsJS v1.x als Aufgabenmodule bezeichnet).

Hinweis

Um Benutzer von Ihrer Teams-App über einen Deep Link mit einem Protokoll wie tel:, mailto:oder webex:zur nativen Umgebung umzuleiten, starten Sie den Deep Link in einem neuen Fenster, indem Sie die window.open -Methode aufrufen oder ein Ankertag mit target="_blank"verwenden.

Erweitern, um mehr zu erfahren
  • Verknüpfen Sie Benutzer innerhalb der Teams-App und nicht mit einer externen Website oder App. Für Szenarien, die externe Funktionen erfordern, muss Ihre Anwendung die ausdrückliche Erlaubnis des Benutzers einholen, um die Funktionen zu starten. [Muss behoben werden]

  • Der UI-Text für Schaltflächen, die externe Funktionen starten, muss Inhalte enthalten, die anzeigen, dass der Benutzer die Teams-Instanz verlässt. Fügen Sie z. B. Text wie „Hier geht es zu Contoso.com“ oder „Ansicht in Contoso.com“ein. [Muss behoben werden]

  • Fügen Sie ein Popupsymbol hinzu, um die Benutzer darüber zu informieren, dass sie außerhalb von Teams navigiert werden. Sie können das Popupsymbol rechts neben dem Link verwenden. [Muss behoben werden]

  • Wenn Sie kein Popupsymbol hinzufügen können, können Sie eine der folgenden Optionen implementieren, um den Benutzer darüber zu informieren, dass er außerhalb von Teams navigiert wird: [Muss behoben werden]

    • Fügen Sie eine Notiz unter Adaptive Karte hinzu, die besagt, dass der Benutzer, wenn benutzer Hilfe mit dieser App abrufen auswählen, den Benutzer außerhalb von Teams führt.
    • Fügen Sie Interstitialdialoge hinzu.

Kompatibilität

[Muss behoben werden]

Die Apps müssen auf den neuesten Versionen der folgenden Betriebssysteme und Browser voll funktionsfähig sein:

  • Microsoft Windows
  • macOS
  • Microsoft Edge
  • Google Chrome
  • iOS
  • Android

Ihre Anwendung muss bei nicht unterstützten Browsern und Betriebssystemen eine entsprechende Fehlermeldung anzeigen.

Antwortzeit

[Muss behoben werden]

Teams-Apps müssen innerhalb eines angemessenen Zeitrahmens reagieren oder einen Lade- oder Eingabeindikator oder eine Meldung oder Warnung anzeigen.

  • Registerkarten müssen innerhalb von zwei Sekunden reagieren oder eine Lademeldung oder Warnung anzeigen. [Muss behoben werden]
  • Bots müssen innerhalb von zwei Sekunden auf Benutzerbefehle reagieren oder eine Tippanzeige anzeigen. [Muss behoben werden]
  • Nachrichtenerweiterungen müssen innerhalb von zwei Sekunden auf Benutzerbefehle reagieren. [Muss behoben werden]
  • Benachrichtigungen müssen innerhalb von zwei Sekunden nach der Benutzeraktion angezeigt werden. [Muss behoben werden]

Apps, die von künstlicher Intelligenz unterstützt werden

Erkunden Sie Ressourcen, die Sie bei verantwortungsbewussten Methoden für künstliche Intelligenz (KI) in jeder Phase der Innovation unterstützen, z. B. microsoft RAI Toolkit und HAX Toolkit Project.

Dieser Abschnitt steht im Einklang mit der Microsoft-Richtlinie für den kommerziellen Marketplace für Apps mit KI-generierten Inhalten und der Microsoft-Richtlinie für den kommerziellen Marketplace für Apps, die Gesichtserkennungsfunktionen verwenden.

Apps mit KI-generiertem Inhalt

  • Die App darf keine unangemessenen, schädlichen oder anstößigen KI-generierten Inhalte generieren, enthalten oder darauf zugreifen, die mit den in 100.10 beschriebenen Richtlinien für den kommerziellen Marketplace übereinstimmen. [Muss behoben werden]

    • Erwägen Sie die Verwendung einer der folgenden Optionen:
      • Verwenden Sie die Teams KI-Bibliothek, die Teams-zentrierte Schnittstelle für GPT-basierte Common Language-Modelle und Benutzerabsichts-Engines. [Gut zu beheben]
      • Verwendung von Moderationshooks, die verwendet werden können, um Botantworten über die Moderations-API zu regulieren. [Gut zu beheben]
      • Fügen Sie die Funktion zum Durchsuchen von Unterhaltungen hinzu, mit der Sie Unterhaltungen überwachen und eingreifen können, wenn Unterhaltungen in die Irre gehen. [Gut zu beheben]
  • Die App muss Mechanismen bereitstellen, mit denen App-Benutzer dem Entwickler unangemessene, schädliche oder anstößige Inhalte über einen der folgenden Mechanismen melden können: [Muss behoben werden]

    • App-Beschreibung einschließlich E-Mail-ID oder Link zum Portal zum Protokollieren des Problems.
    • In App-Mechanismus zum Protokollieren eines Problems zusammen mit einem spezifischen Verweis auf unangemessene Inhalte.
  • Bei gemeldeten Bedenken müssen Sie rechtzeitig Maßnahmen ergreifen. [Muss behoben werden]

  • Die App muss die KI-Funktionalität klar beschreiben, bevor der Kunde das Angebot im Einklang mit Richtlinie 100.1.3 erwirbt und den Benutzer auffordern, die Informationen als Teil der In-App-Funktionalität zu überprüfen. [Muss behoben werden].

    Screenshot: Beschreibung der KI-Funktionalität

Apps mit Gesichtserkennungsfunktionen

Hinweis

Apps in dieser Kategorie werden möglicherweise zusätzlichen Überprüfungen unterzogen, um die Prinzipien der verantwortungsbewussten KI von Microsoft zu beachten.

  • Die App darf die Verwendung von Gesichtserkennungsfunktionen nicht zulassen, um eine Person zu identifizieren, die von oder für eine Polizeibehörde im USA verwendet werden soll. [Muss behoben werden]
  • Für Apps, die Gesichtserkennungs- oder emotionale Rückschlusstechnologien verwenden, müssen Sie in der App-Beschreibung ein prominentes Tag oder einen Hinweis auf jede dieser Funktionen angeben. [Muss behoben werden]
    • Apps, die Gesichtsausdrücke oder Gesichtsbewegungen verwenden, um emotionale Zustände wie Wut, Ekel, Glück, Traurigkeit, Überraschung, Angst oder andere Begriffe abzuleiten, die häufig verwendet werden, um den emotionalen Zustand einer Person zu beschreiben, können basierend auf der Überprüfung eingeschränkt werden.
    • Die Verwendung von Gesichtsausdrücken und Bewegungen, um nur einzelne Gesichtselemente, wie z. B. Lächeln oder erhobene Augenbrauen, zu erkennen und zu klassifizieren, ist erlaubt. Der wichtigste Unterschied besteht zwischen der Erkennung von Gesichtsausdrücken oder Bewegungen als visuelle Signale und dem Rückschluss eines emotionalen Zustands.

App-Paket und Teams Store-Eintrag

[Muss behoben werden]

App-Pakete müssen korrekt formatiert sein und alle erforderlichen Informationen und Komponenten enthalten.

Tipp

  • Sie müssen sicherstellen, dass die bereitgestellten Testkonten oder die Testumgebung dauerhaft gültig sind, d. h., bis die App im kommerziellen Marketplace live ist.

  • Sie müssen die folgenden detaillierten Testanweisungen für die Überprüfung Ihrer App-Einreichung beifügen:

    • Schritte zum Konfigurieren der App-Testkonten für den Fall, dass die App für die Authentifizierung auf externe Konten angewiesen ist.
    • Zusammenfassung des erwarteten App-Verhaltens für die wichtigsten Workflows innerhalb Teams.
    • Beschreiben Sie Einschränkungen, Bedingungen oder Ausnahmen für die Funktionen, Features und Lieferumfang in der langen Beschreibung der App und den zugehörigen Materialien.
    • Hervorhebung aller Überlegungen für Tester beim Überprüfen der App-Einreichung.
    • Füllen Sie die Testkonten mit Dummydaten vor, um tests zu unterstützen.
    • Wenn Sie Ihre Testkonten bereitstellen, stellen Sie sicher, dass Sie die Integration von Drittanbietern aktivieren.

Zurück zum Anfang

App-Manifest

[Muss behoben werden]

Das App-Manifest definiert die Konfiguration Ihrer App.

  • Ihr App-Manifest muss einem öffentlich veröffentlichten App-Manifestschema entsprechen. Weitere Informationen finden Sie unter App-Manifestreferenz. Übermitteln Sie Ihre App nicht mit einer Vorschauversion des App-Manifests.
  • Wenn Ihre App eine Bot- oder Nachrichtenerweiterung enthält, müssen die Details im App-Manifest mit den Bot Framework-Metadaten übereinstimmen, einschließlich Bot-Name, Logo, Link zur Datenschutzerklärung und Link zu den Nutzungsbedingungen.
  • Wenn Ihre App Microsoft Entra ID für die Authentifizierung verwendet, fügen Sie die Microsoft Entra Anwendungs-ID (Client) in das App-Manifest ein. Weitere Informationen finden Sie in der App-Manifestreferenz.

Verwendung des neuesten App-Manifestschemas

  • Wenn Ihre App einmaliges Anmelden (Single Sign-On, SSO) verwendet, müssen Sie Microsoft Entra ID im App-Manifest für die Benutzerauthentifizierung deklarieren. [Muss behoben werden]

  • Sie müssen ein öffentlich veröffentlichtes App-Manifestschema verwenden. Sie können Ihr App-Paket aktualisieren, um eine öffentliche Version des App-Manifestschemas 1.10 oder höher zu verwenden. [Muss behoben werden]

  • Wenn Sie ein App-Update übermitteln, erhöhen Sie nur die Versionsnummer der App. Die App-ID der aktualisierten App muss mit der App-ID der veröffentlichten App übereinstimmen. [Muss behoben werden]

  • Das Vorhandensein zusätzlicher Dateien im App-Paket ist nicht akzeptabel. [Muss behoben werden]

  • Die Versionsnummer muss im App-Manifestdateischema und im App-Manifestschema für zusätzliche Sprachen identisch sein. [Muss behoben werden]

  • Sie müssen das App-Manifestschema version 1.5 oder höher verwenden, um Ihre App zu lokalisieren. Um die App-Schemaversion 1.5 oder höher in Ihrer manifest.json-Datei zu verwenden, aktualisieren Sie das $schema Attribut auf 1.5 oder höher. Aktualisieren Sie die manifestVersion Eigenschaft auf $schema Version (in diesem Fall 1.5). [Muss behoben werden]

  • Wenn Sie eine vorhandene Funktion hinzufügen, aktualisieren oder entfernen, App-Manifest oder Partner Center-Metadaten hinzufügen oder entfernen, müssen Sie die App-Versionsnummer erhöhen und das neue App-Manifest zur Überprüfung in Ihrem Partner Center-Konto übermitteln. [Muss behoben werden]

  • Die Versionszeichenfolge muss dem SemVer-Standard (Semantic Versioning Specification) (MAJOR. KLEINER. PATCH). [Muss behoben werden]

  • Wenn Ihre App Administratoren erfordert, berechtigungen zu überprüfen und die Zustimmung im Teams Admin Center zu erteilen, müssen Sie im App-Manifest deklarieren webapplicationinfo . Wenn webapplicationinfo nicht im App-Manifest deklariert ist, wird die Seite Berechtigungen für Ihre App im Teams Admin Center als ... [Muss behoben werden] angezeigt.

  • Im Rahmen der Teams-App-Zertifizierung müssen Sie eine Produktionsversion des App-Manifests übermitteln. [Muss behoben werden]

  • Es wird empfohlen, die Microsoft Cloud-Partnerprogramm-ID (CCP-ID), früher als Microsoft Partner Network (MPN-ID) bezeichnet, im App-Manifest zu deklarieren. Die CCP-ID hilft bei der Identifizierung der Partner-organization, die die App erstellt. [Gut zu beheben]

  • Im App-Manifest deklarierte Bereiche und/oder Kontexte müssen innerhalb der App sichtbar sein. [Muss behoben werden]

App-Symbole

[Muss behoben werden]

Symbole sind eines der Standard Elemente, die personen beim Durchsuchen des Teams Store sehen.

Erweitern, um mehr zu erfahren

Ihre Symbole müssen die Marke und den Zweck Ihrer App unter Einhaltung der folgenden Anforderungen kommunizieren:

  • Die App-Farbe und das Gliederungssymbol, das im App-Eintrag übermittelt wird, müssen übereinstimmen. [Muss behoben werden]

    Screenshot: Farbsymbol und Gliederungssymbol sind identisch.

    Screenshot: Farbsymbol und Kontursymbol sind nicht identisch.

  • Ihr App-Paket muss zwei .png-Versionen Ihres App-Symbols enthalten: Ein Farbsymbol und ein Umrisssymbol. [Muss behoben werden]

  • Das Marketplace-Symbol, das als Teil des Marketplace-Eintrags der App in Ihrem Partner Center-Konto hochgeladen wurde, muss mit dem Farbsymbol in Ihrem App-Paket übereinstimmen. [Muss behoben werden]

  • Die Farbversion Ihres Symbols muss 192 x 192 Pixel betragen. Ihr Symbol kann eine beliebige Farbe oder mehrere Farben haben, muss aber auf einem einfarbigen oder vollständig transparenten quadratischen Hintergrund stehen. [Muss behoben werden]

  • In den folgenden Szenarien wird die Kontur-Version Ihres Symbols angezeigt:

    • Wenn Ihre App in Gebrauch ist und auf der App-Leiste auf der linken Seite von Teams gehostet wird.
    • Wenn ein Benutzer die Nachrichtenerweiterung Ihrer App anheftet.
  • Die Kontur muss 32 x 32 Pixel groß sein und kann weiß mit transparentem Hintergrund oder transparent mit weißem Hintergrund sein. Das Symbol darf keinen zusätzlichen Abstand um das Symbol haben. [Muss behoben werden]

  • Ihr App-Paket muss ordnungsgemäß dimensionierte und formatierte Symbole enthalten. Die Symbole müssen mit den Informationen in den Metadaten des Teams Store-Eintrags übereinstimmen. [Muss behoben werden]

Weitere Informationen finden Sie in den Richtlinien für Symbole.

App-Beschreibungen

Sie benötigen eine kurze und lange Beschreibung für Ihre App. Die App-Beschreibung trägt dazu bei, die Auffindbarkeit Ihrer App im Teams Store zu verbessern. Die Beschreibungen in Ihrer App-Konfiguration und in Partner Center müssen identisch sein.

Die Grafik zeigt ein Beispiel für eine geeignete App-Beschreibung in der Teams-App.

Die Grafik zeigt ein Fehlerszenario für eine unzureichende App-Beschreibung.



Erweitern, um mehr zu erfahren

Beschreibungen dürfen nicht direkt oder durch Vorschlag eine andere Marke (im Besitz von Microsoft oder anderweitig) deogaten. Stellen Sie sicher, dass Ihre Beschreibung keine Ansprüche enthält, die nicht begründet werden können. Beispielsweise garantierte Steigerung der Effizienz um 200 Prozent.

  • Die App-Beschreibung darf keine vergleichenden Marketinginformationen enthalten. Verwenden Sie beispielsweise keine Logos oder Marken von Wettbewerbern in der Angebotsliste, einschließlich Tags oder anderer Metadaten, die auf konkurrierende Angebote oder Marketplaces verweisen. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für vergleichende Marketinginformationen in der App-Beschreibung.

  • Link zu Kontaktdetails, erste Schritte, Hilfe oder Registrierung in der App-Beschreibung. [Gut zu beheben]

    Die Grafik zeigt ein Beispiel für Kontaktdetails, die in den App-Beschreibungen verknüpft sind.

    Die Grafik zeigt ein Beispiel für Kontaktdetails, die in den App-Beschreibungen nicht verknüpft sind.

  • Die App-Beschreibung muss die beabsichtigte Zielgruppe identifizieren, kurz und klar ihren eindeutigen und eindeutigen Wert erklären, unterstützte Microsoft-Produkte und andere Software identifizieren und alle Voraussetzungen oder Anforderungen für ihre Verwendung enthalten. Sie müssen alle Einschränkungen, Bedingungen oder Ausnahmen für die Funktionen, Features und Lieferumfang, wie in der Auflistung und den zugehörigen Materialien beschrieben, klar beschreiben, bevor der Kunde Ihr Angebot erwirbt. Die von Ihnen deklarierten Funktionen müssen sich auf die Kernfunktionen und die Beschreibung Ihres Angebots beziehen. [Muss behoben werden]

  • Wenn Sie Ihren App-Namen aktualisieren, ersetzen Sie den alten App-Namen in den Angebotsmetadaten im App-Manifest, in AppSource und wo zutreffend. [Muss behoben werden]

  • Einschränkungen und Kontoabhängigkeiten müssen im Manifest App Description, AppSource und Partner Center hervorgehoben werden. Zum Beispiel:

    • Unternehmenskonto
    • Kostenpflichtiges Abonnement
    • Eine andere Lizenz oder ein anderes Konto
    • Sprache
    • PstN-Wählverfahren (Public Switched Telephone Network)
    • Regionale Abhängigkeit
    • Vorlaufzeit für Die Buchung von Übersetzern oder Live-Agents
    • Rollenbasierte Funktionalität
    • Abhängigkeit von nativer App

    Die Grafik zeigt ein Beispiel für Einschränkungen, die in der App-Beschreibung hervorgehoben sind.

    Die Grafik zeigt ein Beispiel für Einschränkungen, die in App-Beschreibungen nicht hervorgehoben sind.

  • Wenn Ihre App für bestimmte Regionen oder geografische Standorte unterstützt wird, müssen Sie diese spezifische Regionsabhängigkeit in der App-Beschreibung im App-Manifest, im Partner Center und in AppSource für dieses Angebot angeben.

  • Wenn Sie auf Teams verweisen müssen, schreiben Sie die erste Referenz in der App-Auflistung als Microsoft Teams. Spätere Verweise können auf Teams-verkürzt werden. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für einen korrekten Verweis auf Teams in der App-Beschreibung.

    Die Grafik zeigt ein Beispiel für einen falschen Verweis auf Teams in der App-Beschreibung.

Kurzbeschreibung

Eine kurze Beschreibung muss eine kurze Zusammenfassung Ihrer App sein, die ihr Wertversprechen hervor hebt und sich an Ihre Zielgruppe richtet.

Was Sie tun sollten:

  • Halten Sie die kurze Beschreibung in einem Satz.
  • Die wichtigsten Informationen kommen an erster Stelle.
  • Fügen Sie Schlüsselwörter hinzu, nach denen Kunden wahrscheinlich suchen.
  • Nutzen Sie das verfügbare Zeichenlimit effizient. Wiederholen Sie beispielsweise nicht Ihren App-Namen.

Don’ts:

[Gut zu beheben]

Verwenden Sie das Wort App in der Kurzbeschreibung.

Lange Beschreibung

Die lange Beschreibung muss eine ansprechende Geschichte liefern, die das Wertversprechen Ihrer App, die primäre Zielgruppe und die Zielbranche hervorhebt. Die Beschreibung kann zwar bis zu 4.000 Zeichen lang sein, es wird jedoch empfohlen, eine kurze Beschreibung von etwa 1.000 Zeichen zu verwenden.

Was Sie tun sollten:

  • Verwenden Sie Markdown, um Ihre Beschreibung zu formatieren.

  • Verwenden Sie aktive Stimme und sprechen Sie direkt mit Benutzern. Zum Beispiel können Sie ....

  • Listen Sie die wichtigsten Vorteile auf, um die Vorteile der Verwendung Ihrer App hervorzuheben. Addieren Sie bis zu drei Vorteile.

  • Fügen Sie das wichtigste Wertversprechen Ihrer App in Teams hinzu.

  • Listen Sie Features mit Aufzählungspunkten auf, damit die Beschreibung einfacher durchsucht werden kann.

  • Beschreiben Sie die Einschränkungen, Features, Bedingungen oder Ausnahmen für die Funktionalität sowie die Lieferleistungen in der Auflistung und den zugehörigen Materialien eindeutig, bevor der Benutzer Ihre App installiert. Die Teams-Funktionen müssen sich auf die in der Auflistung beschriebenen Kernfunktionen beziehen.

  • Stellen Sie sicher, dass die App-Beschreibung mit der in der Teams-App verfügbaren Funktionalität übereinstimmt. Jeder Verweis auf Arbeitsabläufe außerhalb der Teams-App muss begrenzt sein und sich deutlich von den Funktionen der Teams-App abheben.

  • Fügen Sie einen Hilfe- oder Support-Link hinzu.

  • Verweisen Sie auf Microsoft 365 anstelle vonOffice 365.

  • Verwenden Sie die folgende Sprache, wenn Sie beschreiben, wie die App mit Teams (oder Microsoft 365) funktioniert:

    • ... funktioniert mit Microsoft Teams.
    • ... mit Microsoft Teams arbeiten.
    • ... in Microsoft Teams.
    • ... für Microsoft Teams.
    • ... in Microsoft Teams integriert.
    • ... erstellt für...
    • ... entwickelt für...
    • .. konzipiert für...

Was Sie nicht tun sollten:

[Muss behoben werden]

  • Überschreitet 500 Wörter.

  • Kürzen Sie Microsoft als MS oder MSFT.

    Die Grafik zeigt ein Beispiel dafür, wie Microsoft zum ersten Mal in der App-Beschreibung als MS oder MSFT abgekürzt wird.

    Die Grafik zeigt ein Beispiel dafür, dass Microsoft nicht zum ersten Mal in der App-Beschreibung als MS oder MSFT abgekürzt wird.

  • Geben Sie an, dass es sich bei der App um ein Angebot von Microsoft handelt, einschließlich der Verwendung von Microsoft-Slogans oder Leitsätzen.

    Die Grafik zeigt ein Beispiel dafür, wie das Microsoft-Angebot in der App-Beschreibung nicht angegeben wird.

    Grafik, die ein Beispiel für das Schreiben einer App-Beschreibung zeigt, ohne Microsoft-Slogans und -Taglines zu verwenden.

  • Die Verwendung folgender Sprache, es sei denn, Sie sind ein zertifizierter Microsoft-Partner:

    • ... zertifiziert für ...
    • ... unterstützt von ...
  • Tippfehler, Grammatikfehler einschließen.

  • Unnötiges Großbuchstaben für das gesamte App-Manifest oder die lange AppSource-Beschreibung oder den App-Inhalt.

    Die Grafik zeigt ein Beispiel für eine lange App-Beschreibung ohne Fehler.

    Die Grafik zeigt ein Beispiel für eine lange App-Beschreibung mit Tippfehlern und Fehlern.

  • Links zu AppSource einschließen.

    Die Grafik zeigt ein Beispiel für ein Fehlerszenario mit Links zu AppSource in der langen App-Beschreibung.

  • Ungeprüfte Behauptungen aufstellen. Zum Beispiel „am besten“, „Top“ und „am besten bewertet“, es sei denn, dies wird mit der Quelle des Anspruchs angegeben.

  • Vergleichen Sie Ihr Angebot mit anderen Marketplace-Angeboten.

Eine Anleitung zum Erstellen einer genauen, präzisen und informativen kurzen und langen Beschreibung finden Sie in der Checkliste zum Schreiben von App-Beschreibungen.

Screenshots

Screenshots bieten eine auffällige visuelle Vorschau Ihrer App, um Ihren App-Namen, das Symbol und die Beschreibungen zu ergänzen.



Erweitern, um mehr zu erfahren

Beachten Sie Folgendes:

  • Sie können bis zu fünf Screenshots pro Eintrag erstellen.
  • Unterstützte Dateitypen sind PNG, JPEG und GIF.
  • Die Abmessungen müssen 1366 x 768 Pixel betragen.
  • Maximale Größe von 1 024 KB.

Was Sie tun sollten:

  • Konzentrieren Sie sich auf die Funktionen Ihrer App. Beispielsweise, wie Personen mit Ihrem Bot kommunizieren können.

  • Fügen Sie Inhalte ein, die Ihre App genau darstellen.

  • Verwenden Sie Text mit Bedacht.

  • Rahmen Sie Screenshots mit einer Farbe, die Ihre Marke widerspiegelt und Marketinginhalte enthält.

  • Verwenden Sie hochauflösende Screenshots, die scharf sind und lesbaren und gut lesbaren Text enthalten. [Muss behoben werden]

  • Mindestens ein Screenshot muss die Funktionalität Ihrer App auf mobilen Geräten darstellen. [Muss behoben werden]

    Screenshot: Passed-Szenario der App-Funktionalität auf mobilen Geräten

  • Sie können bis zu fünf Screenshots pro Eintrag erstellen. Ihr App-Eintrag muss mindestens drei und maximal fünf Screenshots enthalten. [Muss behoben werden]

  • Verwenden Sie Modelle, die die tatsächliche Benutzeroberfläche der App zum Nutzen der Endbenutzer genau darstellen. Screenshots müssen die tatsächliche Benutzeroberfläche oder szenarien der App genau darstellen, die für die App relevant sind und sich darauf beziehen. [Muss behoben werden]

    Screenshot: Fehlerhaftes Szenario von Ergänzenden Inhalten, die im Screenshot verwendet werden

    Screenshot: Fehlerhaftes Szenario des Screenshots der tatsächlichen Benutzeroberfläche der App.

  • Muss app-Funktionalität oder Integration in Teams darstellen. [Muss behoben werden]

    Screenshot des Szenarios mit einem Fehler bei der App-Funktionalität oder -Integration.

  • Die bereitgestellten Screenshots dürfen nicht fälschlicherweise auf Microsoft Teams als MS, MSFT oder MS Teams verweisen. [Muss behoben werden]

  • Wenn Ihre Teams-App auf Microsoft 365-Clients (Microsoft 365, Outlook und Microsoft Teams) erweiterbar ist, müssen die bereitgestellten Screenshots die App-Funktionalität in anderen Microsoft 365-Clients darstellen. [Muss behoben werden]

    Screenshot des erfolgreichen Szenarios der Teams-App-Funktionalität in MS 365-Clients.

  • Sie müssen Beschriftungen in Ihren Screenshots angeben, damit der Benutzer die App-Funktion klar verstehen kann. [Muss behoben werden]

    Screenshot des erfolgreichen Szenarios der Aufmerksamkeit des Benutzers für die App-Funktionalität.

  • Wenn Ihre App Registerkarten als Funktion unterstützt, müssen die Screenshots, die die App im Kontext einer Teams-Registerkarte in der App-Auflistung zeigen, das Chrom von Team enthalten. [Muss behoben werden]

    Screenshot: Bestandenes Szenario des Screenshots der Registerkartenfunktion.

Was Sie nicht tun sollten:

  • Schließen Sie Modelle ein, die die tatsächliche Benutzeroberfläche Ihrer App ungenau widerspiegeln, z. B. zeigen, dass Ihre App außerhalb von Teams verwendet wird.

    Screenshot: Fehlerhaftes Szenario mit nicht verknüpfter App-Funktionalität in Teams

Videos

Ein Video in Ihrem App-Eintrag ist eine der effektivsten Möglichkeiten, um zu kommunizieren, warum Personen Ihre App verwenden müssen. Sie können Ihre YouTube- oder Vimeo-Video-URL hinzufügen, die den Wert Ihrer App bereitstellt. Als bewährte Methode empfiehlt es sich außerdem, ein Video hinzuzufügen, das die exemplarische Vorgehensweise für die Demo oder das Szenario Ihrer App enthält. [Gut zu beheben]

Wenn Sie ein Video als Teil Ihres App-Eintrags in Ihrem Partner Center-Konto übermitteln möchten, stellen Sie sicher, dass sie die folgenden Kriterien erfüllen:

  • Das Video muss kurz, klar, ansprechend und von guter Qualität sein.

  • Das Video muss veranschaulichen, wie die App eingerichtet und verwendet wird.

  • Das Video muss in einer narrativen Form vorliegen.

  • Die Dauer des Videos muss innerhalb von 60 bis 90 Sekunden für ein Wertvideo und die empfohlene Dauer für ein exemplarische Vorgehensweisenvideo 3 bis 5 Minuten betragen. [Gut zu beheben]

  • Sie müssen Werbung aus Den Einstellungen Ihres YouTube- oder Vimeo-Kontos deaktivieren, bevor Sie den Videolink in der App-Auflistung übermitteln. [Muss behoben werden]

  • Das Video muss die Funktionen und die Integration Ihrer App in Teams hervorheben. [Muss behoben werden]

  • Das Video muss als funktionaler Link verfügbar sein. [Muss behoben werden]

  • Das Video muss im Format https://www.youtube.com/watch?v=:id oder https://youtu.be/:id für YouTube und https://vimeo.com/:id für Vimeo vorliegen.

    Screenshot des Szenarios mit einem Fehler des Videos, das als Teil der App-Auflistung im Partner Center übermittelt wurde.

  • Das Video kann an der ersten Position des Screenshots oder Videos-Karussells in den App-Details (Teams Store und Admin Center) und AppSource-Seiten angezeigt werden. [Gut zu beheben]

  • Das Video zur Demo oder der exemplarischen Vorgehensweise des Szenarios muss darauf achten, Die Benutzer zu schulen und nicht Ihre App zu bewerben.

Weitere Informationen zu den Kriterien für das Erstellen eines App-Wertvideos oder eines exemplarischen Videos finden Sie in der Checkliste zum Erstellen eines Videos.



Datenschutzrichtlinie

[Muss behoben werden]

Die Datenschutzrichtlinie kann für Ihre Teams-App oder eine allgemeine Richtlinie für alle Ihre Dienste spezifisch sein.

  • Wenn Sie eine generische Vorlage für Datenschutzrichtlinien verwenden, müssen Sie im Rahmen Ihrer Datenschutzerklärung einen Verweis auf Dienste, Anwendungenoder Plattformenhinzufügen. Sie müssen Ihre Teams-App nicht im Bereich angeben, wenn Sie einen Verweis auf Dienste, Anwendungen und Plattformen einschließen. Der App-Validierungsprozess interpretiert diese Verweise so, dass Ihre Teams-App zusammen mit Ihren anderen Diensten oder Websites eingeschlossen wird.
  • Muss beinhalten, wie Sie mit der Speicherung, Aufbewahrung und Löschung von Benutzerdaten umgehen. Sie müssen die Sicherheitskontrollen für den Datenschutz beschreiben.
  • Muss Ihre Kontaktdaten enthalten.
  • Darf keine URLs enthalten, die fehlerhaft sind oder für Beta- oder für Staging-Zwecke verwendet werden.
  • Darf keine Links zu AppSource enthalten.
  • Für den Zugriff auf die Datenschutzrichtlinie darf keine Authentifizierung erforderlich sein.
  • Darf keine kommerziellen UI- oder Shop-Links enthalten.
  • Muss denselben Link im App-Manifest und in AppSource aufweisen.

Nutzungsbedingungen

[Muss behoben werden]

Verwenden Sie die folgenden Richtlinien, um die Nutzungsbedingungen zu schreiben:

  • Muss spezifisch und auf Ihr Angebot anwendbar sein.
  • Muss in Ihrer eigenen Domäne gehostet werden.
  • Muss über einen sicheren Link (HTTPS) verfügen.
  • Der Zugriff auf Nutzungsbedingungen darf keine Authentifizierung erfordern.
  • Muss denselben Link im App-Manifest und in AppSource aufweisen.

[Muss behoben werden]

Die Support-URLs Ihrer App dürfen keine Authentifizierung erfordern. Benutzer müssen z. B. ohne Anmeldung mit Ihnen kontaktieren dürfen.

Erweitern, um mehr zu erfahren

Support-URLs müssen Ihre Kontaktdetails oder eine Möglichkeit zur Weiterleitung enthalten, damit Benutzer ein Supportticket erstellen können. Wenn Ihre Support-URL beispielsweise auf GitHub gehostet wird, muss die GitHub-Seite in Ihrem Besitz sein und Ihre Kontaktdetails oder eine Möglichkeit zur Erstellung eines Supporttickets für Benutzer enthalten.

validation-support-links-auth

Lokalisierung

[Muss behoben werden]

  • Wenn Ihre App Lokalisierung unterstützt, muss Ihr App-Paket eine Datei mit Sprachübersetzungen enthalten, die basierend auf der Spracheinstellung von Teams angezeigt werden. Die Datei muss dem Lokalisierungsschema von Teams entsprechen. Weitere Informationen finden Sie unter Teams-Lokalisierungsschema. [Muss behoben werden]

  • App-Metadateninhalte müssen in en-us und anderen Lokalisierungssprachen identisch sein. [Muss behoben werden]

  • Unterstützte Sprachen müssen in der AppSource-App-Beschreibung angezeigt werden. Diese App ist beispielsweise in X (X= lokalisierte Sprache) verfügbar. [Muss behoben werden]

  • Wenn die Clienteinstellungen des Benutzers mit keiner Ihrer zusätzlichen Sprachen übereinstimmen, wird die Standardsprache als endgültige Fallbacksprache verwendet. Aktualisieren Sie die localizationInfo Eigenschaft mit der richtigen Standardsprache, die Ihre Anwendung unterstützt. [Muss behoben werden]

  • Aktualisieren Sie die localizationInfo Eigenschaft mit der richtigen Standardsprache, die Ihre Anwendung unterstützt, oder fügen Sie lokalisierten Inhalt für das App-Manifest und die lange und kurze Beschreibung von Partner Center hinzu. [Muss behoben werden]

Apps, die mit dem SaaS-Angebot verknüpft sind

Dieser Abschnitt entspricht der Microsoft-Richtlinie für den kommerziellen Marketplace 1140.5. Wenn Sie eine Teams-App erstellen, die mit einem SaaS-Angebot (Software-as-a-Service) verknüpft ist, stellen Sie sicher, dass sie diesen Richtlinien entspricht.

Allgemein
  • ISVs müssen die Möglichkeit unterstützen, dass mehrere Benutzer (Abonnenten) im selben Tenant ihr eigenes Abonnement verwalten und den Benutzern im Tenant Lizenzen zuweisen können.
  • Das Angebot muss alle technischen Anforderungen für Teams-Apps erfüllen, die mit einem SaaS-Angebot verknüpft sind.
  • Die mit dem SaaS-Angebot verbundenen Teams-Apps müssen alle in 1000 Software-As-A-Service (SaaS)definierten Anforderungen erfüllen.
  • subscriptionOffer Die in der App-Manifestdatei erwähnten Details müssen korrekt sein. Fügen Sie in Ihrem App-Manifest den Knoten subscriptionOffer mit dem Wert publisherId.offerIdhinzu oder aktualisieren Sie ihn. Wenn Ihre Herausgeber-ID beispielsweise contoso1234 und Ihre Angebots-ID offer01ist, muss der Wert, den Sie in Ihrem App-Manifest angeben, contoso1234.offer01lauten.
  • Das verknüpfte SaaS-Angebot mit der Teams-App muss in AppSource live sein, und Vorschauangebote werden für die Genehmigung im Teams Store nicht akzeptiert.

Angebotsmetadaten
  • Angebotsmetadaten müssen über das App-Manifest, die Teams-App-Auflistung in AppSource und das SaaS-Angebot in AppSource übereinstimmen.
  • Teams-App und SaaS-Angebot müssen vom selben Herausgeber oder Entwickler stammen. Das SaaS-Angebot, auf das im App-Manifest verwiesen wird, muss demselben Herausgeber angehören, wie die Teams-App an den kommerziellen Marketplace übermittelt wird.
  • Da es sich bei Ihrem übermittelten Angebot um eine Teams-App handelt, die mit dem SaaS-Angebot verknüpft ist, müssen Sie Zusätzliche Käufe als Ja, mein Produkt erfordert den Kauf eines Diensts oder zusätzliche In-App-Käufe im Partner Center-Produktsetupabschnitt Ihres Angebotseintrags auswählen.
  • Plan-Beschreibungen und Preisdetails müssen genügend Informationen für Benutzer bereitstellen, um die Angebotsauflistungen klar zu verstehen.
  • Alle Einschränkungen, Abhängigkeiten von zusätzlichen Diensten und Ausnahmen von angebotenen Features müssen in den Planbeschreibungen genau hervorgehoben werden.
  • Die Teams-Apps, die mit dem SaaS-Angebot verknüpft sind, sind so konzipiert, dass sie Lizenzen unterstützen, die pro Benutzer zugewiesen werden. Manchmal ist das SaaS-Angebot mit anderen Methoden aufgebaut oder hat spezielle Kaufabläufe. Sie müssen in den Metadaten der App und in den Details des Abonnementplans deutlich auf die Methode und die Kaufabläufe hinweisen.
  • Das SaaS-Angebot muss allen Nutzern in allen Phasen des Kaufprozesses Nachrichten und Anleitungen bereitstellen.

Startseite und Lizenzverwaltung des SaaS-Angebots
  • Stellen Sie Abonnenten eine Einführung in die Verwendung des Produkts bereit.

  • Zulassen, dass der Abonnent Lizenzen zuweist.

  • Bieten Sie verschiedene Möglichkeiten, sich mit dem Support für Probleme zu befassen, z. B. häufig gestellte Fragen, Wissensdatenbank und E-Mail.

  • Überprüfen Sie die Benutzer, um sicherzustellen, dass ihnen nicht bereits eine Lizenz durch einen anderen Benutzer zugewiesen wurde.

  • Benutzer nach der Lizenzzuweisung benachrichtigen.

  • Führen Sie Benutzer an, wie Sie die App zu Teams hinzufügen und über den Teams-Chat-Bot oder per E-Mail beginnen.

  • Wenn eine SaaS-App die Microsoft-Lizenzverwaltung verwendet, muss der Benutzer nach der Bestätigung des App-Abonnements auf der Angebotsseite des ISV zur Microsoft-Lizenzverwaltung in Teams umgeleitet werden, um eine Sackgasse zu vermeiden und dem Benutzer die Verwaltung von Lizenzen in Teams zu ermöglichen.


Benutzerfreundlichkeit und Funktionalität
  • Nach dem erfolgreichen Kauf und der Zuweisung von Lizenzen müssen Sie Folgendes angeben:
    • Zugang zu Nutzern für abonnierte Plan-Features.
    • Zusätzlicher Nutzen und bedeutende Vorteile des Abonnements für die Nutzer.
    • Stellen Sie in Ihrer Teams-App einen Link zur Startseite der SaaS-Anwendung bereit, auf der Abonnenten die Lizenzen in Zukunft verwalten können.

Konfigurieren und Testen einer SaaS-Anwendung

Wenn die Einrichtung Ihrer App zu Testzwecken komplex ist, stellen Sie ein End-to-End-Funktionsdokument, konfigurationsschritte für verknüpfte SaaS-Angebote und Anweisungen für die Lizenz- und Benutzerverwaltung als Teil Ihrer Hinweise für die Zertifizierung bereit.

Tipp

Sie können ein Video zur Funktionsweise Ihrer App und Lizenzverwaltung hinzufügen, um das Team beim Testen zu unterstützen.

Zurück zum Anfang

Registerkarten

Dieser Abschnitt entspricht der Microsoft-Richtlinie für den kommerziellen Marketplace 1140.4.2. Wenn Ihre App eine Registerkarte enthält, stellen Sie sicher, dass sie diesen Richtlinien entspricht.

Tipp

Weitere Informationen zum Erstellen einer qualitativ hochwertigen App finden Sie unter Richtlinien zum Entwerfen von Teams-Registerkarten.


              
                             Setup
  • Die Registerkarteneinrichtung darf keinen neuen Benutzer ins Tod führen. Geben Sie eine Nachricht zum Abschließen der Aktion oder des Workflows an. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für die Tabulatortaste mit einer Sackgasse beim Setup.

  • Der Benutzer darf die Registerkartenkonfiguration nicht innerhalb von Teams verlassen, um Inhalte außerhalb von Teams zu erstellen, und kehrt dann zu Teams zurück, um ihn anzuheften. Der Konfigurationsbildschirm der Registerkarte muss den Wert der Konfiguration erläutern und wie sie durchgeführt wird. [Muss behoben werden]

    validation-tabs-set-up-profile-name

  • Der Registerkartenkonfigurationsbildschirm darf keine gesamte Website einbetten. Konzentrieren Sie sich auf Ihre Konfigurationserfahrung. Wenn Sie z. B. eine Projektmanagement-Anwendung entwickeln, mit der Benutzer ein Projekt in einem Kanal konfigurieren können, sollten Sie den Konfigurationsbildschirm für die Registerkarte so gestalten, dass der Benutzer ein Projekt aus Ihrer Anwendung auswählen kann, um es im Kanal zu konfigurieren. [Muss behoben werden]

    validation-tabs-setup-configuration-exp

    validation-tabs-set-up-configuration-screen

  • Apps, bei denen Benutzer beim Konfigurieren einer Registerkarte eine URL eingeben müssen, müssen:

    • Stellen Sie dem Benutzer eine geeignete Anleitung für die Weiterleitung bereit, um die URL zu erhalten oder zu generieren. [Muss behoben werden]

    • Suchen Sie nach einer URL, die gemäß der App-Beschreibung für die App-Funktionalität relevant oder geeignet ist. [Muss behoben werden]

      Screenshot: Beispiel für die Registerkartenkonfiguration mit einer Möglichkeit zum Generieren einer URL durch den Benutzer

      Screenshot: Beispiel für die Registerkartenkonfiguration ohne Möglichkeit zum Generieren einer URL durch den Benutzer

  • Link zu den Kontaktinformationen auf dem Konfigurationsbildschirm anstelle von Nur-Text, um Benutzern zu helfen, Sie für Supportanforderungen zu kontaktieren. [Muss behoben werden]

  • Für eine nahtlose Benutzererfahrung bei der ersten Ausführung wird empfohlen, auf dem Konfigurationsbildschirm einen Link zu Ihrer Support-URL oder E-Mail-Adresse zu erstellen. [Gut zu beheben]


Ansichten
  • Der Anmeldebildschirmbereich darf keine großen Logos verwenden. [Muss behoben werden]

    validation-views-app-login

  • Inhalte können vereinfacht werden, indem sie auf mehrere Registerkarten verteilt werden.

    val-views-multiple-tabs

  • Registerkarten sollten keine doppelte Kopfzeile haben. Entfernen Sie doppelte Logos aus dem I-Frame, da das Registerkartenframework bereits das App-Symbol und den Namen anzeigt. [Gut zu beheben]

    Die Grafik zeigt ein Beispiel für eine Registerkarte ohne doppelte Kopfzeilen und Logos.

    Die Grafik zeigt ein Beispiel für eine Registerkarte mit doppelten Kopfzeilen und Logos.


Navigation

Im Folgenden sind die Navigationsrichtlinien aufgeführt:

  • Registerkarten dürfen keine Navigation bereitstellen, die mit der primären Teams-Navigation in Konflikt zu treten hat. Wenn Sie eine linke Navigation auf Ihrer Registerkarte bereitstellen, darf diese nicht nur Symbole oder Symbole mit gestapeltem Text enthalten. Es darf sich nicht um eine reduzierbare Schiene mit der Option zum Anzeigen von Symbolen mit gestapeltem Text (imItieren der Teams-Navigationsleiste) sein. Fügen Sie Symbole mit In-Zeile-Text oder nur Text ein, oder verwenden Sie Hamburger-Menüs anstelle der linken Tabulatorleiste. [Muss behoben werden]

    Entwerfen Sie Ihre App mit einfachen und erweiterten Fluent UI-Komponenten.

    Die Grafik zeigt ein Beispiel für die Navigation auf einer Registerkarte, die nicht mit der primären Teams-Navigation in Konflikt kommt.

    Die Grafik zeigt ein Beispiel für eine linke Navigationsschiene, die in Konflikt mit der primären Teams-Navigation besteht.

  • Wenn ihre Registerkarte auf der linken Schiene eine Symbolleiste ohne Navigationskomponente enthält, muss die Symbolleiste einen Abstand von 20 Pixeln vom linken Navigationsbereich von Teams beibehalten. [Muss behoben werden]

    validation-nav-spacing-between-toolbar

  • Die sekundären und tertiären Seiten in einer Registerkarte müssen in einer Ansicht der Ebene 2 (L2) und ebene 3 (L3) im Standard Registerkartenbereich geöffnet werden, der über Breadcrumbs oder die linke Navigation navigiert wird. Sie können auch die folgenden Komponenten verwenden, um die Navigation auf einer Registerkarte zu unterstützen:

    • Zurück-Schaltflächen

    • Seitenüberschriften

    • Hamburger-Menüs

      Screenshot: Beispiel für ein Dialogfeld in einer Besprechung mit mehreren Navigationsebenen

  • Deep-Links in Registerkarten dürfen nicht mit einer externen Webseite, sondern innerhalb von Teams verknüpft sein. Beispielsweise Dialoge oder andere Registerkarten. [Muss behoben werden]

    validation-nav-view-button-not-linked-static-tab

  • Registerkarten dürfen Benutzern nicht erlauben, außerhalb von Teams für die Kern-App-Benutzeroberfläche zu navigieren. Registerkarten können für nicht zum Kerngeschäft gehörende Arbeitsabläufe außerhalb von Teams umgeleitet werden. Zum Beispiel, um ein Supportticket zu erstellen. [Muss behoben werden]

    validation-nav-core-workflow-within-configuration

    validation-nav-core-workflow-redirects-outside

  • Horizontaler Bildlauf darf in einer Besprechungsregisterkarte nicht vorhanden sein. [Muss behoben werden]

  • In Besprechungsdialogen, die in Ihrer App verwendet werden, dürfen keinen horizontalen Bildlauf zulassen. Verwenden Sie Besprechungsdialoge sparsam und für Szenarien, die leicht und aufgabenorientiert sind. Sie können die Breite des I-Frames des Besprechungsdialogfelds innerhalb des unterstützten Größenbereichs angeben, um verschiedene Szenarien zu berücksichtigen. [Muss behoben werden]

  • In Ihrer App verwendete Dialoge dürfen keinen horizontalen Bildlauf zulassen. Mithilfe von Dialogfeldern können Sie verschiedene Größen auswählen, damit der Inhalt ohne horizontalen Bildlauf reaktionsfähig ist. Bei Bedarf können Sie eine Stageview (eine Vollbild-UI-Komponente zum Anzeigen Ihrer Webinhalte) verwenden, um den Workflow ohne horizontalen Bildlauf abzuschließen. [Muss behoben werden]

  • Horizontaler Bildlauf, der auf der Registerkarte in einem persönlichen Chat, Kanal und in besprechungsinternen Details in einem bereich vorhanden ist, ist nicht zulässig, wenn der gesamte Registerkartenbereich scrollbar ist, es sei denn, Ihre Registerkarte verwendet eine unendliche Canvas mit festen UI-Elementen. [Muss behoben werden]

    Die Grafik zeigt Beispiele für alle Szenarien auf Mobilgeräten, in denen horizontaler Bildlauf zulässig ist.

    Die Grafik zeigt ein Beispiel für einen horizontalen Bildlauf im Kanban-Board.

    Die Grafik zeigt ein Beispiel für eine Listenansicht mit vielen Komponenten.

    Die Grafik zeigt ein Beispiel für einen horizontalen Bildlauf in einem Whiteboard mit unendlichem Zeichenbereich und fester Tafel.

    Die Grafik zeigt ein Beispiel für einen horizontalen Bildlauf in der Listenansicht.

  • Der Benutzer muss über eine Option verfügen, um zum vorherigen Arbeitszustand zu wechseln. [Muss behoben werden]

     Screenshot: Schaltflächenoption

    Screenshot: Fehlerszenario mit der Option

  • Horizontaler Bildlauf in adaptiven Karten darf in Teams nicht vorhanden sein. [Muss behoben werden]

  • Die untere Schiene, die für die Navigation in Registerkarten verwendet wird, darf nicht in Konflikt mit der nativen Navigation für mobile Teams-Apps treten. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für eine Registerkarte, die mit der nativen Navigation mobiler Apps in Teams in Konflikt gerät.


Brauchbarkeit
  • Inhalte dürfen innerhalb der Registerkarte nicht abgeschnitten oder überlappen. [Muss behoben werden]

    validation-usability-content-truncations

  • Benutzer müssen in der Lage sein, ihre letzte Aktion auf der Registerkarte rückgängig zu machen. [Muss behoben werden]

  • Registerkarten in einem persönlichen Kontext können Inhalte von freigegebenen Instanzen der App aggregieren. So muss beispielsweise eine Projektmanagement-App mit einer konfigurierbaren Registerkarte, die es Kanalmitgliedern ermöglicht, das Projekt auf Kanban-Karten zu kommentieren, diese Inhalte zusammenfassen und in der persönlichen App anzeigen. [Gut zu beheben]

  • Registerkarten müssen für Teams-Designs reaktionsfähig sein. Wenn ein Benutzer das Design ändert, muss das Design der App die Auswahl widerspiegeln. [Gut zu beheben]

    Die Grafik zeigt ein Beispiel für eine Registerkarte, die auf ein Design in Teams reagiert.

    Die Grafik zeigt ein Beispiel für eine Registerkarte, die nicht auf das Design in Teams reagiert.

  • Registerkarten müssen nach Möglichkeit Microsoft Teams-Stilkomponenten wie Teams-Schriftarten, Typrampen, Farbpaletten, Rastersystem, Bewegung, Tonfall verwenden. Weitere Informationen finden Sie in den Richtlinien für das Registerkartendesign. [Gut zu beheben]

    Screenshot: Beispiel für eine Registerkarte mit Calibri-Schriftart anstelle der nativen Teams-Schriftart

  • Wenn Ihre App-Funktionalität Änderungen an den Einstellungen erfordert, schließen Sie eine Registerkarte Einstellungen ein. [Gut zu beheben]

  • Registerkarten müssen dem Design der Teams-Interaktion folgen, z. B. seiteninterne Navigation, Position und Verwendung von Dialogen, Informationshierarchien. Weitere Informationen finden Sie unter Microsoft Teams Fluent UI Kit. [Gut zu beheben]

  • Registerkartenfunktionen müssen auf Mobilgeräten (Android und iOS) vollständig responsiv sein. [Muss behoben werden]

    Tipp

    • Fügen Sie einen persönlichen Bot neben einer persönlichen Registerkarte ein.
    • Erlauben Sie Benutzern, Inhalte von ihrer persönlichen Registerkarte zu teilen.
  • Die Registerkarte darf keine Elemente enthalten, die Workflows innerhalb der Registerkarte vollständig behindern oder behindern. Beispiel: Bot in einer Registerkarte, die nicht minimiert werden kann. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für eine Registerkarte mit Elementen, die Workflows innerhalb der Registerkarte behindern.

  • Tab darf keine fehlerhafte Funktionalität aufweisen. Ihr Angebot muss eine verwendbare Softwarelösung sein und die Funktionen, Features und Lieferumfang bereitstellen, wie in Ihrem Eintrag und anderen verwandten Materialien beschrieben. [Muss behoben werden]

  • Wenn Ihre Registerkarten eine Fußzeile enthalten, stellen Sie sicher, dass Sie alle Links, die nicht mit der App-Funktionalität zusammenhängen, aus der Fußzeile entfernen. [Muss behoben werden]


Bereichsauswahl
  • Inhalte auf der Landing Page von konfigurierbaren Registerkarten dürfen nicht für den individuellen Gebrauch bestimmt werden und dürfen keine persönlichen Inhalte wie Meine Aufgaben oder Mein Dashboard enthalten. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für Inhalte auf einer konfigurierbaren Registerkarte mit persönlichem Bereich, z. B.

  • Nach der Konfiguration muss auf der Landing Page eine Gemeinsame Ansicht für das gesamte Team angezeigt werden. [Muss behoben werden]

  • Wenn Ihre App die Bereitstellung einer persönlichen Bereichsansicht für den Benutzer erfordert, um die Effizienz oder Produktivität am Arbeitsplatz zu steigern, verwenden Sie gefilterte Ansichten, Deep Links zu persönlichen Apps oder navigieren Sie auf der konfigurierbaren Registerkarte zu L2- oder L3-Ansichten, und halten Sie die Zielseite für alle Benutzer kontextbezogen gleich. [Muss behoben werden]

  • Der Inhalt der Landing Page der konfigurierbaren Tabs muss für alle Mitglieder des Channels kontextuell gleich sein. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für Inhalte auf der Startseite der konfigurierbaren Registerkarten, die sich kontextabhängig für alle Mitglieder unterscheiden.

  • Konfigurierbare Registerkarten müssen über eine gezielte Funktionalität verfügen. [Muss behoben werden]

    validation-usability-configurable-nested-tab


Zurück zum Anfang

Bots

Dieser Abschnitt entspricht der Microsoft-Richtlinie für den kommerziellen Marketplace 1140.4.3.

Wenn Ihre App einen Bot enthält, stellen Sie sicher, dass er diesen Richtlinien entspricht.

Tipp

Weitere Informationen zum Erstellen eines qualitativ hochwertigen App-Erlebnisses finden Sie unter Entwurfsrichtlinien für Teams-Bots.


Richtlinien für den Botentwurf
  • Ihre Teams-App muss den Entwurfsrichtlinien für Teams-Bots entsprechen.

  • Sie müssen ein Dialogfeld implementieren, um eine Botantwort mit mehreren Durchläufen zu vermeiden, wenn der Workflow den Benutzer mit sich wiederholenden Aufgaben einschließt. Verwenden Sie beispielsweise ein Dialogfeld, um Namen, Geburtsdatum, Ort und Bezeichnung wiederholt zu erfassen, anstatt Unterhaltungen mit mehreren Durchläufen zu verwenden. [Muss behoben werden]

  • Alle fehlerhaften Links, Antworten oder Workflows in Ihrer App müssen behoben werden. [Muss behoben werden]


Botbefehle

Die Analyse von Benutzereingaben und die Vorhersage der Benutzerabsicht ist schwierig. Botbefehle stellen Benutzern eine Reihe von Wörtern oder Ausdrücken bereit, die Ihr Bot verstehen kann.

  • Alle Befehle, die Ihr Bot unterstützt, müssen ordnungsgemäß funktionieren, einschließlich generischer Befehle wie Hi, Hellound Help. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für einen Bot, der auf generische Befehle reagiert.

    Die Grafik zeigt ein Beispiel für einen Bot ohne Reaktion auf generische Befehle.

  • Botbefehle dürfen einen Benutzer nicht in eine Sackgasse führen, die Befehle müssen immer einen Weg nach vorn bieten. [Muss behoben werden]

    validation-bot-commands-dead-end

  • Sie müssen mindestens einen gültigen Botbefehl im items.commands.title Abschnitt des App-Manifests auflisten und eine geeignete Beschreibung hinzufügen, die dem Benutzer Klarheit über den Botbefehl und dessen Verwendung gibt. Botbefehle, die commandLists im Abschnitt der App-Manifestoberfläche als vorab aufgefüllte Befehle im Botbefehlsmenü aufgeführt sind, bieten dem neuen Benutzer eine Möglichkeit, mit dem Bot zu interagieren. [Gut zu beheben]

  • Die Botantwort darf keine offiziellen Microsoft-Produktbilder oder Avatare enthalten. Verwenden Sie Ihre eigenen Ressourcen in Ihrer App. Die Verwendung von Microsoft-Produktbildern in Ihrer App ist nicht zulässig. Sie dürfen urheberrechtlich geschützte Microsoft-Produktbilder nur kopieren, ändern, verteilen, anzeigen, lizenzieren oder verkaufen, wenn Ihnen die ausdrückliche Genehmigung innerhalb des End-User-Lizenzvertrags (EULA), der Lizenzbedingungen, die den Inhalten beigefügt sind, oder in den Microsoft-Marken- und Markenrichtlinien erteilt wurde. [Muss behoben werden]

  • Bots müssen auf Benutzerbefehle reagieren, ohne einen Indikator für kontinuierliches Laden anzuzeigen. [Muss behoben werden]

  • Die Bot-Hilfebefehlsantwort darf den Benutzer nicht außerhalb von Teams umleiten. Die Bot-Hilfebefehlsantwort kann benutzer zu einer Canvas innerhalb der Teams-App umleiten oder eine Möglichkeit für die Vorwärtsantwort in einer adaptiven Karte bereitstellen. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für eine Botantwort, die Benutzer außerhalb von Teams umleitet.

  • Bots müssen immer eine gültige Antwort auf eine Benutzereingabe bereitstellen, auch wenn die Eingabe irrelevant oder falsch ist. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für eine gültige Antwort für einen nicht ordnungsgemäßen Botbefehl.

    Die Grafik zeigt ein Beispiel für eine ungültige Antwort für einen nicht ordnungsgemäßen Botbefehl.

  • Sonderzeichen wie Schrägstrich (/) dürfen Botbefehlen nicht vorangestellt werden. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für ein Szenario mit Einem Fehler, bei dem Botbefehlen Sonderzeichen vorangestellt werden.

  • Bots müssen eine gültige Antwort auf ungültige Benutzerbefehle bereitstellen. Bots dürfen den Benutzer nicht in die Sackgasse führen oder einen Fehler anzeigen, wenn ein Benutzer einen ungültigen Botbefehl sendet. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für einen Bot, der einen Weg nach vorne für einen ungültigen Befehl bietet.

    Die Grafik zeigt ein Beispiel für ein Fehlerhaftes Szenario, bei dem ein Bot eine gleiche Antwort für einen gültigen und ungültigen Befehl sendet.

  • Die Botfunktionalität muss für den Bereich relevant sein, in dem der Bot installiert ist, und der Bot muss einen Wert im installierten Bereich bereitstellen. [Muss behoben werden]

  • Bots dürfen keine doppelten Befehle enthalten. [Muss behoben werden]

  • Bots dürfen keinen Eingabeindikator anzeigen, nachdem sie auf den Benutzerbefehl reagiert haben, können aber während der Reaktion auf den Benutzerbefehl einen Eingabeindikator anzeigen. [Muss behoben werden]

  • Bots müssen eine gültige Antwort auf den in Klein- oder Großbuchstaben eingegebenen Hilfebefehl bereitstellen, der dem Benutzer einen Weg nach vorne bietet oder dem Benutzer den Zugriff auf die Hilfeinhalte im Zusammenhang mit der Verwendung des Bots ermöglicht. Bots müssen eine gültige Antwort bereitstellen, auch wenn sich der Benutzer nicht bei der App angemeldet hat. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel dafür, dass ein Bot keine gültige Antwort für einen Befehl in Klein- oder Großbuchstaben bereitstellt.

    Die Grafik zeigt ein Beispiel für einen Bot ohne gültige Antwort, wenn sich der Benutzer nicht bei der App angemeldet hat.

  • Bots müssen eine gültige Antwort auf den Befehl help bereitstellen.

    Die Grafik zeigt ein Beispiel für den Bot, der eine gültige Antwort an den Befehl help sendet.

  • Botantworten auf Mobilgeräten müssen reaktionsfähig sein, ohne dass Daten gekürzt werden, die die Botnutzung des Endbenutzers zum Abschließen der gewünschten Workflows behindern. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für eine Botnachricht ohne Abschneiden auf mobilgeräten.

    Die Grafik zeigt ein Beispiel für das Abschneiden einer Botnachricht auf mobilgeräten.

  • Alle Links in einer adaptiven Karte einer Botantwort müssen reaktionsfähig sein. Jeder Link, der den Benutzer außerhalb der Teams-Plattform führt, muss einen eindeutigen Umleitungstext aufweisen, z . B. Anzeigen in.. oder Auf diese Weise zu.., ein Popupsymbol in der Schaltfläche für die Botantwortaktion oder einen geeigneten Umleitungstext im Text der Botantwortnachricht enthalten. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für eine Aktionsschaltfläche für Botantworten mit einer Umleitung.

  • Standardmäßig, wenn Ihr Bot nicht reagiert oder keine Benutzerbefehle unterstützt und ein unidirektionales Bot ist, der nur dazu gedacht ist, Benutzer zu benachrichtigen. Sie müssen im App-Manifest auf true festlegen isNotificationOnly . [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für die Benachrichtigungseigenschaft, die im App-Manifest auf true festgelegt ist.

    Die Grafik zeigt ein Beispiel für einen Benachrichtigungsbot, der nicht auf die Nachricht eines Benutzers reagiert.

  • Die Benutzererfahrung für Bots darf auf mobilen Plattformen nicht unterbrochen werden. Ihr Bot muss auf Mobilgeräten vollständig reagieren. [Muss behoben werden]

Tipp

Fügen Sie für persönliche Bots eine Registerkarte Hilfe hinzu, die genauer beschreibt, was Ihr Bot tun kann.


Benutzeroberfläche für die erste Ausführung des Bots
  • Ein Bot im persönlichen Bereich muss immer Eine Willkommensnachricht senden oder Eingabeaufforderungsstarter bereitstellen. [Muss behoben werden]

    Wenn Sie Eingabeaufforderungsstarter verwenden, stellen Sie sicher, dass die folgenden Richtlinien erfüllt sind:

    Eingabeaufforderungsstarter helfen Benutzern, eine Konversation mit Ihrem Bot zu beginnen. Um Eingabeaufforderungsstarter zu aktivieren, muss die commands -Eigenschaft im App-Manifest definiert werden.

    • Der Bot muss mindestens einen Befehl bereitstellen, mit dem der Benutzer das Wertversprechen der App kennen kann. [Muss behoben werden]
    • Eingabeaufforderungsstarter oder -befehle müssen funktionsfähig sein und Antworten zurückgeben. [Muss behoben werden]
    • Die Befehlsbeschreibung muss kohärent sein und den Wert des Befehls klar kommunizieren. [Muss behoben werden]
    • Eingabeaufforderungsstarter oder -befehle müssen für die Funktionalität der App relevant sein. [Muss behoben werden]
    • Der Bot muss über mindestens drei eindeutige Eingabeaufforderungsstarter oder -befehle verfügen. [Gut zu beheben]

    Wenn Ihre App eine Willkommensnachricht sendet, stellen Sie sicher, dass die folgenden Richtlinien erfüllt sind:

    • Wenn die App über einen komplexen Konfigurationsflow verfügt (erfordert eine Unternehmenslizenz oder fehlt ein intuitiver Registrierungsflow), müssen Bots in solchen Apps immer Konfigurationsinformationen enthalten, während sie während der ersten Ausführung eine Willkommensnachricht senden.

      Um eine optimale Erfahrung zu erzielen, muss die Willkommensnachricht den Wert enthalten, den der Bot benutzern bietet, die den Bot im Kanal installiert haben, wie der Bot konfiguriert wird, und alle unterstützten Botbefehle kurz beschreiben. Sie können die Begrüßungsnachricht mithilfe einer adaptiven Karte mit Schaltflächen anzeigen, um die Benutzerfreundlichkeit zu verbessern. Weitere Informationen finden Sie unter Auslösen einer Bot-Begrüßungsnachricht. Für Apps ohne komplexen Konfigurationsablauf können Sie während der ersten Ausführung des Bots eine Willkommensnachricht auslösen. Wenn jedoch eine Begrüßungsnachricht ausgelöst wird, muss sie den Richtlinien für Begrüßungsnachrichten entsprechen.

      Die Grafik zeigt ein Beispiel für den Bot, der eine Willkommensnachricht sendet, wenn der Bot über einen komplexen Konfigurationsworkflow verfügt.

      Die Grafik zeigt ein Beispiel, in dem der Bot keine Willkommensnachricht sendet, wenn der Bot über einen komplexen Konfigurationsworkflow verfügt.

  • Bot-Begrüßungsnachrichten in Kanälen und Chats sind bei der ersten Ausführung optional, insbesondere wenn der Bot für den persönlichen Gebrauch verfügbar ist und ähnliche Aktionen ausführt. Ihr Bot darf keine Begrüßungsnachrichten einzeln an Benutzer senden (dies gilt als Spamming). In der Nachricht muss auch die Person erwähnt werden, die den Bot hinzugefügt hat.

    validation-bot-welcome-message-not-trigger

    validation-bot-wel-message-trigger

  • Die Willkommensnachricht darf den Benutzer nicht in die Sackgasse führen. Die Willkommensnachricht muss den Wert enthalten, den der Bot den Benutzern bietet, die den Bot im Kanal installiert haben, wie der Bot konfiguriert wird, und alle unterstützten Botbefehle kurz beschreiben. Sie können die Begrüßungsnachricht mithilfe einer adaptiven Karte mit Schaltflächen anzeigen, um die Benutzerfreundlichkeit zu verbessern. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für ein fehlgeschlagenes Szenario, bei dem der Bot für den Benutzer in einer Begrüßungsnachricht keine Möglichkeit hat, sich vorwärts zu machen.

    Die Grafik zeigt ein Beispiel für eine Bot-Willkommensnachricht mit einem klaren Weg, wie der Benutzer die Aufgabe abschließen kann.

  • Bot, der in einem Kanal- oder Gruppenchatbereich installiert ist, darf keine proaktive Willkommensnachricht an alle Teammitglieder im 1:1-Chat senden. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für den Bot, der eine proaktive Willkommensnachricht an alle Teammitglieder sendet.

  • Der Bot nur für Benachrichtigungen kann eine proaktive Begrüßungsnachricht in einem Kanal nur senden, wenn die Nachricht wichtige Informationen enthält, damit ein Benutzer die Konfiguration für den Bot abschließen kann, oder wenn die Szenarien erläutert werden, in denen Benachrichtigungen ausgelöst werden. [Muss behoben werden]

  • Ein bot, der in einem Kanal- oder Gruppenchatbereich installiert ist, darf keine proaktiven Nachrichten (nicht nur Willkommensnachricht) senden, die für alle Benutzer im Kanal- oder Gruppenchat irrelevant sind, sondern muss dem Benutzer proaktive Nachrichten über einen 1:1-Chat senden. [Muss behoben werden]

  • Ein bot, der in einem Kanal- oder Gruppenchatbereich installiert ist, darf Benutzern nicht das Starten einzelner Workflows ermöglichen. Bots müssen einzelne Workflows im 1:1-Chat mit dem Benutzer abschließen. [Muss behoben werden]

  • Die Bot-Willkommensnachricht muss deutlich auf die Einschränkungen im Zusammenhang mit der Botnutzung im installierten Bereich hinweisen. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für eine App-Einschränkung in der Bot-Willkommensnachricht.

    Die Grafik zeigt ein Beispiel für einen Bot ohne App-Einschränkung in einer Begrüßungsnachricht.

  • Die Willkommensnachricht muss bei der App-Installation in einem persönlichen Bereich automatisch ausgelöst werden. Wenn der Bot keine Willkommensnachricht in einem persönlichen Bereich sendet, führt der Benutzer zu einer Sackgasse. Wenn die App keinen komplexen Konfigurationsworkflow enthält, ist es optional, dass der Entwickler eine Willkommensnachricht im Kanal- oder Gruppenchatbereich auslöst. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel, in dem der Bot eine Willkommensnachricht nicht automatisch im persönlichen Bereich sendet.

  • Willkommensmeldungen dürfen bei der Botinstallation nur einmal ausgelöst werden. Willkommensmeldungen dürfen nicht jedes Mal ausgelöst werden, wenn der Benutzer den Hilfebefehl aufruft. Die Antwort auf Hilfebefehle muss so ausgerichtet sein, dass der Benutzer auf Hilfe im Zusammenhang mit dem Bot zugreifen kann. [Muss behoben werden]

  • Willkommensnachrichten dürfen nicht bei jedem Botbefehl ausgelöst werden. Dies gilt als Spam. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für den Bot, der eine Willkommensnachricht für einen beliebigen Befehl auslöst.

  • Der Inhalt der Willkommensnachricht muss sich auf den Botworkflow beziehen, der in der langen Beschreibung der App und im Installationsbereich erwähnt wird. Die Willkommensnachricht muss den Wert enthalten, den der Bot benutzern bietet, die den Bot im Kanal installiert haben, wie der Bot konfiguriert wird, und alle unterstützten Botbefehle kurz beschreiben. [Muss behoben werden]

  • Der Bot darf nicht mehrere Willkommensnachrichten senden, wenn er bei der App-Installation ausgelöst wird. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für den Bot, der bei der App-Installation mehrere Willkommensmeldungen auslöst.

  • Der App-Name in der Begrüßungsnachricht muss mit dem App-Namen im App-Manifest übereinstimmen. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für den App-Namen in der Willkommensnachricht, der nicht mit dem App-Namen im App-Manifest übereinstimmt.

  • Die Willkommensnachricht darf keine Namen der chatbasierten plattformbasierten Konkurrenz anzeigen, es sei denn, die App bietet eine bestimmte Interoperabilität.

  • Die Willkommensnachricht darf den Benutzer nicht an eine andere Teams-App umleiten. Stattdessen muss die Willkommensnachricht den Benutzer dazu animieren, seine erste Aufgabe auszuführen, und alle unterstützten Botbefehle in der App kurz beschreiben. [Muss behoben werden]

  • Die Willkommensnachricht darf keine Links zu einem App-Marketplace enthalten, einschließlich AppSource. [Muss behoben werden]

  • Wenn Ihre App über einen komplexen Konfigurationsworkflow verfügt, der eine vom Administrator geführte Installation erfordert, keinen intuitiven und leicht verfügbaren Registrierungsflow aufweist oder die Benutzer konfigurationsschritte außerhalb der Teams-Umgebung ausführen und zurückkehren müssen, muss der Bot nach der Installation eine proaktive Willkommensnachricht in einem Team- oder Gruppenchatbereich senden. [Muss behoben werden]

  • Wenn Ihr Bot eine Willkommensnachricht im Kanal sendet, darf er sie nicht einzeln an Benutzer senden (es wird als Spamming betrachtet). Die Begrüßungsnachricht muss auch die Person Erwähnung, die den Bot hinzugefügt hat. [Gut zu beheben]

Tipp

In Begrüßungsnachrichten an einzelne Nutzer kann eine Karussell-Tour einen effektiven Überblick über Ihren Bot und alle anderen App-Funktionen bieten, um Nutzer zu ermutigen, Bot-Befehle auszuprobieren. Erstellen Sie z. B. eine Aufgabe.


Spamming von Botnachrichten

Bots dürfen Benutzer nicht spamen, indem sie mehrere Nachrichten in kurzer Zeit senden.

  • Bot-Nachrichten in Kanälen und Chats: Spamen Sie Benutzer nicht, indem Sie separate Beiträge erstellen. Erstellen Sie einen einzelnen Beitrag mit Antworten im selben Thread. [Muss behoben werden]

    validation-bot-message-spam-one-message

    validation-bot-message-spam-multiple-message

  • Bot-Nachrichten in persönlichen Apps:

    • Senden Sie nicht mehrere Nachrichten in kurzer Folge. [Muss behoben werden]

      Die Grafik zeigt ein Beispiel für einen Bot, der mehrere Nachrichten in kurzer Folge sendet.

    • Senden Sie eine Nachricht mit vollständigen Informationen. [Muss behoben werden]

    • Vermeiden Sie mehrfache Unterhaltungen, um einen einzelnen sich wiederholenden Workflow abzuschließen. [Muss behoben werden]

    • Verwenden Sie ein Formular (oder Dialogfeld), um alle Eingaben eines Benutzers gleichzeitig zu sammeln. [Muss behoben werden]

    • NLP-basierte Chatbots können Multi-Turn-Konversationen nutzen, um die Diskussion ansprechender zu gestalten und einen Arbeitsablauf abzuschließen.

      validation-bot-message-using-task-module

      Die Grafik zeigt einen Beispielbot, der Nachrichten mit mehreren Durchläufen verwendet, um eine einzelne Unterhaltung abzuschließen.

  • Willkommensnachrichten: Wiederholen Sie nicht gleiche Willkommensnachricht in regelmäßigen Abständen. Wenn beispielsweise ein neues Mitglied zu einem Team hinzugefügt wird, sollten Sie die anderen Mitglieder nicht mit einer Begrüßungsnachricht spammen. Nachricht an das neue Mitglied persönlich senden. [Muss behoben werden]


Botbenachrichtigungen

Bot-Benachrichtigungen müssen Inhalte enthalten, die für den Bereich relevant sind, den Sie für den Bot definieren (Team, Chat oder persönlich). [Muss behoben werden]

validation-bot-notification-relevant

validation-bot-notification-not-relevant


Bots und adaptive Karten

Adaptive Karten sind eine dringend empfohlene Möglichkeit, Bot-Nachrichten anzuzeigen. Die Karten müssen einfach sein und nur bis zu sechs Aktionen enthalten. Um weitere Inhalte anzuzeigen, sollten Sie ein Dialogfeld oder eine Registerkarte verwenden.

Weitere Informationen zu Karten finden Sie unter:

Die Bot-Erfahrung muss auf Mobilgeräten vollständig responsiv sein. Die Bot-Antworten müssen gegebenenfalls einen Weg nach vorn aufzeigen. Bots müssen reaktionsschnell sein und bei Fehlern eine ansprechende Fehlermeldung anzeigen. Bot-Nachrichten, die im persönlichen Bereich an die Basis des Benutzers auf Triggern in einem gemeinsamen Bereich gesendet werden, müssen kontextbezogene Informationen (einschließlich des Nachrichtenursprungs) bereitstellen.


Bots nur für Benachrichtigungen

Apps, die aus reinen Benachrichtigungs-Bots bestehen, bieten dem Nutzer einen Mehrwert, indem sie auf der Grundlage bestimmter Auslöser oder Ereignisse in der Hauptanwendung oder im Backend Benachrichtigungen für den Nutzer auslösen. Beispielsweise wird ein neuer Vertriebsleiter oder Einsteiger hinzugefügt, den das Vertriebsteam weiter verfolgen kann. Ein sehr guter Benachrichtigungsbot benachrichtigt die Benutzer regelmäßig über bestimmte Ereignisvervollständigungen, z. B. Workflowvervollständigungen oder Warnungen.

Tipp

Zeigen Sie Informationen in der Vorschau an, und stellen Sie grundlegende Inline-Benutzeraktionen im bereitgestellten Karte bereit, sodass der Benutzer nicht für alle Aktionen (unabhängig von der Komplexität) außerhalb von Teams navigieren muss.


Botmetadateninformationen
  • Botinformationen im App-Manifest (Botname, Logo, Datenschutzlink und Link zu Nutzungsbedingungen) müssen mit den Bot Framework-Metadaten übereinstimmen. [Muss behoben werden]

  • Stellen Sie sicher, dass die Bot-ID im App-Manifest mit der Bot-ID in der letzten veröffentlichten Version Ihrer App im Teams Store übereinstimmt. Das Ändern von Bot-IDs in einem App-Update führt zu einem dauerhaften Verlust des gesamten Benutzerinteraktionsverlaufs mit dem Bot für vorhandene Benutzer Ihrer App und startet eine neue Konversationskette mit der neuen Bot-ID. [Muss behoben werden]

  • Jede Änderung an App-Name, Metadaten, Bot-Willkommensnachricht oder Botantworten muss mit einem neuen Namen aktualisiert werden. [Muss behoben werden]

  • Der App-Name in der Bot-Willkommensnachricht oder die Botantworten müssen mit dem App-Namen im App-Manifest übereinstimmen. [Muss behoben werden]


Bot im Bereich "Zusammenarbeit"
  • Botinstallation in einem Kanal- oder Gruppenchatbereich, um die Teamliste für das Senden proaktiver Benachrichtigungen für Benutzer abzurufen, da 1:1-Chats für teamspezifische Trigger nicht zulässig sind. Beispielsweise eine App, die Personen für ein Meetup koppelt. [Muss behoben werden]

  • Bot in einem Kanal oder Gruppenchat, der nur zum Abrufen der Nachrichten oder Beiträge zum Senden proaktiver Benachrichtigungen für Benutzer verwendet wird, da 1:1-Chats nicht zulässig sind. [Muss behoben werden]

  • Bots, die im Bereich für die Zusammenarbeit installiert werden, müssen einen Benutzerwert im Bereich für die Zusammenarbeit bereitstellen. [Muss behoben werden]

Zurück zum Anfang

Nachrichtenerweiterungen

Dieser Abschnitt entspricht der Microsoft-Richtlinie für den kommerziellen Marketplace 1140.4.4.

Wenn Ihre App eine Nachrichtenerweiterung enthält, stellen Sie sicher, dass sie diesen Richtlinien entspricht.

Tipp

Weitere Informationen zum Erstellen einer qualitativ hochwertigen App-Erfahrung finden Sie in den Entwurfsrichtlinien für Microsoft Teams Nachrichtenerweiterungen.


Entwurfsrichtlinien für Messagingerweiterungen
  • Wenn Ihre Teams-App die Messagingerweiterungsfunktion verwendet, muss Ihre App die Entwurfsrichtlinien für Messagingerweiterungen befolgen.

    Die Grafik zeigt ein Beispiel für eine App, die die Richtlinien für Erweiterungen nicht erfüllt.

  • Messagingerweiterungen sind Tastenkombinationen zum Einfügen von App-Inhalten oder zum Bearbeiten einer Nachricht, ohne von der Konversation weg zu navigieren. Halten Sie Ihre Messaging-Erweiterung einfach, und zeigen Sie nur die Komponenten an, die zum effektiven Abschließen der Aktion erforderlich sind. Die vollständige Website darf innerhalb der Messaging-Erweiterung nicht im I-Frame stehen. [Muss behoben werden]

  • Vorschaubilder in adaptiven Karten in Messagingerweiterungen müssen ordnungsgemäß geladen werden. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für das Laden von Vorschaubildern in adaptiven Karte.

    Die Grafik zeigt ein Beispiel für ein Vorschaubild, das nicht in adaptiven Karte geladen wird.

  • Die Antwort der Messagingerweiterung Karte muss das App-Symbol enthalten, um Verwirrung durch Endbenutzer zu vermeiden. [Muss behoben werden]

  • Ihre App darf keine fehlerhafte Funktionalität aufweisen. Die App darf den Benutzer nicht daran hindern, einen Workflow in einer Messagingerweiterung abzuschließen. [Muss behoben werden]

  • Messagingerweiterungen müssen in Gruppenchat- und Kanalbereichen wie vorgesehen reagieren oder funktionieren. [Muss behoben werden]

  • Sie müssen eine Möglichkeit für den Benutzer einschließen, sich bei der Messagingerweiterung anzumelden oder sich abzumelden. [Muss behoben werden]

  • Nachrichtenerweiterungen, die OpenAPI-URLs verwenden, dürfen keine Umleitung für API-Aufrufe bereitstellen. Tatsächliche API-Aufrufe müssen von derselben Domäne oder Unterdomäne der Stammdomäne bereitgestellt werden.


Aktionsbefehle für aktionsbasierte Nachrichtenerweiterungen

Aktionsbasierte Nachrichtenerweiterungen müssen folgende Aktionen ausführen:

  • Ermöglichen Sie es Benutzern, Aktionen für eine Nachricht auszulösen, ohne Zwischenschritte wie die Anmeldung auszuführen.

    validation-messaging-extension-no-intermediate-steps

    validation-messaging-extension-intermediate-steps-available

  • Übergeben des Nachrichtenkontexts an den nächsten Arbeitsstatus. [Muss behoben werden]

    validation-messaging-extension-app-passes-messages

    validation-messaging-extension-app-doesnot-pass-messages

  • Integrieren Sie den Namen der Host-App anstelle eines generischen Verbs für Aktionsbefehle, die von einer Chat-Nachricht, einem Channel-Post oder einem Aufruf zum Handeln innerhalb von Apps ausgelöst werden. Verwenden Sie beispielsweise start a Skype-Besprechung for Start Meeting, Upload file to DocuSign for Upload file. [Gut zu beheben]

    Die Grafik zeigt ein Beispiel für den Namen der Host-App für einen Aktionsbefehl.

    Die Grafik zeigt ein Beispiel für ein generisches Verb für einen Aktionsbefehl.

  • Das Aufrufen einer Nachrichtenaktion muss es dem Benutzer ermöglichen, den Workflow abzuschließen. Fehler, leere Antworten oder Indikatoren für kontinuierliches Laden, damit die Nachrichtenaktion wie beabsichtigt funktioniert, dürfen nicht vorhanden sein. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für den Indikator für kontinuierliches Laden, wenn ein Bot einen Aktionsbefehl aufruft.

  • Doppelte Aktionsbefehle dürfen nicht vorhanden sein. [Muss behoben werden]

  • Nachrichtenaktionen müssen es dem Benutzer ermöglichen, den Workflow ohne ungültige Antwort wie beabsichtigt abzuschließen. [Muss behoben werden]

  • Apps mit nur aktionsbasierter Messagingerweiterung müssen den folgenden Endzustand aufweisen:

    • Stellen Sie eine relevante Aktion als Benachrichtigung bereit, entweder in dem Kontext, in dem die Nachrichtenerweiterung aufgerufen wird, oder in einem 1:1-Botchat basierend auf einem Benutzerszenario. [Muss behoben werden]

    • Benutzern das Freigeben von Karten für andere Benutzer basierend auf der ausgeführten Aktion gestatten. Dadurch soll sichergestellt werden, dass Apps keine automatischen Aktionen ausführen. Beispielsweise wird ein Ticket basierend auf einer Nachricht in einem Kanal erstellt, aber die App sendet keine Benachrichtigung oder bietet keine Möglichkeit, den Benutzer aufzufordern, Ticketdetails nach dem Erstellen des Tickets freizugeben. [Muss behoben werden]


Vorschaulinks (Link unfurling)

[Muss behoben werden]

  • Wenn die App die supportsAnonymizedPayloads Eigenschaft im App-Manifest deklariert hat und der Benutzer die App nicht installiert hat, muss der App-Link sich lösen und das Dialogfeld app hinzufügen anzeigen, nachdem die Karte ausgewählt wurde. [Muss behoben werden]

  • Nachrichtenerweiterungen müssen eine Vorschau der erkannten Links im Feld „Verfassen“ in Microsoft Teams anzeigen. Fügen Sie keine Domänen hinzu, die sich außerhalb Ihrer Kontrolle befinden (entweder absolute URLs oder Platzhalter). Beispielsweise ist yourapp.onmicrosoft.com gültig, aber *.onmicrosoft.com nicht gültig. Top-Level Domains sind ebenfalls nicht zulässig. Zum Beispiel *.com oder *.org. [Muss behoben werden]

  • Apps dürfen nur deklarieren, die sich unter dem direkten Besitz des App-Herausgebers im messageHandler Abschnitt zum Entpacken von Links des App-Manifests befinden. [Muss behoben werden] darf nicht enthalten *.botframework.com. sein.


Suchbefehle
  • Such-basierte Nachrichtenerweiterungen müssen Text bereitstellen, der den Nutzern bei der effektiven Suche hilft. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für eine Nachrichtenerweiterung mit Hilfetext für benutzer effektive Suche.

    Die Grafik zeigt ein Beispiel für eine Nachrichtenerweiterung ohne Hilfetext, damit Benutzer effektiv suchen können.

  • @mention ausführbare Dateien müssen klar, leicht verständlich und lesbar sein.

    validation-search-commands-unclear-executable

Zurück zum Anfang

Dialoge

[Muss behoben werden]

Dieser Abschnitt entspricht der Microsoft-Richtlinie für den kommerziellen Marketplace 1140.4.5.

Erweitern, um mehr zu erfahren

Ein Dialogfeld (in TeamsJS v1.x als Aufgabenmodul bezeichnet) muss ein Symbol und den Kurznamen der App enthalten, der es zugeordnet ist. Dialoge dürfen keine gesamte App einbetten und nur die Komponenten anzeigen, die zum Ausführen einer bestimmten Aktion erforderlich sind.

Weitere Informationen finden Sie unter Entwurfsrichtlinien für Teams-Dialoge.

validation-task-module-displays-component

validation-task-module-embed-app

Tipp

Weitere Informationen zum Erstellen einer qualitativ hochwertigen App-Erfahrung finden Sie in den Entwurfsrichtlinien für Teams Aufgabenmodule.

Zurück zum Anfang

Besprechungserweiterungen

Dieser Abschnitt entspricht der Microsoft-Richtlinie für den kommerziellen Marketplace 1140.4.6.

Tipp

Weitere Informationen zum Erstellen einer qualitativ hochwertigen App-Erfahrung finden Sie in den Designrichtlinien für die Erweiterung von Teams-Meetings.


Entwurfsrichtlinien für Besprechungserweiterungen
  • Ihre Teams-Apps müssen den Entwurfsrichtlinien für Besprechungserweiterungen entsprechen.

  • Mit der App-Benutzeroberfläche in besprechungsinternen Apps können Sie Teilnehmer während der Besprechung einbinden, indem Sie die Registerkarten in der Besprechung, das Dialogfeld und das Feature für die Besprechungsfreigabe verwenden. Wenn Ihre App die Teams-Besprechungserweiterung unterstützt, müssen Sie eine reaktionsfähige Besprechungserfahrung bereitstellen, die auf die Teams-Besprechungserfahrung abgestimmt ist. [Muss behoben werden]

  • Besprechungserweiterungs-Apps müssen eine reaktionsfähige Besprechungserfahrung bieten, die an der Teams-Besprechungserfahrung ausgerichtet ist. Besprechungserfahrung ist obligatorisch für eine Teams-App, die die Erweiterbarkeit von Besprechungen unterstützt, aber Vor- und Nachbesprechungen sind nicht obligatorisch. [Muss behoben werden]

    • Mit der Pre-Meeting App-Erfahrung können Nutzer Meeting-Apps finden und hinzufügen. Benutzer können auch Aufgaben vor der Besprechung ausführen, z. B. das Entwickeln einer Umfrage, um die Besprechungsteilnehmer zu befragen. Wenn Ihre App eine Erfahrung vor der Besprechung bietet, muss sie für den Workflow der Besprechung relevant sein.

    • Mit der App-Erfahrung nach der Besprechung können Benutzer die Ergebnisse der Besprechung anzeigen, z. B. Umfrageergebnisse oder Feedback und andere App-Inhalte. Wenn Ihre App eine Erfahrung nach der Besprechung bietet, muss sie für den Workflow der Besprechung relevant sein.

    • Mit der In-Meeting-App-Erfahrung können Sie Besprechungsteilnehmer während der Besprechung einbeziehen und die Besprechungserfahrung für alle Teilnehmer verbessern. Teilnehmer dürfen nicht außerhalb der Teams-Besprechung genommen werden, um die wichtigsten Benutzerworkflows Ihrer App abzuschließen.

    Die Grafik zeigt ein Beispiel für eine Besprechungserfahrung, die Benutzer außerhalb von Teams umleitet, um die Kernfunktionen der App abzuschließen.

  • Ihre App muss einen Mehrwert bieten, der über die Bereitstellung nur benutzerdefinierter Zusammen-Modus-Szenen in Teams hinausgeht. [Muss behoben werden]

  • Sie müssen als Bereich unter und , meetingChatTabund meetingSidePanel als Kontexteigenschaft im App-Manifest deklarierengroupChat, um Ihre App für Besprechungen auf Teams meetingDetailsTabMobile zu aktivieren.configurableTabs [Muss behoben werden]

  • Besprechungszeichen dürfen einen Besprechungsteilnehmer nicht in die Sackgasse stellen. Besprechungszeichenzeichen müssen eine ordnungsgemäße Fehlermeldung für App-Einschränkungen wie z. B. regionsspezifische Abhängigkeiten anzeigen. [Muss behoben werden]

  • In der Kopfzeile der Besprechungscanvas muss der richtige App-Name angezeigt werden, um zu vermeiden, dass der Besprechungsteilnehmer verwechselt wird. [Muss behoben werden]

  • Sie müssen eine Option für den Benutzer einschließen, um sich bei der Besprechungserweiterung abzumelden oder sich abzumelden. [Muss behoben werden]

  • Besprechungsregisterkarten auf mobilen Plattformen müssen relevante Workflows enthalten. Leere Seiten dürfen auf einer Besprechungsregisterkarte nicht vorhanden sein. [Muss korrigiert werden]

  • Die Besprechungsphase ist eine fokussierte, intuitive und kollaborative Teilnahme-Canvas. Die Besprechungsphase darf nicht die gesamte Websiteumgebung einbetten. [Muss behoben werden]

  • Die App darf keinen fortlaufenden Ladebildschirm, einen Fehler oder eine fehlerhafte Funktionalität anzeigen, die den Benutzer in einem Besprechungsszenario nicht beendet oder den Abschluss eines Workflows blockiert. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für den Bildschirm für das fortlaufende Laden in einer App.

  • Die App darf beim Starten einer Besprechung keine neue Teams-instance öffnen. Besprechungszeichen sind eine Erweiterung der Teams-Funktionen, die die Zusammenarbeit in Echtzeit fördern, und neue Besprechungen müssen immer innerhalb der aktiven Teams-instance geöffnet werden. [Muss behoben werden]

  • Besprechungs-Apps müssen Workflows innerhalb der Microsoft Teams-Plattform abschließen, ohne auf chatbasierte Plattformen von Mitbewerbern umzuleiten. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für eine App, die auf eine chatbasierte Plattform eines Mitbewerbers umgeleitet wird.

  • Wenn Ihre App rollenbasierte Ansichten unterstützt und bestimmte Workflows für alle Teilnehmer nicht verfügbar sind, empfehlen wir, dass Sie in registerkarten- und seitenbereichsbasiertes Messaging für Teilnehmer implementieren, die angeben, dass die App für die Ansicht des Organisators vorgesehen ist, und Details dazu bereitstellen, wie die Teilnehmer die Besprechungsnotizen, Aktionselemente und Aktualisierungstermine erhalten. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für eine App ohne Möglichkeit für Teilnehmer in einer rollenbasierten Ansicht.


Erfahrung vor und nach der Besprechung
  • Bildschirmanzeigen vor und nach Besprechungen müssen den allgemeinen Richtlinien für den Entwurf von Registerkarten entsprechen. Weitere Informationen finden Sie unter Teams-Entwurfsrichtlinien. [Muss behoben werden]

  • Registerkarten müssen ein strukturiertes Layout aufweisen, wenn mehrere Elemente angezeigt werden. Beispielsweise finden Sie mehr als 10 Umfragen oder Erhebungen unter Beispiellayout. [Muss behoben werden]

  • Ihre App muss Benutzer benachrichtigen, wenn die Ergebnisse einer Umfrage oder Erhebung exportiert werden, indem sie angibt, dass Ergebnisse erfolgreich heruntergeladen wurden. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für Tabstopps, die den Entwurfsrichtlinien für Registerkarten nicht folgen.


Besprechungserfahrung
  • Apps dürfen nur während Besprechungen ein dunkles Design verwenden. Weitere Informationen finden Sie unter Teams-Entwurfsrichtlinien. [Muss behoben werden]

  • Eine QuickInfo muss den Namen der App anzeigen, wenn der Mauszeiger während einer Besprechung über das App-Symbol bewegt wird. [Muss behoben werden]

    validation-in-meeting-exp-display-app-names

  • Nachrichtenerweiterungen müssen während Besprechungen genauso funktionieren wie außerhalb von Besprechungen. [Muss behoben werden]


Registerkarten in Besprechungen
  • Muss reaktionsfähig sein. [Muss behoben werden]

  • Die Abstands- und Komponentengrößen müssen beibehalten werden. [Muss behoben werden]

  • Muss über eine Schaltfläche „Zurück“ verfügen, wenn mehrere Navigationsebenen vorhanden sind. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für die Schaltfläche

    Die Grafik zeigt ein Beispiel für die Schaltfläche

  • Darf nicht mehr als eine Schaltfläche zum Schließen enthalten. Es kann Benutzer verwirren, da es bereits eine integrierte Kopfzeilenschaltfläche zum Schließen der Registerkarte gibt. [Muss behoben werden]

  • Darf keinen horizontalen Bildlauf aufweisen. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für die Registerkarte

    Die Grafik zeigt ein Beispiel für die Registerkarte


Besprechungsdialoge
  • Muss sparsam und für leichte und aufgabenorientierte Szenarien eingesetzt werden. [Muss behoben werden]

  • Der Inhalt muss in einer einzigen Spalte angezeigt werden und darf nicht über mehrere Navigationsebenen verfügen. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für ein spaltenbasiertes Layout für das Dialogfeld in besprechungsinternen Besprechungen.

    Die Grafik zeigt ein Beispiel für mehrere Spaltenlayouts für besprechungsinterne Dialoge.

  • Dialoge dürfen nicht verwendet werden. [Muss behoben werden]

  • Muss mit der Mitte der Besprechungsbereich ausgerichtet sein. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für einen Besprechungsdialog, der nicht am Mittelpunkt der Besprechungsphase ausgerichtet ist.

  • Muss geschlossen werden, nachdem ein Benutzer eine Schaltfläche ausgewählt oder eine Aktion ausgeführt hat. [Muss behoben werden]

  • Zusammen-Modus: Stellen Sie sicher, dass Sie die folgenden bewährten Methoden für das Erstellen einer Szene berücksichtigen: [Muss behoben werden]

    • Alle Bilder haben das .png-Format.
    • Das endgültige Paket mit allen zusammengestellten Bildern darf eine Auflösung von 1920 x 1080 nicht überschreiten. Die Auflösung ist eine gerade Zahl. Diese Auflösung ist eine Voraussetzung dafür, dass Szenen erfolgreich angezeigt werden.
    • Die maximale Größe einer Szene beträgt 10 MB.
    • Die maximale Größe jedes Bilds beträgt 5 MB. Eine Szene ist eine Sammlung mehrerer Bilder. Der Grenzwert gilt für jedes einzelne Bild.
    • Wählen Sie nach Bedarf Transparent aus. Dieses Kontrollkästchen ist im rechten Bereich verfügbar, wenn ein Bild ausgewählt ist. Die überlappenden Bilder müssen als „transparent“ gekennzeichnet werden, um anzugeben, dass sie Bilder in der Szene überlappen.

Freigegebene Besprechungsphase

Um die shareAppContentToStage-API zu verwenden, müssen Sie die richtigen RSC-Berechtigungen deklarieren. Im App-Manifest müssen Sie die authorization -Eigenschaft konfigurieren. Aktualisieren Sie die name Eigenschaft als MeetingStage.Write.Chat und type die resourceSpecific Eigenschaft im Delegated Feld. [Muss behoben werden]

Das Feature „Gemeinsame Besprechungsphase“ kann nur über die Teams Desktop-App gestartet werden. Die Nutzung der gemeinsamen Besprechungsphase muss jedoch möglich sein und darf nicht unterbrochen werden, wenn sie auf mobilen Geräten angezeigt wird. [Muss behoben werden]

Zurück zum Anfang

Connector

  1. Der Connectorname muss mit dem App-Namen innerhalb der App und im App-Manifest identisch sein.

    Screenshot: Konflikt zwischen App-Name und App-Manifest

  2. Beim Konfigurieren des Connectors darf kein Fehler auftreten.

    Screenshot: Fehler beim Konfigurieren des Connectors durch den Benutzer

Benachrichtigungen

Dieser Abschnitt entspricht der Richtlinie 1140.4.7 für den kommerziellen Marketplace von Microsoft.

Wenn Ihre App die von Microsoft Graph bereitgestellten Aktivitätsfeed-APIs verwendet, stellen Sie sicher, dass sie den folgenden Richtlinien entspricht.

Tipp

Wenn Ihre Apps Benachrichtigungsszenarien unterstützen, bei denen die Benachrichtigungen nach langen Intervallen ausgelöst werden, z. B. nach einem Tag oder einem Monat. Bevor Sie zur Überprüfung einreichen, stellen Sie sicher, dass Sie solche Benachrichtigungen im Hintergrund auslösen, damit wir die Benachrichtigungen testen können.



Richtlinien für den Benachrichtigungsentwurf
  • Ihre Teams-Apps müssen den Entwurfsrichtlinien für Aktivitätsfeedbenachrichtigungen entsprechen.

  • Irrelevanter, falscher, nicht reagierender oder fehlerhafter Workflow darf nicht vorhanden sein, nachdem der Benutzer eine Benachrichtigung im Teams-Aktivitätsfeed ausgewählt hat. Benutzer dürfen nicht daran gehindert werden, einen Workflow abzuschließen, nachdem sie eine Aktivitätsfeedbenachrichtigung ausgewählt haben. [Muss behoben werden]

  • Fügen Sie den Namen Ihrer App in die Aktivitätsfeedbenachrichtigung für Endbenutzer ein, um die Quelle oder den Trigger für die Benachrichtigung ohne Verwirrung zu verstehen. [Muss behoben werden]

  • Die App muss Benachrichtigungen für alle Benachrichtigungsszenarien auslösen, die in der langen Beschreibung der App, der Ersten Ausführung der App und in Szenarien, die im App-Manifest unter deklariert sind activityTypes , aufgeführt sind. [Muss behoben werden]

  • Benachrichtigungen müssen innerhalb von fünf Sekunden nach der Benutzeraktion angezeigt werden. [Muss behoben werden]

  • Sie müssen Benachrichtigungseinschränkungen (falls vorhanden) in der langen Beschreibung Ihrer App oder bei der ersten Ausführung der App angeben. [Muss behoben werden]


Allgemein
  • Alle in der App-Konfiguration angegebenen Benachrichtigungs-Auslöser müssen funktionieren. [Muss behoben werden]
  • Benachrichtigungen müssen gemäß den unterstützten Sprachen lokalisiert werden, die für Ihre App konfiguriert sind. [Muss behoben werden]
  • Benachrichtigungen müssen innerhalb von fünf Sekunden nach der Benutzeraktion angezeigt werden. [Muss behoben werden]
  • Benachrichtigungen müssen gemäß den unterstützten Sprachen für alle Plattformen lokalisiert werden, auf denen Ihre App kompatibel ist. [Muss behoben werden]

Avatare
  • Der Benachrichtigungs-Avatar muss mit dem Farbsymbol Ihrer App übereinstimmen. [Muss behoben werden]
  • Von einem Benutzer ausgelöste Benachrichtigungen müssen den Avatar des Benutzers enthalten. [Muss behoben werden]

Spamming
  • Apps dürfen nicht mehr als 10 Benachrichtigungen pro Minute an einen Benutzer senden. [Muss behoben werden]
  • Bots und der Aktivitätsfeed dürfen keine doppelten Benachrichtigungen auslösen. [Muss behoben werden]
  • Benachrichtigungen müssen den Benutzern einen gewissen Wert bieten und dürfen nicht für triviale oder irrelevante Ereignisse verwendet werden. [Muss behoben werden]

Navigation und Layout
  • Benachrichtigungen müssen dem Layout und der Erfahrung des Teams-Aktivitätsfeeds entsprechen. [Muss behoben werden]
  • Bei Auswahl einer Benachrichtigung muss der Benutzer zu relevanten Inhalten innerhalb Teams weitergeleitet werden. [Muss behoben werden]

Zurück zum Anfang

Microsoft 365 Compliance-Programm

Dieser Abschnitt entspricht der Microsoft-Richtlinie für den kommerziellen Marketplace 1140.6.

Erweitern, um mehr zu erfahren

Das Microsoft 365 App Compliance-Programm soll Organisationen dabei helfen, Risiken zu bewerten und zu verwalten, indem Sicherheits- und Compliance-Informationen zu Ihrer App ausgewertet werden. Wenn Sie eine App im Teams Store veröffentlichen, müssen Sie die folgenden Ebenen des Programms abschließen:

  • Publisher Überprüfung:Hilft Administratoren und Endbenutzern, die Authentizität von App-Entwicklern zu verstehen, die sich in die Microsoft Identity Platform integrieren. Nach Abschluss des Vorgangs wird im Microsoft Entra Zustimmungsdialogfeld und auf anderen Bildschirmen ein blauer bestätigter Badge angezeigt. Weitere Informationen finden Sie unter Markieren Ihrer App als vom Herausgeber überprüft. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für einen blauen bestätigten Badge im Microsoft Entra Zustimmungsdialogfeld.

  • Publisher-Bestätigung:Ein Prozess, bei dem Sie allgemeine Informationen zur Datenverarbeitung sowie Sicherheits- und Compliance-Informationen weitergeben, um potenziellen Kunden zu helfen, fundierte Entscheidungen über die Verwendung Ihrer App zu treffen. [Gut zu beheben]

Für eine App, die zuvor nicht aufgeführt ist, können Sie den Herausgebernachweis erst abschließen, wenn die App im Teams Store verfügbar ist. Wenn Sie eine bereits aufgeführte App aktualisieren, schließen Sie den Herausgebernachweis ab, bevor Sie die neueste Version der App übermitteln.

Zurück zum Anfang

Werbung

Dieser Abschnitt steht im Einklang mit der Microsoft-Richtlinie für kommerzielle Marktplätze Nr. 1140.7.

Apps dürfen keine Werbung anzeigen, einschließlich dynamischer Werbung, Banneranzeigen und Anzeigen in Nachrichten. [Muss behoben werden]

Die Grafik zeigt ein Beispiel für ein fehlgeschlagenes Werbeszenario in Teams.

Zurück zum Anfang

Kryptowährungsbasierte Apps

Sie müssen die Einhaltung aller Gesetze, in denen Ihre App verteilt wird, nachweisen, wenn Ihre App: [Muss behoben werden]

  • Ermöglicht Transaktionen oder Übertragungen von Kryptowährungen innerhalb der App.

  • Fördert Kryptowährungsinhalte.

  • Ermöglicht Es Benutzern, ihre gespeicherte Kryptowährung zu speichern oder darauf zuzugreifen.

  • Ermutigt oder ermöglicht Es Benutzern, eine kryptowährungsbasierte Transaktion oder Übertragung außerhalb der Teams-Plattform abzuschließen.

  • Fördert oder erleichtert das Mining von Kryptowährungstoken.

  • Erleichtert die Teilnahme von Benutzern an Initial Coin Offerings.

  • Belohnungen oder Anreize für Benutzer mit Kryptowährungstoken für die Durchführung einer Aufgabe.

Wenn die Compliancedemonstration nach einer internen Microsoft-Überprüfung zufriedenstellend ist, kann Microsoft mit der weiteren Zertifizierung Ihrer App fortfahren. Wenn die Compliancedemonstration nicht zufriedenstellend ist, informiert Microsoft Sie über die Entscheidung, ihre App nicht zu zertifizieren.

Zurück zum Anfang

App-Funktionalität

  • Workflows oder Inhalte in der App müssen mit dem Bereich verknüpft sein. [Muss behoben werden]
  • Alle App-Funktionen müssen funktionsfähig sein und ordnungsgemäß funktionieren, wie in der langen Beschreibung des AppSource- oder App-Manifests beschrieben. [Muss behoben werden]
  • Apps müssen den Benutzer immer benachrichtigen, bevor eine Datei oder ausführbare Datei in der Umgebung des Benutzers heruntergeladen wird. Jeder Handlungsaufruf (Call to Action, CTA), entweder textbasiert oder anderweitig, der dem Benutzer klar macht, dass eine Datei oder ausführbare Datei bei einer Benutzeraktion heruntergeladen wird, ist in der App zulässig. [Muss behoben werden]
  • Apps mit Regionsabhängigkeit müssen die Benutzer mit einer ordnungsgemäßen Fehlermeldung in allen anwendbaren Funktionen benachrichtigen, wenn sie versuchen, sie in einer nicht unterstützten Region zu verwenden. [Muss behoben werden]

Zurück zum Anfang

Benutzerumgebung für mobile Geräte

  • Mobile Add-Ins müssen kostenlos sein. Es dürfen keine In-App-Inhalte oder Links vorhanden sein, die Upselling, Onlineshops oder andere Zahlungsanforderungen fördern. Für alle Konten, die für Apps erforderlich sind, dürfen keine Gebühren für die Nutzung anfallen, und wenn sie zeitlich begrenzt sind, dürfen keine Inhalte enthalten, die auf eine Zahlungspflicht hinweisen. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für ein mobiles Add-In, das zur Zahlung anfragt.

  • Die Verwendung der Wörter FREE, FREE TRIAL oder TRY FREE ist auf desktop- oder Web-App-Erfahrungen ohne Einschränkung oder Berücksichtigung zulässig.

  • Die Verwendung des Worts FREE als Nur-Text im Kontext eines Test- oder App-Upgrades ist auf Mobilgeräten zulässig.

  • Die Verwendung des Worts FREE im Kontext einer Testversion oder eines App-Upgrades mit einem Link, der zu einer Landing Page ohne Zahlungs- oder Preisinformationen führt, ist auf Mobilgeräten zulässig. Nur-Text, um zu signalisieren, dass die App kostenpflichtig ist, ist auf Mobilgeräten zulässig.

  • Die Verwendung des Worts FREE als Nur-Text im Kontext eines Test- oder App-Upgrades und im Zusammenhang mit Preisdetails ist auf Mobilgeräten nicht zulässig. [Muss behoben werden]

  • Die Verwendung des Worts FREE im Zusammenhang mit einem Test- oder App-Upgrade, das einem Link zugeordnet ist, der zu einer Landing Page mit Preisinformationen oder Zahlungsdetails auf Mobilgeräten führt, ist nicht zulässig. [Muss behoben werden]

  • Preisdetails für Mobilgeräte in jedem Format, z. B. Bild, Text oder Link, sind nicht zulässig. CTA wie das Anzeigen von Plänen auf Mobilgeräten ist nicht zulässig. Informationen zu Plänen ohne Preisdetails, aber mit einem Kontaktlink oder einer E-Mail-Adresse auf Mobilgeräten sind nicht zulässig. Text mit Kontaktdetails, die auf ein kostenpflichtiges Upgrade verweisen oder darauf verweisen, ist auf Mobilgeräten nicht zulässig. Zahlungen für physische Güter sind mobil erlaubt. Ihre App kann z. B. die Zahlung für die Buchung eines Taxis ermöglichen. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für Preisdetails auf Mobilgeräten.

  • Zahlungen für digitale Waren in der App sind auf Mobilgeräten nicht zulässig. [Muss behoben werden]

    Die Grafik zeigt ein Beispiel für Zahlungen für digitale Waren auf mobilgeräte.

  • Teams-Apps müssen eine geeignete geräteübergreifende mobile Erfahrung bieten. [Muss behoben werden]

  • Funktionen, die auf Mobilgeräten nicht unterstützt werden, dürfen einen Benutzer nicht in die Sackgasse führen und müssen ggf. eine ordnungsgemäße Fehlermeldung bereitstellen. [Muss behoben werden]

Zurück zum Anfang

Apps, die auf Microsoft 365-Clients erweitert wurden

Allgemein

  • Die Apps, die Teams-Apps auf Microsoft 365-Clients erweitern sollen, müssen die Schemaversion 1.13 oder höher verwenden.

  • Die Support-URL Ihrer App muss Inhalte enthalten, die für die Microsoft 365-Clients erweiterbare Teams-App relevant sind, und darf nicht nur einen einzelnen Client aufrufen.

  • Sie müssen in der App-Beschreibung einen relevanten Verweis auf die Microsoft 365-Clients erweiterbare Teams-App angeben.

  • Wenn Ihre Teams-App auf Microsoft 365-Clients erweiterbar ist, müssen die Inhalte, die in "Erste Schritte", "Anmeldung", "Registrierung", "Abmelden", "Hilfeseiten" oder "Weiterleitungsnachrichten" ihrer App bereitgestellt werden, alle Clients aufrufen.

Kompatibilität

Teams-Apps, die für Microsoft 365-Clients erweiterbar sind, müssen auf den neuesten Versionen von Microsoft Edge- und Google Chrome-Clients vollständig reaktionsfähig und funktionsfähig sein. Der Benutzer muss in der Lage sein, persönliche Registerkarten oder Nachrichtenerweiterungen auf den folgenden Seiten aufzurufen und weiterhin zu verwenden:

  • Outlook für Windows und Web.
  • Microsoft 365 auf Desktop, Web und Android.
  • Microsoft Teams auf Desktop und Web.
  • Microsoft Teams unter Android und iOS.

Benutzerumgebung für mobile Geräte

Benutzer müssen die App über das Flyoutmenü "Aktionen" im Microsoft 365-Client auf Mobilgeräten starten können. Der App-Name muss in der Aktionsleiste ordnungsgemäß angezeigt werden. [Muss behoben werden]

Flyout zum Starten von Apps über Aktionen

Benutzer müssen in der Lage sein, mehrere statische Registerkarten innerhalb des Microsoft 365-Clients auf Mobilgeräten erfolgreich zu starten und zwischen diesen zu wechseln. Die Registerkarten müssen ordnungsgemäß geladen werden. Wenn mehr als drei statische Registerkarten vorhanden sind, müssen die verbleibenden Registerkarten im Abschnitt Weitere angezeigt werden. [Muss behoben werden]

Benutzeroberfläche für mehrere Registerkarten

Wenn Ihre App SSO verwendet, muss sie den Benutzer erfolgreich authentifizieren. SSO ermöglicht Benutzern die Anmeldung mit einem Satz von Anmeldeinformationen bei mehreren unabhängigen Softwaresystemen. Benutzer können auf alle erforderlichen Anwendungen zugreifen, ohne unterschiedliche Anmeldeinformationen für die Authentifizierung zu verwenden. [Muss behoben werden]

App-Authentifizierung

Die App muss das Benutzerkonto instance beenden, wenn der Benutzer innerhalb des Microsoft 365-Clients auf dem Mobilgerät gewechselt oder abgemeldet wird. [Muss behoben werden]

Kontowechsel und -abmeldung

  • Benutzer müssen in der Lage sein, zum vorherigen Arbeitszustand zurückzukehren. Wenn sich der Benutzer auf der Stammseite befindet, muss die Rückwärtsnavigation die App instance innerhalb des Microsoft 365-Clients auf Mobilgeräten beenden. [Muss behoben werden]

  • Apps, die DeepLinks zu einem Workflow unterstützen, müssen in der Lage sein, den Benutzer zur entsprechenden Landing Page-Oberfläche umzuleiten. [Muss behoben werden]

Registerkartennavigation

  • Die Statusanzeige muss angezeigt werden, wenn die App nach dem Laden der App automatisch geladen und geschlossen wird. [Muss behoben werden]

  • Ein Fehlerbildschirm muss angezeigt werden, wenn eine App in den Instanzen nicht geladen werden kann, z. B. inkohärentes oder fehlerhaftes Netzwerk, Timeout oder Authentifizierungsfehler usw. [Muss behoben werden]

Zurück zum Anfang

Microsoft Teams-Apps sind als Plug-In für Microsoft 365 Copilot erweiterbar

Das Plug-In darf das LLM-Verhalten nicht ändern

Die kurzen Beschreibungen einer App, eines Parameters und eines Befehls dürfen folgendes nicht enthalten:

  1. Anweisungsausdrücke. Wenn der Benutzer beispielsweise X sagt, ignorieren, löschen, zurücksetzen, neue Anweisungen, antworte fett oder drucke nichts.
  2. Ausführliche, blumige oder Marketingsprache.
  3. Ansprüche der Superlative wie Nr. 1, erstaunlich oder am besten.
  4. URLs, Emojis oder ausgeblendete Zeichen wie hexadezimale, binäre oder unkonventionelle Symbole.
  5. Grammatik- und Interpunktionsfehler.

Benutzerbewusstsein

In der langen Beschreibung einer App muss deutlich Folgendes hervorgehoben werden:

  • Kompatibilität der App mit Microsoft 365 Copilot. Verwenden Sie beispielsweise Contoso in Microsoft 365 Copilot, um Ihre Aufgaben zu durchsuchen und zusammenzufassen.

  • Geben Sie mindestens eine Eingabeaufforderung an, wie Benutzer ein Nachrichtenerweiterungs-Plug-In in Microsoft 365 Copilot verwenden können. Was sind beispielsweise die Tickets mit hoher Priorität, die mir diese Woche in Contoso zugewiesen wurden.

    Screenshot eines Passszenarios mit einem Beispiel einer Beispielaufforderung für die Verwendung der Nachrichtenerweiterung als Plug-In in Microsoft 365 Copilot.

    Screenshot: Fehlerszenario ohne Beispiel einer Beispielaufforderung für die Verwendung der Nachrichtenerweiterung als Plug-In in Microsoft 365 Copilot.

Antwortqualität

  • Die Pflichtfelder in Microsoft 365 Copilot Antwort für adaptive Karten müssen den Informationstitel und mindestens zwei zusätzliche nützliche Felder Ihrer Wahl enthalten, z. B. Änderungsdatum, Autor, status und Flags. Sowohl die Vorschau als auch der Inhalt müssen Teil einer einzelnen Antwort sein.

    Screenshot: Beispiel einer Beispiel-App mit Microsoft 365 Copilot Antwort, die Vorschau und Inhalt in derselben Antwort enthält

  • Adaptive Karten in Microsoft 365 Copilot Antwort müssen mindestens eine Aktionsschaltfläche aufweisen.

  • Aktionsschaltflächen, die in Microsoft 365 Copilot Antwort-Adaptive Karten vorhanden sind, müssen funktionsfähig sein.

    Screenshot: Beispiel für Den Informationstitel, zusätzliche Benutzerfelder und Aktionsschaltfläche in einer Antwort für adaptive Karten.

  • Microsoft 365 Copilot müssen genau reagieren und keinen Fehler anzeigen, wenn ein Benutzer mit einem einzelnen Parameter auffordert.

  • Microsoft 365 Copilot müssen genau reagieren und keinen Fehler anzeigen, wenn ein Benutzer mit einem Multiparameter auffordert.

  • Microsoft 365 Copilot muss genau reagieren und keinen Fehler anzeigen, wenn ein Benutzer eine Nachverfolgung einfordert.

  • Die Nachrichtenerweiterung muss mindestens zwei Parameter für eine verbesserte Benutzererfahrung in Microsoft 365 Copilot enthalten.

Zurück zum Anfang

Nächster Schritt

Weitere Informationen