Directrices de validación de la tienda de Teams

Siguiendo estas directrices, aumenta las posibilidades de que la aplicación pase el proceso de envío de Microsoft Teams Store. Las directrices específicas de Teams complementan las directivas de certificación de marketplace comercial de Microsoft y se actualizan con frecuencia para reflejar nuevas funcionalidades, comentarios de los usuarios y cambios en las reglas de operación.

Nota:

  • Algunas directrices pueden no ser aplicables a su aplicación. Por ejemplo, si la aplicación no incluye un bot, puede omitir las directrices relacionadas con los bots.
  • Hemos cruzado estas directrices con las directivas de certificación comercial de Microsoft y hemos agregado Do’s y Don’ts con ejemplos de escenarios de superación o error encontrados en nuestro proceso de validación.
  • Algunas directrices se marcan como Corrección obligatoria. Si el envío de la aplicación no cumple estas directrices obligatorias, recibirás un informe de errores de nosotros con los pasos necesarios para remediarlos. El envío de la aplicación pasará la validación de la Tienda Teams solo después de haber corregido los problemas.
  • Otras directrices se marcan como Corrección sugerida. Para una experiencia de usuario ideal, te sugerimos que corrijas los problemas; sin embargo, no se bloqueará la publicación del envío de la aplicación en la Tienda Teams, si decides no corregir los problemas.

Propuesta de valor

Esta sección está en línea con el número de directiva de certificación comercial de Microsoft 1140.1 y proporciona más instrucciones a los desarrolladores de aplicaciones de Microsoft Teams sobre la propuesta de valor de su oferta.

Las aplicaciones deben proporcionar valor a los usuarios al permitirles completar flujos de trabajo funcionales que fomenten el uso repetido. Expanda las secciones siguientes para obtener más información sobre la propuesta de valor:

Pestañas

Las pestañas deben proporcionar valor añadido más allá de hospedar un sitio web ya existente. [corrección obligatoria]

El gráfico muestra un ejemplo de una aplicación con un flujo de trabajo valioso para canalizar miembros dentro de un equipo.

El gráfico muestra un ejemplo de una aplicación con todo el sitio web en un marco I sin ninguna opción de retroceso.


Bots de notificación Una notificación proporciona valor en Teams si:
  1. La tarjeta o el texto publicados proporcionan detalles adecuados que no requieren ninguna otra acción por parte del usuario.
  2. La tarjeta o el texto publicados proporcionan información de vista previa adecuada para que un usuario tome medidas o decida ver más detalles en un vínculo que se abre fuera de Teams.

Las aplicaciones que solo proporcionan notificaciones con contenido como , Tiene una nueva notificación o haga clic para ver y requieren que el usuario navegue fuera de Teams para todo lo demás no proporciona un valor significativo dentro de Teams.

Captura de pantalla que muestra un ejemplo de una notificación solo un poco con información inadecuada en la versión preliminar.


Extensiones de mensaje

[corrección obligatoria]

Las aplicaciones que constan de la extensión de mensaje basada en búsqueda proporcionan valor añadido al usuario mediante el uso compartido de tarjetas que permiten conversaciones contextuales sin cambiar de contexto.

Para pasar la validación de una aplicación de extensión de mensaje solo basada en búsqueda, se requieren los siguientes elementos como línea base para asegurarse de que la experiencia del usuario no se interrumpe. Una tarjeta compartida a través de una extensión de mensaje proporciona valor añadido en Teams si:

  1. La tarjeta publicada proporciona los detalles adecuados que no requieren ninguna otra acción por parte del usuario.

  2. La tarjeta publicada proporciona información de vista previa adecuada para que un usuario tome medidas o decida ver más detalles en un vínculo que se abre fuera de Teams.

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

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


Desplegamiento de vínculos

El desenlazamiento de vínculos de solo las aplicaciones no proporciona un valor añadido significativo en Teams. Considere la posibilidad de crear más flujos de trabajo en la aplicación, si la aplicación solo admite la desplegamiento de vínculos y no tiene ninguna otra funcionalidad.


Volver al principio

Nombre de la aplicación

[corrección obligatoria]

Esta sección está en línea con el número de directiva de certificación comercial de Microsoft 1140.1.1 y proporciona más instrucciones a los desarrolladores sobre cómo asignar nombres a sus aplicaciones.

Expandir para obtener más información

El nombre de una aplicación desempeña un papel fundamental en la forma en que los usuarios la detectan en la Tienda Teams. Usa las siguientes directrices para dar nombre a una aplicación:

  • El nombre debe incluir términos relevantes para los usuarios. [corrección obligatoria]

  • Nombres comunes con prefijos o sufijos con el nombre del desarrollador. Por ejemplo, Contoso Tasks en lugar de Tasks. [corrección obligatoria]

  • No debe usar Teams ni otros nombres de producto de Microsoft, como Excel, PowerPoint, Word, OneDrive, SharePoint, OneNote, Azure, Surface y Xbox, que puedan indicar falsamente la co-marca o la venta conjunta. Para obtener más información sobre cómo hacer referencia a los productos y servicios de software de Microsoft, consulta Microsoft Trademark y Brand Guidelines. [corrección obligatoria]

  • No debe copiar el nombre de una aplicación que aparece en la Tienda Teams u otra oferta del marketplace comercial. [corrección obligatoria]

  • No debe contener términos profanos o despectivos. El nombre tampoco debe incluir lenguaje racial o culturalmente insensible. [corrección obligatoria]

  • Debe ser único. Si la aplicación (Contoso) aparece en la Tienda Teams y Microsoft AppSource y quiere enumerar otra aplicación específica de una geografía como Contoso México, el envío debe cumplir los siguientes criterios:

    • Evoca la funcionalidad específica de la región de la aplicación en el título, los metadatos, la experiencia de la primera aplicación de respuesta y las secciones de ayuda. Por ejemplo, el título debe ser Contoso México. El título de la aplicación debe diferenciar claramente una aplicación ya existente del mismo desarrollador para evitar confusiones por parte del usuario final. [corrección obligatoria]
    • Al cargar el paquete de la aplicación en el Centro de partners, seleccione los mercados adecuados donde la aplicación está disponible en la sección Disponibilidad . [corrección obligatoria]
  • El nombre de la aplicación no debe dirigirse con una característica básica de Teams, como Chat, Contactos, Calendario, Llamadas, Archivos, Actividad, Teams y Ayuda. El nombre de la aplicación no se abrevia a Chat, Contactos, Calendario, Llamadas, Archivos, Actividad, Teams y Ayuda en la instalación en el panel de navegación izquierdo. [corrección obligatoria]

  • Si la aplicación forma parte de una asociación oficial con Microsoft, el nombre de la aplicación debe ser el primero. Por ejemplo, el conector de Contoso para Microsoft Teams.

  • El nombre de la aplicación no debe tener ninguna referencia a los productos de Microsoft o Microsoft. No use Teams ni Microsoft en el nombre de la aplicación a menos que la aplicación esté en asociación oficial con Microsoft. En tal instancia, el nombre de la aplicación debe aparecer primero antes que cualquier referencia a Microsoft. Por ejemplo, el conector de Contoso para Microsoft Teams. [corrección obligatoria]

  • No use paréntesis en la nomenclatura para incluir productos de Microsoft. [corrección obligatoria]

  • El nombre del desarrollador debe ser el mismo en el manifiesto de la aplicación (anteriormente denominado manifiesto de aplicación de Teams) y AppSource. [corrección obligatoria]

  • Los manifiestos de aplicación enviados deben ser manifiestos de producción. En consecuencia, el nombre de la aplicación no debe indicar que la aplicación es una aplicación de preproducción. Por ejemplo, el nombre de la aplicación no debe contener palabras como Beta, Desarrollo, Versión preliminar y UAT. [corrección obligatoria]

  • El nombre de la aplicación en el manifiesto de la aplicación y AppSource debe coincidir. [corrección obligatoria]

Sugerencia

La personalización de marca de la aplicación en la Tienda Teams y AppSource, incluidos el nombre de la aplicación, el nombre del desarrollador, el icono de la aplicación, las capturas de pantalla de AppSource, el vídeo, la descripción breve y el sitio web por separado o tomados juntos, no deben suplantar una oferta oficial de Microsoft a menos que la aplicación sea una oferta oficial de Microsoft 1P.

Aplicación duplicada

  • Las aplicaciones del mismo desarrollador que ofrecen la misma funcionalidad deben compartir una lista de aplicaciones a menos que los requisitos de cumplimiento de privacidad exijan listas de aplicaciones independientes o listas de aplicaciones independientes para admitir la nube gubernamental. Debe compilar en la lógica de negocios y publicar solo una lista. [corrección obligatoria]

    • Para cumplir con el requisito de compatibilidad con varias regiones, debe compilar en la lógica de negocios y publicar solo una lista.

    Captura de pantalla que muestra el escenario pasado de los requisitos de región realizados con lógica.

    • Para cumplir varios requisitos de punto de conexión para la implementación local y en la nube, debe compilar en la lógica de negocios y publicar solo una lista.

Apto para el consumo en el área de trabajo

[corrección obligatoria]

Esta sección está en línea con el número de directiva de certificación comercial de Microsoft 1140.1.2, 100.8 y 100.10 y proporciona instrucciones adicionales a los desarrolladores sobre la creación de aplicaciones adecuadas para el área de trabajo.

Expandir para obtener más información

El contenido de la aplicación debe ser adecuado para consumo general en áreas de trabajo y seguir todas las restricciones enumeradas en las directivas de certificación del marketplace comercial. Están prohibidos los contenidos relacionados con la religión, la directiva, el juego y el entretenimiento prolongado. [corrección obligatoria]

La aplicación debe habilitar la colaboración en grupo, optimizar la productividad de la persona, o ambas cosas. Las aplicaciones destinadas a la unión y socialización de equipos deben ser colaborativas y estar diseñadas para múltiples participantes. Las aplicaciones no deben requerir una inversión de tiempo considerable de más de 60 minutos por sesión ni afectar a la productividad. [corrección obligatoria]

Las aplicaciones de agregador de contenido deben tener un mecanismo para que los usuarios notifiquen un problema o contenido inadecuado al publicador de la aplicación. [corrección obligatoria]

Captura de pantalla que muestra el escenario pasado de la aplicación de agregador de contenido para notificar problemas.

Plataformas y servicios similares

[corrección obligatoria]

Esta sección se alinea con el número 1140.1.3 de la directiva de certificación comercial de Microsoft.

Las aplicaciones deben centrarse en la experiencia de Teams y no incluir los nombres, iconos o imágenes de otras plataformas o servicios de colaboración basados en chat similares dentro del contenido de la aplicación o en sus metadatos, a menos que la aplicación proporcione interoperabilidad específica.

Nombres de características

Los nombres de características de la aplicación en botones y otro texto de la interfaz de usuario no deben usar terminología reservada para Teams y otros productos de Microsoft. Por ejemplo, Iniciar reunión, Realizar llamada o Iniciar chat son nombres de características en uso por Microsoft en Microsoft Teams. Si es necesario, incluya el nombre de la aplicación para que la distinción sea clara, como Iniciar reunión de Contoso.

Autenticación

[corrección obligatoria]

Esta sección está en línea con el número de directiva de certificación comercial de Microsoft 1140.1.4 y proporciona instrucciones a los desarrolladores sobre la autenticación de sus aplicaciones con servicios externos.

Para obtener más información sobre cómo implementar la autenticación de aplicaciones, vea autenticación en Teams.

Expandir para obtener más información

Autenticación con servicios externos

Si la aplicación autentica a los usuarios con un servicio externo, siga estas instrucciones:

  • Iniciar sesión, cerrar sesión y registrar experiencias:

    • Las aplicaciones que dependen de cuentas o servicios externos deben proporcionar una experiencia de inicio de sesión, cierre de sesión y registro clara y sencilla. [corrección obligatoria]
    • Cuando los usuarios cierran la sesión, deben cerrar sesión solo desde la aplicación y seguir con sesión iniciada en Teams. [corrección obligatoria]
    • Las aplicaciones que dependen de cuentas o servicios externos deben ofrecer una manera de que los nuevos usuarios se registren o se ponga en contacto con el editor de la aplicación para obtener más información sobre los servicios y obtener acceso a los servicios. El avance debe estar disponible en el manifiesto de la aplicación, la descripción larga de AppSource y la experiencia de primera ejecución de la aplicación (mensaje de bienvenida del bot, configuración de pestaña o página de configuración). [corrección obligatoria]
    • Las aplicaciones que requieren que el administrador de inquilinos complete la instalación única deben llamar a la dependencia del administrador de inquilinos para configurar la aplicación (antes de que cualquier otro usuario de inquilino pueda instalar y usar la aplicación). La dependencia debe ser resaltada en el manifiesto de la aplicación, la descripción larga de AppSource, todos los puntos de contacto de la experiencia de primera ejecución (mensaje de bienvenida del bot, configuración de pestaña o página de configuración), texto de ayuda según se considere necesario como parte de la respuesta del bot, las extensiones de redacción o el contenido de la pestaña estática. [corrección obligatoria]
  • Experiencias de uso compartido de contenidos: las aplicaciones que requieren autenticación con un servicio externo para compartir contenido en canales de Teams deben indicar claramente en la documentación de ayuda (o en recursos similares) cómo desconectar o dejar de compartir contenidos si esa característica se admite en el servicio externo. Esto no significa que la capacidad de no compartir contenido deba estar presente en la aplicación de Teams.

Audio

  • Si la intención principal de la aplicación es escuchar música, debe admitir al menos un ámbito de colaboración con un flujo de trabajo de un extremo a otro específico para la aplicación. Por ejemplo, el uso compartido de la lista de reproducción, la configuración o el anclaje de la lista de reproducción y la escucha sincrónica de música. [corrección obligatoria]

  • Se recomienda que las aplicaciones publicadas con la intención principal de permitir a los usuarios escuchar música en Teams incluyan experiencia de escucha conjunta colaborativa. [Corrección sugerida]

Seguridad

Esta sección se alinea con el número 1140.3 de la directiva de certificación comercial de Microsoft.

Volver al principio

Información financiera

[corrección obligatoria]

Esta sección está en línea con el número de directiva de certificación comercial de Microsoft 1140.3.1 y proporciona instrucciones sobre la transmisión de información financiera dentro de la interfaz de Teams y notifica a los desarrolladores los escenarios de pago restringidos en la versión móvil (Android e iOS) de su aplicación de Teams.

Expandir para obtener más información

Las aplicaciones no deben pedir a los usuarios que realicen pagos dentro de la interfaz de Teams y transmitan información financiera a los usuarios a través de una interfaz de bot. [corrección obligatoria]

validation-financial-info

Puede proporcionar un vínculo para proteger los servicios de pago externos solo si lo da a conocer en sus términos de uso, directiva de privacidad, página de perfil o sitio web antes de que el usuario acepte usar la aplicación. [corrección obligatoria]

No deberá facilitar los pagos a través de una aplicación para bienes o servicios prohibidos por Directiva general número 100.10 Contenidos inapropiados. [corrección obligatoria]

Las aplicaciones que se ejecutan en la versión de iOS o Android de Teams deben cumplir las siguientes directrices:

  • Las aplicaciones no deben incluir compras desde la aplicación, ofertas de prueba o interfaz de usuario que tengan como objetivo vender a los usuarios a versiones de pago o tiendas en línea para comprar otro contenido, aplicaciones o complementos. [Corrección obligatoria]

    validation-financial-info-in-app-purchase

    validation-online-store

  • Si la aplicación requiere una cuenta, los usuarios pueden registrarse para obtener una cuenta sin cargo alguno. Se prohíbe el uso del término gratuito o cuenta gratuita. [corrección obligatoria]

  • Puede determinar si una cuenta estará activa indefinidamente o durante un tiempo limitado. Cuando la cuenta expira, la aplicación no debe mostrar la interfaz de usuario, el texto o los vínculos que indiquen la necesidad de pagar. [corrección obligatoria]

  • La directiva de privacidad y las condiciones de uso de la aplicación deben estar libres de cualquier interfaz de usuario o vínculo relacionado con comercio. [corrección obligatoria]

Bots

[corrección obligatoria]

Esta sección se alinea con el número de directiva de Marketplace comercial de Microsoft 1140.3.2.

Expandir para obtener más información

En el caso de las aplicaciones que utilizan el Azure Bot Service de Microsoft (como los bots y las extensiones de mensaje), debe seguir todos los requisitos definidos en los términos de Microsoft Online Services.

Los bots siempre deben pedir permiso para cargar un archivo y mostrar un mensaje de confirmación.

validation-bot-confirmation

Dominios externos

[corrección obligatoria]

Esta sección está en línea con el número de directiva de Marketplace comercial de Microsoft 1140.3.3 y proporciona instrucciones para desarrolladores sobre el uso de dominios restringidos en la propiedad de manifiesto de aplicación validDomains .

Expandir para obtener más información

No incluya dominios fuera del control de la organización (incluidos los caracteres comodín) y servicios de tunelización en las configuraciones de dominio de la aplicación. Las excepciones son las siguientes:

  • Si su aplicación depende de SharePoint, puede incluir el sitio raíz de SharePoint asociado como un dominio válido utilizando la {teamSiteDomain} propiedad de contexto. [corrección obligatoria]

  • No use dominios de nivel superior como .com, .in y .org como dominio válido. [corrección obligatoria]

  • No use .onmicrosoft.com ni como un dominio válido donde onmicrosoft no esté bajo su control. Sin embargo, puede usar yoursite.com como un dominio válido donde el sitio esté bajo su control aunque el dominio incluya un carácter comodín. [corrección obligatoria]

  • Si la aplicación es una powerapp basada en Microsoft Power Platform, debe incluir apps.powerapps.com como un dominio válido para permitir que la aplicación sea accesible y funcional dentro de Teams.

  • Los dominios externos declarados para el envío no deben contener direcciones URL. Por ejemplo, www o https. [corrección obligatoria]

  • Si la aplicación usa la OAuthCard de Azure Bot Service, debe incluir token.botframework.com como dominio válido o, de lo contrario, el botón Iniciar sesión no funcionará. No debe declarar .botframework.com como no se permiten caracteres comodín con este nombre de dominio. [corrección obligatoria]

  • Las direcciones URL de OpenAPI deben estar bajo control de asociado.

  • No se permiten los siguientes dominios externos: [Corrección obligatoria]

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

Cuando se usan caracteres comodín (*), se aplican las reglas siguientes:

  • Si un segmento de subdominio incluye un carácter comodín, debe ser el único carácter del segmento.
  • Cualquier segmento anterior a un segmento con caracteres comodín también debe ser un segmento comodín.

Por ejemplo, *.*.domain.com es válido, pero foo.*.myteam.domain.com no es válido.

Contenido confidencial

[corrección obligatoria]

La aplicación no debe publicar datos confidenciales, como tarjetas de crédito, detalles de pago financiero, estado, seguimiento de contactos u otra información de identificación personal (PII) a un público no diseñado para ver el contenido.

La aplicación debe advertir a los usuarios antes de descargar cualquier archivo o archivo ejecutable (.exe) en el equipo o entorno del usuario.

Funcionalidad y rendimiento general

Esta sección está en línea con el número de directiva de Marketplace comercial de Microsoft 1140.4.

  • La guía de avance es obligatoria tanto para el administrador como para los usuarios existentes. Puede agregar instrucciones paso a paso como hipervínculos para registrarse, empezar, ponerse en contacto con nosotros, vínculos de ayuda o correo electrónico.
  • No es necesario llamar a las limitaciones o dependencias de la cuenta en la funcionalidad de la aplicación, pero es obligatorio agregarla tanto en la descripción larga del manifiesto de la aplicación como en la lista de aplicaciones de AppSource.
  • Debe llamar a cualquier dependencia de los administradores de inquilinos para los nuevos usuarios. Si no hay ninguna dependencia, es obligatorio proporcionar un registro, ponerse en contacto con nosotros, un vínculo de introducción o un correo electrónico.

Volver al principio

Lanzamiento de funcionalidades externas

[corrección obligatoria]

Las aplicaciones no deben sacar a los usuarios de Teams para escenarios de usuario principales. El contenido de la aplicación y las interacciones deben producirse dentro de las funcionalidades de Teams, como bots, tarjetas adaptables, pestañas y diálogos (denominados módulos de tareas en TeamsJS v1.x).

Nota:

Para redirigir a los usuarios desde la aplicación de Teams a su experiencia nativa a través de un vínculo profundo con un protocolo como , o , inicie el vínculo profundo en una nueva ventana llamando al window.open método o usando una etiqueta delimitadora con target="_blank".webex:mailto:tel:

Expandir para obtener más información
  • Vincule a los usuarios dentro de la aplicación de Teams y no a un sitio o aplicación externos. En escenarios que requieran funcionalidad externa, la aplicación debe tener permiso de usuario explícito para iniciar la funcionalidad. [corrección obligatoria]

  • El texto de la interfaz de usuario del botón que inicia la funcionalidad externa debe incluir contenido para indicar que el usuario se ha extraído de la instancia de Teams. Por ejemplo, incluya texto como puede serThis way to Contoso.com o View en Contoso.com. [corrección obligatoria]

  • Agregue el icono emergente para que los usuarios sepan que se están navegando fuera de Teams. Puede usar el icono emergente situado a la derecha del vínculo. [corrección obligatoria]

  • Si no puede agregar un icono emergente , puede implementar cualquiera de las siguientes opciones para que el usuario sepa que se está navegando fuera de Teams: [Corrección obligatoria]

    • Agregue una nota en Tarjeta adaptable que indica que, cuando los usuarios seleccionan Obtener ayuda con esta aplicación, lleva al usuario fuera de Teams.
    • Agregar diálogos intersticiales.

Compatibilidad

[corrección obligatoria]

Las aplicaciones deben ser totalmente funcionales en las versiones más recientes de los siguientes sistemas operativos y exploradores:

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

La aplicación debe mostrar un mensaje de error correcto en exploradores y sistemas operativos no compatibles.

Tiempo respuesta

[corrección obligatoria]

Las aplicaciones de Teams deben responder dentro de un plazo de tiempo razonable o mostrar un indicador de carga o escritura, un mensaje o una advertencia.

  • Las pestañas deben responder en dos segundos o mostrar un mensaje de carga o una advertencia. [corrección obligatoria]
  • Los bots deben responder a las órdenes del usuario en dos segundos o mostrar un indicador de escritura. [corrección obligatoria]
  • Las extensiones de mensaje deben responder a los comandos de usuario en dos segundos. [corrección obligatoria]
  • Las notificaciones deben mostrarse en los dos segundos siguientes a la acción del usuario. [corrección obligatoria]

Aplicaciones con tecnología de inteligencia artificial

Explore los recursos diseñados para ayudarle con prácticas responsables de inteligencia artificial (IA) en cada fase de innovación, como Microsoft RAI Toolkit y HAX Toolkit Project.

Esta sección está en consonancia con la directiva de Marketplace comercial de Microsoft para aplicaciones con contenido generado por IA y directiva de Marketplace comercial de Microsoft para aplicaciones que usan funcionalidades de reconocimiento facial.

Aplicaciones con contenido generado por IA

  • La aplicación no debe generar, contener ni proporcionar acceso a contenido inadecuado, dañino o ofensivo generado por IA coherente con las directivas existentes de Marketplace comercial descritas en la versión 100.10. [corrección obligatoria]

    • Considere la posibilidad de usar cualquiera de las siguientes opciones:
      • Use la biblioteca de inteligencia artificial de Teams, la interfaz centrada en Teams para los modelos de lenguaje común basados en GPT y los motores de intención de usuario. [Corrección sugerida]
      • Uso de enlaces de moderación, que se pueden usar para regular las respuestas del bot a través de la API de moderación. [Corrección sugerida]
      • Agregue la funcionalidad de barrido de conversaciones, que le ayuda a supervisar las conversaciones e intervenir cuando las conversaciones se desatraen. [Corrección sugerida]
  • La aplicación debe proporcionar mecanismos para que los usuarios de la aplicación notifiquen contenido inadecuado, dañino o ofensivo al desarrollador mediante cualquiera de los siguientes mecanismos: [Corrección obligatoria]

    • Descripción de la aplicación, incluido el identificador de correo o el vínculo al portal para registrar el problema.
    • En el mecanismo de la aplicación para registrar el problema junto con una referencia específica al contenido inadecuado.
  • Debe tomar medidas oportunas sobre los problemas notificados. [corrección obligatoria]

  • La aplicación debe describir claramente la funcionalidad de IA antes de que el cliente adquiera la oferta coherente con la directiva 100.1.3 y pedir al usuario que revise la información como parte de la funcionalidad desde la aplicación. [Corrección obligatoria].

    Captura de pantalla que muestra la descripción de la funcionalidad de Ai.

Aplicaciones que usan funcionalidades de reconocimiento facial

Nota:

Las aplicaciones de esta categoría pueden someterse a una revisión adicional para que se adhieran a los principios de inteligencia artificial responsable de Microsoft.

  • La aplicación no debe permitir el uso de capacidades de reconocimiento facial para identificar a un individuo que va a ser utilizado por o para un departamento de policía en el Estados Unidos. [corrección obligatoria]
  • Para las aplicaciones que usan tecnologías de reconocimiento facial o inferencia emocional, debe proporcionar una etiqueta o indicación destacada de cada una de estas funcionalidades en la descripción de la aplicación. [corrección obligatoria]
    • Las aplicaciones que usan expresiones faciales o movimientos faciales para inferir estados emocionales, como enojo, asco, felicidad, tristeza, sorpresa, miedo u otros términos que se suelen usar para describir el estado emocional de una persona pueden restringirse en función de la revisión.
    • Se permite el uso de expresiones faciales y movimientos para detectar y clasificar solo elementos faciales individuales, como sonrisas o cejas levantadas. La distinción clave es entre la detección de expresiones faciales o movimientos como señales visuales frente a la inferencia de un estado emocional.

Paquete de aplicación y descripción de la Tienda Teams

[corrección obligatoria]

Los paquetes de aplicaciones deben tener un formato correcto e incluir toda la información y los componentes requeridos.

Sugerencia

  • Debe asegurarse de que las cuentas de prueba proporcionadas o el entorno de prueba sean válidos a perpetuidad, es decir, hasta que la aplicación esté activa en marketplace comercial.

  • Debes incluir las siguientes instrucciones de prueba detalladas para validar el envío de la aplicación:

    • Pasos para configurar las cuentas de prueba de la aplicación en caso de que la aplicación dependa de cuentas externas para la autenticación.
    • Resumen de comportamiento esperado de la aplicación para los flujos de trabajo principales en Teams.
    • Describa claramente las limitaciones, condiciones o excepciones a la funcionalidad, las características y los resultados en la descripción larga de la aplicación y los materiales relacionados.
    • Énfasis en las consideraciones para los evaluadores al validar el envío de la aplicación.
    • Rellena previamente las cuentas de prueba con datos ficticios para facilitar las pruebas.
    • Si va a proporcionar las cuentas de prueba, asegúrese de habilitar la integración de terceros. Además, deshabilite la autenticación en dos fases o multifactor.

Volver al principio

Manifiesto de la aplicación

[corrección obligatoria]

El manifiesto de aplicación define la configuración de la aplicación.

  • El manifiesto de la aplicación debe ajustarse a un esquema de manifiesto de aplicación publicado públicamente. Para obtener más información, consulte Referencia del manifiesto de la aplicación. No envíes la aplicación con una versión preliminar del manifiesto de la aplicación.
  • Si la aplicación incluye un bot o una extensión de mensaje, los detalles del manifiesto de la aplicación deben ser coherentes con los metadatos de Bot Framework, incluidos el nombre del bot, el logotipo, el vínculo a la directiva de privacidad y el vínculo a las condiciones de servicio.
  • Si la aplicación usa Microsoft Entra ID para la autenticación, incluya el identificador de Microsoft Entra aplicación (cliente) en el manifiesto de la aplicación. Para obtener más información, consulte la referencia del manifiesto de la aplicación.

Usos del esquema de manifiesto de aplicación más reciente

  • Si la aplicación usa el inicio de sesión único (SSO), debe declarar Microsoft Entra ID en el manifiesto de la aplicación para la autenticación de usuario. [corrección obligatoria]

  • Debe usar un esquema de manifiesto de aplicación publicado públicamente. Puede actualizar el paquete de la aplicación para usar una versión pública del esquema de manifiesto de aplicación 1.10 o posterior. [corrección obligatoria]

  • Al enviar una actualización de la aplicación, solo aumenta el número de versión de la aplicación. El identificador de aplicación de la aplicación actualizada debe coincidir con el identificador de aplicación de la aplicación publicada. [corrección obligatoria]

  • La presencia de archivos adicionales en el paquete de la aplicación no es aceptable. [corrección obligatoria]

  • El número de versión debe ser el mismo en el esquema del archivo de manifiesto de la aplicación y en los idiomas adicionales del esquema de manifiesto de la aplicación. [corrección obligatoria]

  • Debe usar la versión 1.5 o posterior del esquema de manifiesto de aplicación para localizar la aplicación. Para usar la versión 1.5 o posterior del esquema de la aplicación en el archivo manifest.json, actualice el $schema atributo a 1.5 o posterior. Actualice la propiedad a $schema la manifestVersion versión (1.5 en este caso). [corrección obligatoria]

  • Al agregar, actualizar o quitar una funcionalidad existente, agregar o quitar el manifiesto de aplicación o los metadatos del Centro de partners, debe aumentar el número de versión de la aplicación y enviar el nuevo manifiesto de aplicación en la cuenta del Centro de partners para su validación. [corrección obligatoria]

  • La cadena de versión debe seguir el estándar de especificación de control de versiones semántico (SemVer) (MAJOR. MENOR. PATCH). [corrección obligatoria]

  • Si la aplicación requiere que los administradores revisen los permisos y concedan consentimiento en el Centro de administración de Teams, debe declarar webapplicationinfo en el manifiesto de la aplicación. Si webapplicationinfo no se declara en el manifiesto de la aplicación, la página Permisos de la aplicación en el Centro de administración de Teams se muestra como ... [Corrección obligatoria]

  • Como parte de la certificación de aplicaciones de Teams, debe enviar una versión de producción del manifiesto de la aplicación. [corrección obligatoria]

  • Se recomienda declarar el identificador de Microsoft Partner Network (MPN) en el manifiesto de la aplicación. El id. de MPN ayuda a identificar la organización asociada que compila la aplicación. [Corrección sugerida]

  • Los ámbitos o el contexto declarados en el manifiesto de la aplicación deben estar visibles dentro de la aplicación. [corrección obligatoria]

Iconos de la aplicación

[corrección obligatoria]

Los iconos son uno de los elementos principales que los usuarios ven al examinar la Tienda Teams.

Expandir para obtener más información

Los iconos deben comunicar la marca y el propósito de la aplicación a la vez que cumplen los siguientes requisitos:

  • El color y el icono de esquema de la aplicación enviados en la lista de aplicaciones deben coincidir. [corrección obligatoria]

    Captura de pantalla que muestra que el icono de color y el icono de esquema son iguales.

    Captura de pantalla que muestra que el icono de color y el icono de esquema no son iguales.

  • El paquete de la aplicación debe incluir dos versiones .png del icono de la aplicación: un icono de color y un icono de contorno. [corrección obligatoria]

  • El icono de Marketplace cargado como parte de la lista de Marketplace de la aplicación en la cuenta del Centro de partners debe coincidir con el icono de color proporcionado en el paquete de la aplicación. [corrección obligatoria]

  • La versión de color del icono debe ser de 192 x 192 píxeles. El símbolo de icono puede ser cualquier color o colores, pero debe situarse sobre un fondo cuadrado sólido o totalmente transparente. [corrección obligatoria]

  • La versión de esquema del icono se muestra en los escenarios siguientes:

    • Cuando la aplicación está en uso y hospedada en la barra de aplicaciones del lado izquierdo de Teams.
    • Cuando un usuario ancla la extensión de mensaje de la aplicación.
  • El contorno debe ser de 32 x 32 píxeles y puede ser blanco con un fondo transparente o transparente con un fondo blanco. El icono no debe tener ningún relleno adicional alrededor del símbolo. [corrección obligatoria]

  • El paquete de la aplicación debe incluir iconos con el formato y el tamaño correctos. Los iconos deben coincidir con la información de los metadatos de la descripción de la Tienda Teams. [corrección obligatoria]

Para obtener más información, vea directrices sobre iconos.

Descripciones de aplicaciones

Debe tener una descripción corta y larga para la aplicación. La descripción de la aplicación ayuda a mejorar la detectabilidad de la aplicación en la Tienda Teams. Las descripciones de la configuración de la aplicación y del Centro de partners deben ser las mismas.

El gráfico muestra un ejemplo de descripción adecuada de la aplicación en la aplicación teams.

El gráfico muestra un escenario con errores para una descripción inadecuada de la aplicación.



Expandir para obtener más información

Las descripciones no deben establecerse directamente ni a través de sugerencias para desaprotección de otra marca (propiedad de Microsoft o de otro modo). Asegúrese de que la descripción no incluya notificaciones que no se puedan justificar. Por ejemplo, aumento garantizado del 200% en la eficiencia.

  • La descripción de la aplicación no debe contener información comparativa de marketing. Por ejemplo, no use logotipos o marcas comerciales de la competencia en la lista de ofertas, incluidas etiquetas u otros metadatos que hagan referencia a ofertas o marketplaces competidores. [corrección obligatoria]

    El gráfico muestra un ejemplo de información comparativa de marketing en la descripción de la aplicación.

  • Detalles de contacto de hipervínculo, introducción, ayuda o registro en la descripción de la aplicación. [Corrección sugerida]

    El gráfico muestra un ejemplo de detalles de contacto con hipervínculos en las descripciones de la aplicación.

    El gráfico muestra un ejemplo de detalles de contacto que no están hipervínculos en las descripciones de la aplicación.

  • La descripción de la aplicación debe identificar al público deseado, explicar breve y claramente su valor único y distinto, identificar los productos de Microsoft admitidos y otro software e incluir los requisitos previos o requisitos para su uso. Debe describir claramente las limitaciones, condiciones o excepciones a la funcionalidad, características y entregas, como se describe en la lista y los materiales relacionados antes de que el cliente adquiera su oferta. Las funcionalidades que declare deben estar relacionadas con las funciones principales y la descripción de la oferta. [corrección obligatoria]

  • Si actualiza el nombre de la aplicación, reemplace el nombre de la aplicación anterior por el nuevo nombre de la aplicación en los metadatos de la oferta en el manifiesto de la aplicación, AppSource y siempre que corresponda. [corrección obligatoria]

  • Las limitaciones y las dependencias de la cuenta se deben señalar en el manifiesto Descripción de la aplicación, AppSource y Centro de partners. Por ejemplo:

    • Cuenta de empresa
    • Suscripción de pago
    • Otra licencia o cuenta
    • Idioma
    • Marcado de red telefónica conmutada (RTC)
    • Dependencia regional
    • Plazo para reservar traductores o agentes en directo
    • Funcionalidad basada en roles
    • Dependencia de la aplicación nativa

    El gráfico muestra un ejemplo de limitaciones que se indican en la descripción de la aplicación.

    El gráfico muestra un ejemplo de limitaciones no indicadas en las descripciones de la aplicación.

  • Si la aplicación es compatible con regiones o ubicaciones geográficas específicas, debes llamar a esa dependencia de región específica en la descripción de la aplicación en el manifiesto de la aplicación, el Centro de partners y AppSource para esa oferta.

  • Si necesita hacer referencia a Teams, escriba la primera referencia en la lista de aplicaciones como Microsoft Teams. Las referencias posteriores se pueden acortar a Teams. [corrección obligatoria]

    El gráfico muestra un ejemplo de referencia correcta a Teams en la descripción de la aplicación.

    El gráfico muestra un ejemplo de referencia incorrecta a Teams en la descripción de la aplicación.

Descripción breve

Una breve descripción debe ser un resumen conciso de la aplicación que resalte su propuesta de valor y se dirija a la audiencia de destino.

Dos:

  • Limite la descripción a una sola frase.
  • Ponga la información más importante en primer lugar.
  • Incluya palabras clave que los clientes probablemente busquen.
  • Haga un uso eficaz del límite de caracteres disponible. Por ejemplo, no repita el nombre de la aplicación.

No:

[Corrección sugerida]

Use la palabra aplicación en la descripción breve.

Descripción larga

La descripción larga debe proporcionar una narrativa atractiva que resalte la propuesta de valor de la aplicación, la audiencia principal y el sector de destino. Aunque la descripción puede tener hasta 4000 caracteres, se recomienda tener una descripción concisa de alrededor de 1000 caracteres.

Dos:

  • Use Markdown para dar formato a la descripción.

  • Use la voz activa y hable directamente a los usuarios. Por ejemplo, Puede ....

  • Enumere las principales ventajas para resaltar las ventajas de usar la aplicación. Agregue hasta tres ventajas.

  • Agregue la propuesta de valor clave de la aplicación en Teams.

  • Enumere las características con viñetas para que sea más fácil escanear la descripción.

  • Describa claramente las limitaciones, características, condiciones o excepciones a la funcionalidad y los resultados en la lista y los materiales relacionados antes de que el usuario instale la aplicación. Las funcionalidades de Teams deben estar relacionadas con las funciones principales que se describen en la lista.

  • Asegúrese de que la descripción de la aplicación coincida con la funcionalidad disponible dentro de la aplicación de Teams. Cualquier referencia a flujos de trabajo fuera de la aplicación de Teams debe ser limitada y se debe denominar de forma distinta desde la funcionalidad de la aplicación de Teams.

  • Incluya un vínculo de ayuda o soporte.

  • Consulte Microsoft 365 en lugar de Office 365.

  • Use el siguiente lenguaje cuando describa cómo funciona la aplicación con Teams (o Microsoft 365):

    • ... funciona con Microsoft Teams.
    • ... trabajar con Microsoft Teams.
    • ... en Microsoft Teams.
    • ... para Microsoft Teams.
    • ... integrado con Microsoft Teams.
    • ... creado para...
    • ... desarrollado para...
    • .. diseñado para...

Don'ts:

[corrección obligatoria]

  • Superar las 500 palabras.

  • Abreviar Microsoft como MS o MSFT.

    El gráfico muestra un ejemplo de abreviatura de Microsoft como MS o MSFT por primera vez en la descripción de la aplicación.

    El gráfico muestra un ejemplo de no abreviar Microsoft como MS o MSFT por primera vez en la descripción de la aplicación.

  • Indicar que la aplicación es una oferta de Microsoft, incluyendo el uso de eslóganes o etiquetas de Microsoft.

    El gráfico muestra un ejemplo de cómo no indicar la oferta de Microsoft en la descripción de la aplicación.

    Gráfico que muestra un ejemplo de cómo escribir la descripción de la aplicación sin usar eslóganes y etiquetas de Microsoft.

  • Usar el siguiente idioma a menos que sea un asociado certificado de Microsoft:

    • ... certificado para...
    • ... con tecnología de ...
  • Incluir errores tipográficos y gramaticales.

  • Ponga en mayúscula innecesariamente todo el manifiesto de la aplicación o la descripción larga de AppSource o el contenido de la aplicación.

    El gráfico muestra un ejemplo de descripción larga de la aplicación sin errores.

    El gráfico muestra un ejemplo de descripción larga de la aplicación con errores tipográficos y .

  • Incluir vínculos a AppSource.

    El gráfico muestra un ejemplo de un escenario de error con vínculos a AppSource en la descripción larga de la aplicación.

  • Realizar notificaciones no comprobadas. Por ejemplo, mejor, superior y clasificado, a menos que venga con el origen de la notificación.

  • Comparar la oferta con otras ofertas del marketplace.

Para obtener instrucciones sobre cómo crear una descripción precisa, concisa e informativa corta y larga, consulte lista de comprobación para escribir descripciones de la aplicación.

Capturas de pantalla

Las capturas de pantalla proporcionan una destacada vista previa de su aplicación para complementar el nombre, el icono y las descripciones de la misma.



Expandir para obtener más información

Recuerde lo siguiente:

  • Puede tener hasta cinco capturas de pantalla por anuncio.
  • Los tipos de archivo admitidos son PNG, JPEG y GIF.
  • Las dimensiones deben ser de 1366 x 768 píxeles.
  • Tamaño máximo de 1 024 KB.

Dos:

  • Céntrese en las funcionalidades de la aplicación. Por ejemplo, cómo las personas pueden comunicarse con el bot.

  • Incluya contenidos que representen con precisión su aplicación.

  • Use el texto con juicio.

  • Capturas de pantalla enmarcadas con un color que refleja su marca e incluye contenido de marketing.

  • Use capturas de pantalla de alta resolución que sean nítidas y contengan texto legible y legible. [corrección obligatoria]

  • Al menos una captura de pantalla debe representar la funcionalidad de la aplicación en dispositivos móviles. [corrección obligatoria]

    Captura de pantalla que muestra el escenario pasado de la funcionalidad de la aplicación en dispositivos móviles.

  • Puede tener hasta cinco capturas de pantalla por anuncio. Debe tener un mínimo de tres y un máximo de cinco capturas de pantalla en la descripción de la aplicación. [corrección obligatoria]

  • Use simulacros que represente con precisión la interfaz de usuario real de la aplicación en beneficio de los usuarios finales. Las capturas de pantalla deben representar con precisión la interfaz de usuario real de la aplicación o los escenarios pertinentes y relacionados con la aplicación. [corrección obligatoria]

    Captura de pantalla que muestra el escenario con errores del contenido de suplemento usado en la captura de pantalla.

    Captura de pantalla que muestra el escenario con errores de la captura de pantalla de la interfaz de usuario real de la aplicación.

  • Debe representar la funcionalidad de la aplicación o la integración con Teams. [corrección obligatoria]

    Captura de pantalla que muestra el escenario con errores de funcionalidad o integración de la aplicación.

  • Las capturas de pantalla proporcionadas no deben hacer referencia incorrectamente a Microsoft Teams como MS, MSFT o MS Teams. [corrección obligatoria]

  • Si la aplicación de Teams es extensible entre clientes de Microsoft 365 (Microsoft 365, Outlook y Microsoft Teams), las capturas de pantalla proporcionadas deben representar la funcionalidad de la aplicación en otros clientes de Microsoft 365. [corrección obligatoria]

    Captura de pantalla que muestra el escenario pasado de la funcionalidad de aplicaciones de Teams en clientes de MS 365.

  • Debe proporcionar subtítulos en las capturas de pantalla para que el usuario comprenda claramente la funcionalidad de la aplicación. [corrección obligatoria]

    Captura de pantalla que muestra el escenario pasado de atención del usuario para la funcionalidad de la aplicación.

  • Si la aplicación admite pestañas como funcionalidad, las capturas de pantalla que muestran la aplicación en el contexto de una pestaña de Teams, en la lista de aplicaciones, deben contener el cromo del equipo. [corrección obligatoria]

    Captura de pantalla que muestra el escenario pasado de la captura de pantalla de la funcionalidad de tabulación.

Don'ts:

  • Incluya simulacros que reflejen inexactamente la interfaz de usuario real de la aplicación, como mostrar que la aplicación se usa fuera de Teams.

    Captura de pantalla que muestra el escenario de error de la funcionalidad de la aplicación no relacionada en Teams.

Vídeos

Un vídeo de la descripción de la aplicación es una de las maneras más eficaces de comunicar por qué los usuarios deben usar la aplicación. Puedes agregar tu dirección URL de vídeo de YouTube o Vimeo que proporcione el valor de tu aplicación. Además, como procedimiento recomendado, se recomienda agregar un vídeo que proporcione el tutorial de demostración o escenario de la aplicación. [Corrección sugerida]

Si decide enviar un vídeo como parte de la descripción de la aplicación en su cuenta del Centro de partners, asegúrese de cumplir los siguientes criterios:

  • El vídeo debe ser corto, claro, atractivo y de buena calidad.

  • El vídeo debe mostrar cómo configurar y usar la aplicación.

  • El vídeo debe tener un formato narrativo.

  • La duración del vídeo debe ser de entre 60 y 90 segundos para un vídeo de valor y la duración recomendada para un vídeo de tutorial es de 3 a 5 minutos. [Corrección sugerida]

  • Debes desactivar los anuncios de la configuración de tu cuenta de YouTube o Vimeo antes de enviar el vínculo de vídeo en la lista de aplicaciones. [corrección obligatoria]

  • El vídeo debe resaltar las funcionalidades y la integración de la aplicación en Teams. [corrección obligatoria]

  • El vídeo debe estar disponible como un vínculo funcional. [corrección obligatoria]

  • El vídeo debe tener el formato https://www.example.com/123456789.

    Captura de pantalla que muestra el escenario con errores del vídeo enviado como parte de la lista de aplicaciones en el Centro de partners.

  • El vídeo se puede mostrar en la primera posición de las capturas de pantalla o el carrusel de vídeos en los detalles de la aplicación (Tienda Teams y centro de Administración) y las páginas de AppSource. [Corrección sugerida]

  • El vídeo del tutorial de demostración o escenario debe tener la intención de educar a los usuarios y no promover la aplicación.

Para obtener más información sobre los criterios para crear un vídeo de valor de aplicación o un vídeo de tutorial, consulte la lista de comprobación para crear un vídeo.



Directiva de privacidad

[corrección obligatoria]

La directiva de privacidad puede ser específica de la aplicación de Teams o una directiva general para todos los servicios.

  • Si usa una plantilla de directiva de privacidad genérica, debe agregar una referencia a servicios, aplicacioneso plataformas en el ámbito de la directiva de privacidad. No es necesario especificar la aplicación de Teams en el ámbito, si incluye una referencia a servicios, aplicaciones y plataformas. El proceso de validación de aplicaciones interpreta estas referencias para incluir la aplicación de Teams junto con otros servicios o sitios web.
  • Debe incluir cómo maneja el almacenamiento, la retención y la eliminación de los datos de los usuarios. Debe describir los controles de seguridad para protección de datos.
  • Debe incluir su información de contacto.
  • No debe incluir direcciones URL que estén rotas o sean con fines beta o de ensayo.
  • No debe incluir vínculos a AppSource.
  • No debe requerir autenticación para acceder a la directiva de privacidad.
  • No debe incluir vínculos a interfaces de usuario o tiendas comerciales.
  • Debe tener el mismo vínculo en el manifiesto de la aplicación y AppSource.

Términos de uso

[corrección obligatoria]

Use las siguientes directrices para escribir el Condiciones de uso:

  • Debe ser específico y aplicable a su oferta.
  • Debe estar hospedado en su propio dominio.
  • Debe tener un vínculo seguro (HTTPS).
  • El acceso a Condiciones de uso no debe requerir autenticación.
  • Debe tener el mismo vínculo en el manifiesto de la aplicación y AppSource.

[corrección obligatoria]

Las direcciones URL de soporte técnico de la aplicación no deben requerir autenticación. Por ejemplo, los usuarios deben poder ponerse en contacto con usted sin iniciar sesión.

Expandir para obtener más información

Las direcciones URL de soporte técnico deben incluir los detalles de contacto o una forma de avanzar para que los usuarios generen una incidencia de soporte técnico. Por ejemplo, si la dirección URL de soporte técnico se hospeda en GitHub, la página de GitHub debe estar bajo su propiedad y debe incluir los detalles de contacto o una forma de avanzar para que los usuarios generen una incidencia de soporte técnico.

validation-support-links-auth

Localización

[corrección obligatoria]

  • Si su aplicación es compatible con la localización, el paquete de su aplicación debe incluir un archivo con traducciones de idiomas que se muestren en función de la configuración del idioma de Teams. El archivo debe ajustarse al esquema de localización de Teams. Para obtener más información, vea esquema de localización de Teams. [corrección obligatoria]

  • El contenido de metadatos de la aplicación debe ser el mismo en en-us y en otros lenguajes de localización. [corrección obligatoria]

  • Los idiomas admitidos deben mostrarse en la descripción de la aplicación AppSource. Por ejemplo, esta aplicación está disponible en X (X= idioma localizado). [corrección obligatoria]

  • Si la configuración de cliente del usuario no coincide con ninguno de los idiomas adicionales, el idioma predeterminado se usa como idioma de reserva final. Actualice la localizationInfo propiedad con el idioma predeterminado correcto que admite la aplicación. [corrección obligatoria]

  • Actualice la localizationInfo propiedad con el idioma predeterminado correcto que admite la aplicación o agregue contenido localizado para el manifiesto de la aplicación y la descripción larga y breve del Centro de partners. [corrección obligatoria]

Aplicaciones vinculadas a la oferta de SaaS

Esta sección está en línea con el número de directiva de Marketplace comercial de Microsoft 1140.5. Si va a crear una aplicación de Teams vinculada a una oferta de software como servicio (SaaS), asegúrese de que cumple estas directrices.

General
  • Los ISV deben admitir la posibilidad de que varios usuarios (suscriptores) del mismo inquilino administren su propia suscripción y asignen licencias a los usuarios del inquilino.
  • La oferta debe cumplir todos los requisitos técnicos para las aplicaciones de Teams vinculadas a una oferta de SaaS.
  • Las aplicaciones de Teams vinculadas a la oferta de SaaS deben cumplir todos los requisitos definidos en 1000 Software as a Service (SaaS).
  • subscriptionOffer los detalles mencionados en el archivo de manifiesto de la aplicación deben ser correctos. En el manifiesto de la aplicación, agregue o actualice subscriptionOffer con valor añadido publisherId.offerId. Por ejemplo, si el identificador del publicador es contoso1234 y el identificador de la oferta es offer01, el valor que especifique en el manifiesto de la aplicación debe ser contoso1234.offer01.
  • La oferta SaaS vinculada a la aplicación Teams debe estar activa en AppSource y las ofertas en versión preliminar no se aceptan para la aprobación de la Tienda Teams.

Metadatos de la oferta
  • Los metadatos de la oferta deben coincidir en el manifiesto de la aplicación, la lista de aplicaciones de Teams en AppSource y la oferta de SaaS en AppSource.
  • La aplicación de Teams y la oferta de SaaS deben pertenecer al mismo editor o desarrollador. La oferta SaaS a la que se hace referencia en el manifiesto de la aplicación debe pertenecer al mismo publicador que la aplicación de Teams se envía al marketplace comercial.
  • Como la oferta enviada es una aplicación de Teams vinculada a la oferta de SaaS, debe seleccionar Compras adicionales como Sí, mi producto requiere la compra de un servicio o ofrece compras adicionales desde la aplicación en la sección de configuración de productos del Centro de partners de la lista de ofertas.
  • Las descripciones del plan y los detalles de precios deben proporcionar información suficiente para que los usuarios comprendan claramente los listados de ofertas.
  • Las limitaciones, dependencias en servicios adicionales y excepciones a las características ofrecidas se deben indicar con precisión en las descripciones del plan.
  • Las aplicaciones de Teams vinculadas a la oferta de SaaS están diseñadas para admitir licencias asignadas sobre la base de nombres y usuarios. A veces, la oferta de SaaS se crea con otro método o tiene flujos de compra especializados. Debe hacer mención claramente en los metadatos de la aplicación y los detalles del plan de suscripción sobre el método y los flujos de compra.
  • La oferta de SaaS debe proporcionar mensajes e instrucciones a todos los usuarios en todos los estados aplicables de flujo de compra.

Página principal de la oferta de SaaS y administración de licencias
  • Ofrecer una introducción a los suscriptores sobre cómo usar el producto.

  • Permitir que el suscriptor asigne licencias.

  • Proporcione diferentes formas de interactuar con el soporte técnico para problemas, como preguntas más frecuentes, knowledge base y correo electrónico.

  • Valide a los usuarios para asegurarse de que aún no tienen una licencia asignada a través de otro usuario.

  • Notificar a los usuarios después de la asignación de licencias.

  • Guía a los usuarios sobre cómo agregar la aplicación a Teams y empezar a usar el bot de chat o el correo electrónico de Teams.

  • Si una aplicación SaaS usa la administración de licencias de Microsoft, después de la confirmación de la suscripción de la aplicación en la página de aterrizaje del ISV, se debe redirigir al usuario a la administración de licencias de Microsoft en Teams para evitar un dead-end y permitir al usuario administrar licencias dentro de Teams.


Facilidad de uso y funcionalidad
  • Después de adquirir y asignar licencias correctamente, debe proporcionar lo siguiente:
    • Acceso a los usuarios para las características del plan suscrito.
    • Valor añadido y ventajas significativas del plan de suscripción para los usuarios.
    • Desde la aplicación de Teams, proporcione un vínculo a la página principal de la aplicación SaaS para que los suscriptores administren las licencias en el futuro.

Configuración y prueba de la aplicación SaaS

Si la configuración de la aplicación con fines de prueba es compleja, proporcione un documento funcional de un extremo a otro, pasos de configuración de la oferta SaaS vinculada e instrucciones para la administración de licencias y usuarios como parte de las Notas para la certificación.

Sugerencia

Puede agregar un vídeo sobre cómo funciona la administración de licencias y aplicaciones para ayudar al equipo a realizar pruebas.

Volver al principio

Pestañas

Esta sección está en línea con el número de directiva de Marketplace comercial de Microsoft 1140.4.2. Si la aplicación incluye una pestaña, asegúrese de que cumple estas directrices.

Sugerencia

Para obtener más información sobre cómo crear una experiencia de aplicación de alta calidad, consulte Directrices de diseño de pestañas en Teams.


Configuración
  • La configuración de tabulación no debe incluir un nuevo usuario. Proporcionar un mensaje sobre cómo completar la acción o el flujo de trabajo. [corrección obligatoria]

    El gráfico muestra un ejemplo de Tab con un dead-end al configurar.

  • El usuario no debe dejar la experiencia de configuración de la pestaña dentro de Teams para crear contenido fuera de Teams y, a continuación, volver a Teams para anclarlo. La pantalla de configuración de pestañas debe explicar el valor de la configuración y cómo realizar la configuración. [corrección obligatoria]

    validation-tabs-set-up-profile-name

  • La pantalla de configuración de tabulación no debe insertar un sitio web completo. Mantenga su experiencia de configuración centrada. Por ejemplo, si va a crear una aplicación de administración de proyectos que permita a los usuarios configurar un proyecto en un canal, mantenga la pantalla de configuración de pestañas centrada en permitir que el usuario seleccione un proyecto de la aplicación para configurarlo en el canal. [corrección obligatoria]

    validation-tabs-setup-configuration-exp

    validation-tabs-set-up-configuration-screen

  • Las aplicaciones que requieren que los usuarios escriban una dirección URL al configurar una pestaña deben:

    • Proporcione una guía de avance adecuada para que el usuario adquiera o genere la dirección URL. [corrección obligatoria]

    • Compruebe si la dirección URL es relevante o adecuada para la funcionalidad de la aplicación según la descripción de la aplicación. [corrección obligatoria]

      Captura de pantalla que muestra un ejemplo de configuración de tabulación con una manera de avanzar para que el usuario genere una dirección URL.

      Captura de pantalla que muestra un ejemplo de configuración de tabulación sin una manera de avanzar para que el usuario genere una dirección URL.

  • Hipervínculo la información de contacto en la pantalla de configuración en lugar de texto sin formato para ayudar a los usuarios a ponerse en contacto con usted para conocer los requisitos de soporte técnico. [corrección obligatoria]

  • Para una experiencia de usuario de primera ejecución sin problemas, se recomienda hipervínculo la dirección URL de soporte técnico o el correo electrónico en la pantalla de configuración. [Corrección sugerida]


Vistas
  • El área de pantalla de inicio de sesión no debe usar logotipos grandes. [corrección obligatoria]

    validation-views-app-login

  • El contenido se puede simplificar desglosándolo en varias pestañas.

    val-views-multiple-tabs

  • Las pestañas no deben tener un encabezado duplicado. Quite los logotipos duplicados del marco I, ya que el marco de tabulación ya muestra el icono y el nombre de la aplicación. [Corrección sugerida]

    El gráfico muestra un ejemplo de una pestaña sin encabezados y logotipos duplicados.

    El gráfico muestra un ejemplo de una pestaña con encabezados y logotipos duplicados.


Navegación

Estas son las directrices de navegación:

  • Las pestañas no deben proporcionar navegación que entre en conflicto con la navegación principal de Teams. Si proporciona un panel de navegación izquierdo en la pestaña, no debe incluir solo iconos o iconos con texto apilado. No debe ser un riel contraíble con la opción de ver iconos con texto apilado (imitando la barra de navegación de Teams). Incluya iconos con texto en línea o solo texto o use menús de hamburguesa en lugar de la barra de tabulación izquierda. [corrección obligatoria]

    Diseñe su aplicación con componentes de UI Fluent básicos y avanzados.

    El gráfico muestra un ejemplo de navegación en una pestaña que no entra en conflicto con la navegación principal de Teams.

    El gráfico muestra un ejemplo de la barra de navegación izquierda que entra en conflicto con la navegación principal de Teams.

  • Si la pestaña tiene una barra de herramientas en el riel izquierdo sin ningún componente de navegación, la barra de herramientas debe dejar un espaciado de 20 píxeles desde la navegación izquierda de Teams. [corrección obligatoria]

    validation-nav-spacing-between-toolbar

  • Las páginas secundarias y terciarias de una pestaña deben abrirse en una vista de nivel dos (L2) y nivel tres (L3) en el área de tabulación principal, que se navega a través de rutas de navegación o navegación izquierda. También puede usar los siguientes componentes para ayudar a la navegación en una pestaña:

    • Botones Atrás

    • Encabezados de página

    • Menús de hamburguesa

      Captura de pantalla que muestra un ejemplo de diálogo en reunión con varios niveles de navegación.

  • Los vínculos profundos en las pestañas no deben vincularse a una página web externa, sino dentro de Teams. Por ejemplo, diálogos u otras pestañas. [corrección obligatoria]

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

  • Las pestañas no deben permitir que los usuarios naveguen fuera de Teams para obtener la experiencia básica de la aplicación. Las pestañas pueden redirigir fuera de Teams para flujos de trabajo no principales. Por ejemplo, para generar una incidencia de soporte técnico. [corrección obligatoria]

    validation-nav-core-workflow-within-configuration

    validation-nav-core-workflow-redirects-outside

  • El desplazamiento horizontal no debe estar presente en una pestaña en la reunión. [Corrección obligatoria]

  • Los diálogos en la reunión que se usan en la aplicación no deben permitir el desplazamiento horizontal. Use diálogos en reuniones con moderación y para escenarios que estén orientados a tareas y a la luz. Puede especificar el ancho del marco I del cuadro de diálogo en la reunión dentro del intervalo de tamaño admitido para tener en cuenta diferentes escenarios. [corrección obligatoria]

  • Los diálogos usados en la aplicación no deben permitir el desplazamiento horizontal. Los cuadros de diálogo permiten seleccionar diferentes tamaños para que el contenido responda sin necesidad de desplazamiento horizontal. Si es necesario, puede usar una vista previa (un componente de interfaz de usuario de pantalla completa para exponer el contenido web) para completar el flujo de trabajo sin desplazamiento horizontal. [corrección obligatoria]

  • No se permite el desplazamiento horizontal presente en la pestaña de una pestaña de detalles de chat personal, canal y reunión en cualquier ámbito si todo el lienzo de pestaña se puede desplazar, a menos que la pestaña use un lienzo infinito con elementos fijos de la interfaz de usuario. [corrección obligatoria]

    El gráfico muestra ejemplos de todos los escenarios en dispositivos móviles en los que se permite el desplazamiento horizontal.

    El gráfico muestra un ejemplo de desplazamiento horizontal en el panel Kanban.

    El gráfico muestra un ejemplo de vista de lista con muchos componentes.

    El gráfico muestra un ejemplo de desplazamiento horizontal en una pizarra blanca con lienzo infinito y placa fija.

    El gráfico muestra un ejemplo de desplazamiento horizontal en la vista de lista.

  • El usuario debe tener una opción para ir al estado de trabajo anterior. [corrección obligatoria]

     Captura de pantalla que muestra la opción de botón Atrás disponible.

    Captura de pantalla que muestra el escenario con errores de ninguna opción de botón Atrás disponible.

  • El desplazamiento horizontal en tarjetas adaptables no debe estar presente en Teams. [corrección obligatoria]

  • La barra inferior que se usa para la navegación en pestañas no debe entrar en conflicto con la navegación de aplicaciones móviles nativas de Teams. [corrección obligatoria]

    El gráfico muestra un ejemplo de una pestaña que entra en conflicto con la navegación nativa de aplicaciones móviles de Teams.


Usabilidad
  • El contenido no debe truncarse ni superponerse dentro de la pestaña. [Corrección obligatoria]

    validation-usability-content-truncations

  • Los usuarios deben poder deshacer su última acción en la pestaña. [Corrección obligatoria]

  • Las pestañas en un contexto personal pueden agregar contenido de instancias compartidas de la aplicación. Por ejemplo, una aplicación de administración de proyectos con una pestaña configurable que permite a los miembros del canal comentar el proyecto en tarjetas Kanban debe agregar ese contenido y mostrarlo en la aplicación personal. [Corrección sugerida]

  • Las pestañas deben responder a los temas de Teams. Cuando un usuario cambia el tema, el tema de la aplicación debe reflejar la selección. [Corrección sugerida]

    El gráfico muestra un ejemplo de una pestaña que responde a un tema en Teams.

    El gráfico muestra un ejemplo de una pestaña que no responde al tema en Teams.

  • Las pestañas deben usar componentes con estilo de Teams, como fuentes de Teams, rampas de tipo, paletas de colores, sistema de cuadrícula, movimiento, tono de voz, siempre que sea posible. Para obtener más información, vea directrices de diseño de pestañas. [Corrección sugerida]

    Captura de pantalla que muestra un ejemplo de una pestaña con fuente calibri en lugar de una fuente nativa de Teams.

  • Si la funcionalidad de la aplicación requiere cambios en la configuración, incluya una pestaña deConfiguración. [Corrección sugerida]

  • Las pestañas deben seguir el diseño de interacción de Teams, como la navegación en la página, la posición y el uso de diálogos, las jerarquías de información. Para obtener más información, consulte Kit de interfaz de usuario de Microsoft Teams Fluent. [Corrección sugerida]

  • Las experiencias de pestañas deben tener una capacidad de respuesta total en dispositivos móviles (Android e iOS). [corrección obligatoria]

    Sugerencia

    • Incluir un bot personal junto a una ficha personal.
    • Permitir a los usuarios compartir contenidos desde su pestaña personal.
  • Tab no debe contener elementos que obstruyan o impidan completamente los flujos de trabajo dentro de la pestaña. Por ejemplo, bot dentro de una pestaña que no se puede minimizar. [corrección obligatoria]

    El gráfico muestra un ejemplo de pestaña con elementos que impiden los flujos de trabajo dentro de la pestaña.

  • La pestaña no debe tener una funcionalidad rota. Su oferta debe ser una solución de software utilizable y debe proporcionar la funcionalidad, las características y los resultados, tal como se describe en la descripción y otros materiales relacionados. [corrección obligatoria]

  • Si las pestañas contienen un pie de página, asegúrese de quitar del pie de página todos los vínculos no relacionados con la funcionalidad de la aplicación. [corrección obligatoria]


Selección de ámbito
  • El contenido de la página de aterrizaje de las pestañas configurables no debe tener un ámbito para uso individual y no incluir contenido personal como Mis tareas o Mi panel. [corrección obligatoria]

    El gráfico muestra un ejemplo de contenido en una pestaña configurable con ámbito personal, como Mis tareas o Mi panel.

  • Después de la experiencia de configuración, la página de aterrizaje debe mostrar una vista de colaboración para todo el equipo. [corrección obligatoria]

  • Si la aplicación requiere el aprovisionamiento de una vista de ámbito personal para que el usuario mejore la eficacia o la productividad del área de trabajo, use vistas filtradas, vínculos profundos a aplicaciones personales o navegue a las vistas L2 o L3 dentro de la pestaña configurable y mantenga la página de aterrizaje contextualmente igual para todos los usuarios. [corrección obligatoria]

  • El contenido de la página de aterrizaje de las pestañas configurables debe ser contextualmente el mismo para todos los miembros del canal. [corrección obligatoria]

    El gráfico muestra un ejemplo de contenido en la página de aterrizaje de las pestañas configurables contextualmente diferentes para todos los miembros.

  • Las pestañas configurables deben tener una funcionalidad centrada. [corrección obligatoria]

    validation-usability-configurable-nested-tab


Volver al principio

Bots

Esta sección se alinea con el número de directiva de Marketplace comercial de Microsoft 1140.4.3.

Si la aplicación incluye un bot, asegúrese de que cumple estas directrices.

Sugerencia

Para obtener más información sobre cómo crear una experiencia de aplicación de alta calidad, consulte directrices de diseño de bots de Teams.


Directrices de diseño de bots
  • La aplicación de Teams debe seguir las directrices de diseño del bot de Teams.

  • Debe implementar un cuadro de diálogo para evitar la respuesta del bot de varios turnos cuando el flujo de trabajo implica al usuario realizar tareas repetitivas. Por ejemplo, use un cuadro de diálogo para capturar de forma repetitiva el nombre, el dob, el lugar y la designación en lugar de usar conversaciones de varios turnos. [corrección obligatoria]

  • Los vínculos, respuestas o flujos de trabajo rotos de la aplicación deben corregirse. [corrección obligatoria]


Comandos de bot

Analizar las entradas de los usuarios y predecir su intención es difícil. Los comandos de bot proporcionan a los usuarios un conjunto de palabras o frases para que el bot las entienda.

  • Todos los comandos que admite el bot deben funcionar correctamente, incluidos los comandos genéricos como Hi, Helloy Help. [corrección obligatoria]

    El gráfico muestra un ejemplo de bot que responde a comandos genéricos.

    El gráfico muestra un ejemplo de bot sin respuesta a comandos genéricos.

  • Los comandos de bot no deben llevar a un usuario a un punto muerto; los comandos siempre deben proporcionar una manera de avanzar. [corrección obligatoria]

    validation-bot-commands-dead-end

  • Debe enumerar al menos un comando de bot válido en la items.commands.title sección del manifiesto de la aplicación y agregar una descripción adecuada que proporcione claridad al usuario sobre el comando del bot y su uso. Los comandos de bot que aparecen en la commandLists sección de la superficie del manifiesto de la aplicación como comandos rellenados previamente en el menú de comandos del bot y proporcionan una manera de avanzar para que el nuevo usuario interactúe con el bot. [Corrección sugerida]

  • La respuesta del bot no debe contener imágenes o avatares oficiales de productos de Microsoft. Usa tus propios recursos en la aplicación. No se permite el uso de imágenes de producto de Microsoft en la aplicación. Solo puede copiar, modificar, distribuir, mostrar, licenciar o vender imágenes de producto protegidas por derechos de autor de Microsoft si se le concede permiso explícito dentro del contrato de licencia de End-User (CLUF), los términos de licencia que acompañan al contenido o en las directrices de marca comercial y marca de Microsoft. [corrección obligatoria]

  • Los bots deben responder a los comandos del usuario sin mostrar un indicador de carga continua. [corrección obligatoria]

  • La respuesta del comando de ayuda del bot no debe redirigir al usuario fuera de Teams. La respuesta de comandos de ayuda del bot puede redirigir al usuario a un lienzo dentro de la aplicación teams o proporcionar una respuesta de avance en una tarjeta adaptable. [corrección obligatoria]

    El gráfico muestra un ejemplo de respuesta del bot que redirige al usuario fuera de Teams.

  • Los bots siempre deben proporcionar una respuesta válida a una entrada del usuario, incluso si la entrada es irrelevante o incorrecta. [corrección obligatoria]

    El gráfico muestra un ejemplo de una respuesta válida para un comando de bot incorrecto.

    El gráfico muestra un ejemplo de una respuesta no válida para un comando de bot incorrecto.

  • Los caracteres especiales, como la barra diagonal (/), no deben ir precedidos de comandos de bot. [corrección obligatoria]

    El gráfico muestra un ejemplo de un escenario con errores en el que los caracteres especiales tienen como prefijo los comandos del bot.

  • Los bots deben proporcionar una respuesta válida a los comandos de usuario no válidos. Los bots no deben enviar al usuario un error o mostrar un error si un usuario envía un comando de bot no válido. [corrección obligatoria]

    El gráfico muestra un ejemplo de bot que proporciona una manera de avanzar para un comando no válido.

    El gráfico muestra un ejemplo de un escenario con errores en el que un bot envía una misma respuesta para un comando válido y no válido.

  • La funcionalidad del bot debe ser relevante para el ámbito en el que está instalado el bot y el bot debe proporcionar valor en el ámbito instalado. [corrección obligatoria]

  • Los bots no deben contener comandos duplicados. [corrección obligatoria]

  • Los bots no deben mostrar un indicador de escritura después de responder al comando del usuario, pero pueden mostrar un indicador de escritura mientras responden al comando del usuario. [corrección obligatoria]

  • Los bots deben proporcionar una respuesta válida al comando de ayuda escrito en minúsculas o en mayúsculas que proporcione al usuario una manera de avanzar o permita al usuario acceder al contenido de ayuda relacionado con el uso del bot. Los bots deben proporcionar una respuesta válida incluso cuando el usuario no haya iniciado sesión en la aplicación. [corrección obligatoria]

    El gráfico muestra un ejemplo de bot que no proporciona una respuesta válida para un comando en minúsculas o en mayúsculas.

    El gráfico muestra un ejemplo de un bot sin una respuesta válida cuando el usuario no ha iniciado sesión en la aplicación.

  • Los bots deben proporcionar una respuesta válida para ayudar al comando.

    El gráfico muestra un ejemplo de bot que envía una respuesta válida para el comando help.

  • Las respuestas de bot en dispositivos móviles deben responder sin ningún truncamiento de datos que entorpece el uso del bot del usuario final para completar los flujos de trabajo deseados. [corrección obligatoria]

    El gráfico muestra un ejemplo de un mensaje de bot sin truncarse en el móvil.

    El gráfico muestra un ejemplo de un mensaje de bot truncado en el móvil.

  • Todos los vínculos de una tarjeta adaptable de respuesta del bot deben responder. Cualquier vínculo que lleve al usuario fuera de la plataforma de Teams debe tener un texto de redireccionamiento claro, como Ver en.. o De esta manera a.., un icono emergente en el botón de acción de respuesta del bot o tener un texto de redireccionamiento adecuado en el cuerpo del mensaje de respuesta del bot. [corrección obligatoria]

    El gráfico muestra un ejemplo del botón de acción de respuesta del bot con un redireccionamiento.

  • Por diseño, si el bot no responde ni admite ningún comando de usuario y es un bot unidireccional destinado solo a notificar a los usuarios. Debe establecer en isNotificationOnly true en el manifiesto de la aplicación. [corrección obligatoria]

    El gráfico muestra un ejemplo de la propiedad notification only establecida en true en el manifiesto de la aplicación.

    El gráfico muestra un ejemplo de bot de notificación solo que no responde para el mensaje de un usuario.

  • La experiencia del usuario del bot no debe romperse en las plataformas móviles. El bot debe tener una capacidad de respuesta completa en dispositivos móviles. [corrección obligatoria]

Sugerencia

Para los bots personales, incluye una pestaña de Ayuda que describa con más detalle lo que puede hacer su bot.


Mensajes de bienvenida del bot
  • Si la aplicación tiene un flujo de configuración complejo (requiere una licencia de empresa o carece de un flujo de registro intuitivo), los bots de estas aplicaciones siempre deben enviar un mensaje de bienvenida durante la primera ejecución.

    Para obtener la mejor experiencia, el mensaje de bienvenida debe incluir el valor que ofrece el bot a los usuarios, que instalaron el bot en el canal, cómo configurar el bot y describir brevemente todos los comandos de bot admitidos. Puede mostrar el mensaje de bienvenida con una tarjeta adaptable con botones para mejorar la facilidad de uso. Para obtener más información, consulte cómo activar un mensaje de bienvenida del bot. En el caso de las aplicaciones sin un flujo de configuración complejo, puede elegir desencadenar un mensaje de bienvenida durante la primera experiencia de ejecución del bot. Sin embargo, si se desencadena un mensaje de bienvenida, debe seguir las instrucciones del mensaje de bienvenida.

    El gráfico muestra un ejemplo de bot que envía un mensaje de bienvenida cuando el bot tiene un flujo de trabajo de configuración complejo.

    El gráfico muestra un ejemplo de bot que no envía un mensaje de bienvenida cuando el bot tiene un flujo de trabajo de configuración complejo.

  • Los mensajes de bienvenida del bot en los canales y chats son opcionales durante la primera ejecución, especialmente si el bot está disponible para uso personal y realiza acciones similares. El bot no debe enviar mensajes de bienvenida a los usuarios individualmente (se considera spam). El mensaje también debe mencionar a la persona que agregó el bot.

    validation-bot-welcome-message-not-trigger

    validation-bot-wel-message-trigger

  • Solo los bots de notificación deben enviar un mensaje de bienvenida que aclara que el bot es un bot de notificación solo y los usuarios no podrán interactuar con él. [corrección obligatoria]

    El gráfico muestra un ejemplo de bot que envía un mensaje de bienvenida que indica que es un bot solo de notificación.

  • El mensaje de bienvenida no debe ser un error para el usuario. El mensaje de bienvenida debe incluir el valor que ofrece el bot a los usuarios que instalaron el bot en el canal, cómo configurar el bot y describir brevemente todos los comandos de bot admitidos. Puede mostrar el mensaje de bienvenida con una tarjeta adaptable con botones para mejorar la facilidad de uso. [corrección obligatoria]

    El gráfico muestra un ejemplo de un escenario con errores en el que el bot no tiene ninguna manera de avanzar para el usuario en un mensaje de bienvenida.

    El gráfico muestra un ejemplo de mensaje de bienvenida del bot con una manera clara de avanzar para que el usuario complete la tarea.

  • El bot instalado en un ámbito de chat de canal o grupo no debe enviar un mensaje de bienvenida proactivo a todos los miembros del equipo en el chat 1:1. [corrección obligatoria]

    El gráfico muestra un ejemplo de bot que envía un mensaje de bienvenida proactivo a todos los miembros del equipo.

  • Solo el bot de notificación puede enviar un mensaje de bienvenida proactivo en un canal solo si el mensaje contiene información importante para que cualquier usuario complete la configuración del bot o aclare los escenarios en los que se desencadenan las notificaciones. [corrección obligatoria]

  • El bot instalado en un ámbito de chat de canal o grupo no debe enviar mensajes proactivos (no solo mensajes de bienvenida) que sean irrelevantes para todos los usuarios del chat de canal o grupo, sino que deben enviar mensajes proactivos al usuario a través del chat 1:1. [corrección obligatoria]

  • El bot instalado en un ámbito de chat de canal o grupo no debe permitir que los usuarios inicien flujos de trabajo individuales. Los bots deben completar flujos de trabajo individuales en el chat 1:1 con el usuario. [corrección obligatoria]

  • El mensaje de bienvenida del bot debe indicar claramente las limitaciones relacionadas con el uso del bot en el ámbito instalado. [corrección obligatoria]

    El gráfico muestra un ejemplo de limitación de aplicaciones en el mensaje de bienvenida del bot.

    El gráfico muestra un ejemplo de un bot sin limitación de aplicación en un mensaje de bienvenida.

  • El mensaje de bienvenida debe desencadenarse automáticamente al instalar la aplicación en un ámbito personal. Si el bot no envía un mensaje de bienvenida en un ámbito personal, el usuario se lleva a un punto muerto. Si la aplicación no incluye un flujo de trabajo de configuración complejo, es opcional que el desarrollador desencadene un mensaje de bienvenida en el ámbito de chat de grupo o canal. [corrección obligatoria]

    El gráfico muestra un ejemplo de bot que no envía un mensaje de bienvenida automáticamente en el ámbito personal.

  • Los mensajes de bienvenida solo deben desencadenarse una vez al instalar el bot. Los mensajes de bienvenida no deben desencadenarse cada vez que el usuario invoca el comando de ayuda. La respuesta del comando de ayuda debe centrarse para incluir una manera de que el usuario acceda a la ayuda relacionada con el bot. [corrección obligatoria]

  • Los mensajes de bienvenida no deben desencadenarse con todos los comandos del bot. Esto se considera spam. [corrección obligatoria]

    El gráfico muestra un ejemplo para que el bot desencadene un mensaje de bienvenida para cualquier comando.

  • El contenido del mensaje de bienvenida debe estar relacionado con el flujo de trabajo del bot mencionado en la descripción larga de la aplicación y el ámbito de instalación. El mensaje de bienvenida debe incluir el valor que ofrece el bot a los usuarios que instalaron el bot en el canal, cómo configurar el bot y describir brevemente todos los comandos de bot admitidos. [corrección obligatoria]

  • El bot no debe enviar varios mensajes de bienvenida cuando se desencadena al instalar la aplicación. [corrección obligatoria]

    El gráfico muestra un ejemplo de bot que desencadena varios mensajes de bienvenida durante la instalación de la aplicación.

  • El nombre de la aplicación en el mensaje de bienvenida debe coincidir con el nombre de la aplicación en el manifiesto de la aplicación. [corrección obligatoria]

    El gráfico muestra un ejemplo de nombre de aplicación en el mensaje de bienvenida que no coincide con el nombre de la aplicación en el manifiesto de la aplicación.

  • El mensaje de bienvenida no debe mostrar nombres de plataformas de colaboración basadas en chat de la competencia a menos que la aplicación proporcione interoperabilidad específica.

  • El mensaje de bienvenida no debe redirigir al usuario a otra aplicación de Teams, sino que el mensaje de bienvenida debe empujar al usuario para completar su primera tarea y describir brevemente todos los comandos de bot admitidos en la aplicación. [corrección obligatoria]

  • El mensaje de bienvenida no debe contener vínculos a ningún marketplace de aplicaciones, incluido AppSource. [corrección obligatoria]

  • Si la aplicación tiene un flujo de trabajo de configuración complejo que requiere la instalación dirigida por el administrador, no tiene un flujo de registro intuitivo y disponible, o requiere que los usuarios completen los pasos de configuración fuera de la experiencia de Teams y vuelvan, el bot debe enviar un mensaje de bienvenida proactivo en un ámbito de chat de grupo o equipo después de la instalación. [corrección obligatoria]

  • Si el bot envía un mensaje de bienvenida en el canal, no debe enviarlo a los usuarios de forma individual (se considera spam). El mensaje de bienvenida también debe mencionar a la persona que agregó el bot. [Corrección sugerida]

Sugerencia

En los mensajes de bienvenida a usuarios individuales, un paseo por el carrusel puede proporcionar una visión general eficaz del bot y cualquier otra característica de la aplicación para animar a los usuarios a probar los comandos bot. Por ejemplo, Crear una tarea.


Correo no deseado de mensajes de bot

Los bots no deben enviar correo no deseado a los usuarios enviando varios mensajes de corta duración.

  • Mensajes de bots en canales y chats: No cree spam, enviando mensajes separados a los usuarios. Crear una publicación única con respuestas en el mismo hilo. [corrección obligatoria]

    validation-bot-message-spam-one-message

    validation-bot-message-spam-multiple-message

  • mensajes de bot en aplicaciones personales:

    • No envíe varios mensajes en sucesión rápida. [corrección obligatoria]

      El gráfico muestra un ejemplo de un bot que envía varios mensajes en sucesión rápida.

    • Envíe un mensaje con la información completa. [corrección obligatoria]

    • Evite las conversaciones de varios turnos para completar un único flujo de trabajo repetitivo. [corrección obligatoria]

    • Use un formulario (o cuadro de diálogo) para recopilar todas las entradas de un usuario a la vez. [corrección obligatoria]

    • Los bots de chat conversacionales basados en NLP pueden usar la conversación de varios turnos para que el diálogo sea más atractivo y complete un flujo de trabajo.

      validation-bot-message-using-task-module

      El gráfico muestra un bot de ejemplo que usa mensajes de varios turnos para completar una sola conversación.

  • Mensajes de bienvenida:no repita el mismo mensaje de bienvenida en intervalos regulares. Por ejemplo, cuando se agrega un nuevo miembro a un equipo, no hay que enviar un mensaje de bienvenida a los demás miembros. Enviar un mensaje personalmente al nuevo miembro. [corrección obligatoria]


Notificaciones de bot

Las notificaciones del bot deben incluir contenido relevante para el ámbito que se defina para el bot (equipo, chat o personal). [corrección obligatoria]

validation-bot-notification-relevant

validation-bot-notification-not-relevant


Bots y tarjetas adaptables

Las tarjetas adaptativas son una forma muy recomendable de mostrar los mensajes de los bots. Las tarjetas deben ser ligeras y solo deben incluir un máximo de seis acciones. Para mostrar más contenido, considere la posibilidad de usar un cuadro de diálogo o una pestaña.

Para obtener más información acerca de las tarjetas, consulte:

La experiencia del bot debe ser totalmente dinámica en dispositivos móviles. Las respuestas del bot deben proporcionar una manera de avanzar cuando corresponda. El bot debe responder y generar un error con un mensaje de error estable para los errores. Los mensajes de bot enviados en el ámbito personal a la base del usuario en los desencadenadores de un ámbito de colaboración deben proporcionar información contextual (incluido el origen del mensaje).


Solo bots de notificación

Las aplicaciones que constan de bots de solo notificación proporcionan valor añadido al usuario mediante el desencadenamiento de notificaciones de usuario basadas en determinados desencadenadores o eventos en la aplicación principal o el back-end. Por ejemplo, se agrega un nuevo cliente potencial para que el equipo de ventas realice un seguimiento. Un bot de solo notificación de alta calidad notifica a los usuarios periódicamente determinadas finalizaciones de eventos, como las finalizaciones de flujo de trabajo o las alertas.

Sugerencia

Obtenga una vista previa de la información y proporcione acciones básicas de usuario en línea en la tarjeta publicada para que el usuario no tenga que navegar fuera de Teams para todas las acciones (independientemente de la complejidad).


Información de metadatos del bot
  • La información del bot en el manifiesto de la aplicación (nombre del bot, logotipo, vínculo de privacidad y vínculo de términos de servicio) debe ser coherente con los metadatos de Bot Framework. [corrección obligatoria]

  • Asegúrese de que el identificador del bot del manifiesto de la aplicación coincida con el identificador del bot en la última versión publicada de la Tienda Teams de la aplicación. El cambio de los identificadores de bot en una actualización de la aplicación conduce a la pérdida permanente de todo el historial de interacción del usuario con el bot para los usuarios existentes de la aplicación e inicia una nueva cadena de conversación con el nuevo identificador de bot. [corrección obligatoria]

  • Cualquier cambio en el nombre de la aplicación, los metadatos, el mensaje de bienvenida del bot o las respuestas del bot debe actualizarse con un nuevo nombre. [corrección obligatoria]

  • El nombre de la aplicación en el mensaje de bienvenida del bot o las respuestas del bot deben coincidir con el nombre de la aplicación en el manifiesto de la aplicación. [corrección obligatoria]


Bot en ámbito de colaboración
  • No se permite la instalación de bots en un ámbito de chat de canal o grupo para obtener la lista de equipos para enviar notificaciones proactivas para los usuarios, ya que no se permiten chats 1:1 para desencadenadores específicos del equipo. Por ejemplo, la aplicación que empareja a personas para una reunión. [corrección obligatoria]

  • Bot en un canal o chat de grupo que solo se usa para obtener los mensajes o publicaciones para enviar notificaciones proactivas para los usuarios, ya que no se permiten los chats 1:1. [corrección obligatoria]

  • Los bots instalados en el ámbito de colaboración deben proporcionar un valor de usuario en el ámbito de colaboración. [corrección obligatoria]

Volver al principio

Extensiones de mensajería

Esta sección se alinea con el número de directiva de Marketplace comercial de Microsoft 1140.4.4.

Si la aplicación incluye una extensión de mensaje, asegúrese de que cumple estas directrices.

Sugerencia

Para obtener más información sobre cómo crear una experiencia de aplicación de alta calidad, vea las directrices de diseño de extensiones de mensaje de Teams.


Directrices de diseño de extensiones de mensajería
  • Si la aplicación de Teams usa la funcionalidad de extensión de mensajería, la aplicación debe seguir las directrices de diseño de la extensión de mensajería.

    El gráfico muestra un ejemplo de una aplicación que no cumple las directrices de extensión.

  • Las extensiones de mensajería son métodos abreviados para insertar contenido de la aplicación o realizar una acción en un mensaje sin salir de la conversación. Mantenga la extensión de mensajería simple y muestre solo los componentes necesarios para completar la acción de forma eficaz. El sitio web completo no debe incluirse en la extensión de mensajería. [corrección obligatoria]

  • Las imágenes en versión preliminar en tarjetas adaptables en extensiones de mensajería deben cargarse correctamente. [corrección obligatoria]

    El gráfico muestra un ejemplo de carga de imágenes en versión preliminar en la tarjeta adaptable.

    El gráfico muestra un ejemplo de imagen de vista previa que no se carga en la tarjeta adaptable.

  • La tarjeta de respuesta de la extensión de mensajería debe incluir el icono de aplicación para evitar confusiones del usuario final. [corrección obligatoria]

  • La aplicación no debe tener ninguna funcionalidad rota. La aplicación no debe impedir que el usuario complete un flujo de trabajo en una extensión de mensajería. [corrección obligatoria]

  • Las extensiones de mensajería deben responder o funcionar según lo previsto en los ámbitos de canal y chat en grupo. [corrección obligatoria]

  • Debe incluir una manera de que el usuario inicie sesión o cierre la sesión desde la extensión de mensajería. [corrección obligatoria]

  • Las extensiones de mensaje que usan direcciones URL de OpenAPI no deben proporcionar redireccionamiento en ninguna llamada API. Las llamadas API reales se deben atender desde el mismo dominio o subdominio del dominio raíz.


Comandos de acción para extensiones de mensaje basadas en acciones

Las extensiones de mensaje basadas en acciones deben hacer lo siguiente:

  • Permitir que los usuarios desencadenen acciones en un mensaje sin completar pasos intermedios, como es el inicio de sesión.

    validation-messaging-extension-no-intermediate-steps

    validation-messaging-extension-intermediate-steps-available

  • Pasar el contexto del mensaje al siguiente estado de trabajo. [corrección obligatoria]

    validation-messaging-extension-app-passes-messages

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

  • Incorpore el nombre de la aplicación host en lugar de un verbo genérico para los comandos de acción que se desencadenan desde un mensaje de chat, una publicación de canal o una llamada a la acción dentro de las aplicaciones. Por ejemplo, use Iniciar una Reunión de Skype para Iniciar reunión, Cargar archivo en DocuSign para Cargar archivo. [Corrección sugerida]

    El gráfico muestra un ejemplo del nombre de la aplicación host para un comando de acción.

    El gráfico muestra un ejemplo de verbo genérico para un comando de acción.

  • La invocación de una acción de mensaje debe permitir que el usuario complete el flujo de trabajo. Los errores, las respuestas en blanco o los indicadores de carga continua para que la acción del mensaje funcione según lo previsto no deben estar presentes. [corrección obligatoria]

    El gráfico muestra un ejemplo de indicador de carga continua cuando un bot invoca un comando de acción.

  • Los comandos de acción duplicados no deben estar presentes. [corrección obligatoria]

  • Las acciones de mensaje deben permitir que el usuario complete el flujo de trabajo según lo previsto sin una respuesta no válida. [corrección obligatoria]

  • Las aplicaciones con solo la extensión de mensajería basada en acciones deben tener el siguiente estado final:

    • Publique una acción pertinente como una notificación en el contexto donde se invoca la extensión de mensaje o en el chat del bot 1:1 en función del escenario de usuario. [corrección obligatoria]

    • Permitir a los usuarios compartir tarjetas con otros usuarios en función de la acción realizada. Esto es para asegurarse de que las aplicaciones no realizan acciones silenciosas. Por ejemplo, se crea un vale en función de un mensaje de un canal, pero la aplicación no envía una notificación o no proporciona una manera de solicitar al usuario que comparta los detalles de la incidencia después de crear el vale. [corrección obligatoria]


Vínculos de vista previa (desplegamiento de vínculos)

[corrección obligatoria]

  • Si la aplicación ha declarado la supportsAnonymizedPayloads propiedad en el manifiesto de la aplicación y el usuario no ha instalado la aplicación, el vínculo de la aplicación debe desarollarse y mostrar el cuadro de diálogo Agregar aplicación después de seleccionar la tarjeta. [corrección obligatoria]

  • Las extensiones de mensaje deben obtener una vista previa de los vínculos reconocidos en el cuadro de redacción de Teams. No agregue dominios que estén fuera de su control (direcciones URL absolutas o caracteres comodín). Por ejemplo, yourapp.onmicrosoft.com es válido, pero *.onmicrosoft.com no es válido. Los dominios de nivel superior también están prohibidos. Por ejemplo, *.com o *.org. [corrección obligatoria]

  • Las aplicaciones solo deben declarar que están bajo la propiedad directa del publicador de la aplicación en la messageHandler sección de desplegamiento del vínculo del manifiesto de la aplicación. No debe contener *.botframework.com. [Corrección obligatoria]


comandos de Búsqueda
  • Las extensiones de mensaje basadas en búsqueda deben proporcionar texto que ayude a los usuarios a buscar de forma eficaz. [corrección obligatoria]

    El gráfico muestra un ejemplo de una extensión de mensaje con texto de ayuda para que los usuarios busquen de forma eficaz.

    El gráfico muestra un ejemplo de una extensión de mensaje sin texto de ayuda para que los usuarios busquen de forma eficaz.

  • @mention los ejecutables deben ser claros, fáciles de entender y legibles.

    validation-search-commands-unclear-executable

Volver al principio

Diálogos

[corrección obligatoria]

Esta sección está en línea con el número de directiva de Marketplace comercial de Microsoft 1140.4.5.

Expandir para obtener más información

Un cuadro de diálogo (denominado módulo de tareas en TeamsJS v1.x) debe incluir un icono y el nombre corto de la aplicación a la que está asociada. Los cuadros de diálogo no deben insertar una aplicación completa y mostrar solo los componentes necesarios para completar una acción específica.

Para obtener más información, consulte Directrices de diseño de cuadros de diálogo de Teams.

validation-task-module-displays-component

validation-task-module-embed-app

Sugerencia

Para obtener más información sobre cómo crear una experiencia de aplicación de alta calidad, vea directrices de diseño de módulos de tareas de Teams.

Volver al principio

Extensiones de reunión

Esta sección está en línea con el número de directiva de Marketplace comercial de Microsoft 1140.4.6.

Sugerencia

Para obtener más información sobre cómo crear una experiencia de aplicación de alta calidad, vea las directrices de diseño de la extensión de reuniones de Teams.


Directrices de diseño de extensiones de reunión
  • Las aplicaciones de Teams deben seguir las directrices de diseño de la extensión de reunión.

  • Con la experiencia de la aplicación en la reunión, puede interactuar con los participantes durante la reunión mediante pestañas, cuadros de diálogo y la característica de uso compartido en la reunión para la fase. Si la aplicación admite la extensión de reunión de Teams, debe proporcionar una experiencia dinámica en la reunión alineada con la experiencia de reunión de Teams. [corrección obligatoria]

  • Las aplicaciones de extensibilidad de reuniones deben ofrecer una experiencia dinámica en la reunión alineada con la experiencia de reunión de Teams. La experiencia en la reunión es obligatoria para una aplicación de Teams que admite la extensibilidad de reuniones, pero las experiencias previas y posteriores a la reunión no son obligatorias. [corrección obligatoria]

    • Con la experiencia de la aplicación previa a la reunión, los usuarios pueden buscar y agregar aplicaciones de reunión. Los usuarios también pueden realizar tareas previas a la reunión, como desarrollar un sondeo para encuestar a los participantes de la reunión. Si la aplicación proporciona una experiencia previa a la reunión, debe ser relevante para el flujo de trabajo de la reunión.

    • Con la experiencia de la aplicación posterior a la reunión, los usuarios pueden ver los resultados de la reunión, como, sondear los resultados de la encuesta o los comentarios y otro contenido de la aplicación. Si la aplicación proporciona una experiencia posterior a la reunión, debe ser relevante para el flujo de trabajo de la reunión.

    • Con la experiencia de la aplicación en la reunión, puede interactuar con los participantes de la reunión durante la reunión y mejorar la experiencia de la reunión para todos los asistentes. Los asistentes no deben llevarse fuera de la reunión de Teams para completar los flujos de trabajo principales de usuario de la aplicación.

    El gráfico muestra un ejemplo de una experiencia en la reunión que redirige al usuario fuera de Teams para completar la funcionalidad principal de la aplicación.

  • La aplicación debe ofrecer valor más allá de proporcionar solo escenas personalizadas del modo junto en Teams. [corrección obligatoria]

  • Debe declarar groupChat como un ámbito en configurableTabs y meetingDetailsTab, meetingChatTaby meetingSidePanel como una propiedad de contexto en el manifiesto de la aplicación para habilitar la aplicación para reuniones en dispositivos móviles de Teams. [corrección obligatoria]

  • Los lienzos de reunión no deben ser un punto muerto para un asistente a la reunión. Los lienzos de reunión deben mostrar un mensaje de error correcto para las limitaciones de la aplicación, como la dependencia específica de la región. [corrección obligatoria]

  • El encabezado del lienzo de la reunión debe mostrar el nombre correcto de la aplicación para evitar confundir al asistente a la reunión. [corrección obligatoria]

  • Debe incluir una opción para que el usuario cierre la sesión o cierre la sesión de la extensión de reunión. [corrección obligatoria]

  • Las pestañas de reunión en plataformas móviles deben incluir flujos de trabajo pertinentes. Las páginas en blanco no deben estar presentes en una pestaña de reunión. [Corrección obligatoria]

  • La fase de reunión es un lienzo de participación centrada, intuitiva y colaborativa. La fase de reunión no debe insertar la experiencia completa del sitio web. [corrección obligatoria]

  • La aplicación no debe mostrar la pantalla de carga continua, el error o la funcionalidad interrumpida que impide que el usuario o bloquee la finalización de un flujo de trabajo en un escenario de reunión. [corrección obligatoria]

    El gráfico muestra un ejemplo de pantalla de carga continua en una aplicación.

  • La aplicación no debe abrir una nueva instancia de Teams al iniciar una reunión. Los lienzos de reuniones son una extensión de las funcionalidades de Teams que promueven la colaboración en tiempo real y las nuevas reuniones deben abrirse siempre dentro de la instancia de Teams actualmente activa. [corrección obligatoria]

  • Las aplicaciones de reunión deben completar flujos de trabajo dentro de la plataforma de Microsoft Teams sin redirigir a plataformas basadas en chat de la competencia. [corrección obligatoria]

    Gráfico que muestra un ejemplo de una aplicación que redirige a la plataforma basada en chat de la competencia.

  • Si la aplicación admite vistas basadas en roles y determinados flujos de trabajo no están disponibles para todos los participantes, se recomienda implementar la mensajería adecuada para los participantes en la pestaña y el panel lateral, indicando que la aplicación es para la vista del organizador y proporcionar detalles sobre cómo los asistentes reciben las notas de la reunión, los elementos de acción y las agendas de actualización. [corrección obligatoria]

    El gráfico muestra un ejemplo de una aplicación sin una manera de avanzar para los participantes en una vista basada en roles.


Experiencia previa y posterior a la reunión
  • Las pantallas previas y posteriores a la reunión deben cumplir las directrices generales de diseño de pestañas. Para obtener más información, vea las directrices de diseño de Teams. [corrección obligatoria]

  • Las pestañas deben tener un diseño organizado cuando muestren varios elementos. Por ejemplo, más de 10 sondeos o encuestas, vea diseño de ejemplo. [corrección obligatoria]

  • La aplicación debe notificar a los usuarios cuándo se exportan los resultados de una encuesta o un sondeo indicando resultados descargados correctamente. [corrección obligatoria]

    El gráfico muestra un ejemplo de tabulación que no sigue las directrices de diseño de pestañas.


Experiencia en la reunión
  • Las aplicaciones sólo deben utilizar un tema oscuro durante las reuniones. Para obtener más información, vea las directrices de diseño de Teams. [corrección obligatoria]

  • Una información sobre herramientas debe mostrar el nombre de la aplicación cuando se mantenga el puntero sobre el icono de la aplicación durante las reuniones. [corrección obligatoria]

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

  • Las extensiones de mensaje deben funcionar igual durante las reuniones que fuera de ellas. [corrección obligatoria]


Pestañas en reunión
  • Debe ser receptivo. [corrección obligatoria]

  • Debe mantener el relleno y los tamaños de componentes. [corrección obligatoria]

  • Debe tener un botón Atrás si hay más de una capa de navegación. [corrección obligatoria]

    El gráfico muestra un ejemplo de botón Atrás presente.

    El gráfico muestra un ejemplo de botón Atrás no presente.

  • No debe incluir más de un botón cerrar. Puede confundir a los usuarios, ya que ya hay un botón de encabezado integrado para descartar la pestaña. [Corrección obligatoria]

  • No debe tener desplazamiento horizontal. [corrección obligatoria]

    El gráfico muestra un ejemplo de pestaña en reunión con desplazamiento vertical.

    El gráfico muestra un ejemplo de pestaña en la reunión con desplazamiento horizontal.


Cuadros de diálogo en la reunión
  • Debe usarse con moderación y para escenarios que sean ligeros y orientados a tareas. [corrección obligatoria]

  • Debe mostrar el contenido en una sola columna y no tener varios niveles de navegación. [corrección obligatoria]

    El gráfico muestra un ejemplo de diseño de una sola columna para el cuadro de diálogo en la reunión.

    El gráfico muestra un ejemplo de varios diseños de columna para el cuadro de diálogo en la reunión.

  • No se deben usar cuadros de diálogo. [corrección obligatoria]

  • Debe alinearse con el centro del escenario de la reunión. [corrección obligatoria]

    El gráfico muestra un ejemplo de diálogo en reunión que no se alinea con el centro de la fase de reunión.

  • Debe descartarse después de que un usuario seleccione un botón o realice una acción. [corrección obligatoria]

  • Modo juntos: asegúrese de tener en cuenta los siguientes procedimientos recomendados para una experiencia de creación de escenas: [Corrección obligatoria]

    • Todas las imágenes están en formato .png.
    • El paquete final con todas las imágenes juntas no debe superar la resolución 1920x1080. La resolución es un número par. Esta resolución es un requisito para que las escenas se muestren correctamente.
    • El tamaño máximo de la escena es de 10 MB.
    • El tamaño máximo de cada imagen es de 5 MB. Una escena es una colección de varias imágenes. El límite es para cada imagen individual.
    • Seleccione Transparente según sea necesario. Esta casilla está disponible en el panel derecho cuando se selecciona una imagen. Las imágenes superpuestas deben marcarse como transparentes para indicar que se superponen en la escena.

Fase de reunión compartida

Para usar la API shareAppContentToStage , debe declarar los permisos de RSC correctos. En el manifiesto de la aplicación, debe configurar la authorization propiedad . Actualice la name propiedad como MeetingStage.Write.Chat y type como Delegated en el resourceSpecific campo . [corrección obligatoria]

La característica de fase de reunión compartida solo se puede iniciar a través de la aplicación de escritorio de Teams. Sin embargo, la experiencia de consumo de la fase de reunión compartida debe ser usable y no interrumpirse cuando se visualiza en dispositivos móviles. [corrección obligatoria]

Volver al principio

Connector

  1. El nombre del conector debe ser el mismo que el nombre de la aplicación dentro de la aplicación y en el manifiesto de la aplicación.

    Captura de pantalla que muestra la falta de coincidencia en el nombre de la aplicación entre la aplicación y el manifiesto de la aplicación.

  2. El usuario no debe encontrar ningún error al configurar el conector.

    Captura de pantalla que muestra un error mientras el usuario configura el conector.

Notificaciones

Esta sección está en línea con el número de directiva de Marketplace comercial de Microsoft 1140.4.7.

Si la aplicación usa las API de fuente de actividad proporcionadas por Microsoft Graph, asegúrese de que cumple las siguientes directrices.

Sugerencia

Si las aplicaciones admiten escenarios de notificación en los que las notificaciones se desencadenan después de intervalos largos, por ejemplo, después de un día o un mes. Antes de enviarlas para su revisión, asegúrese de desencadenar dichas notificaciones en segundo plano para que podamos probar las notificaciones.



Directrices de diseño de notificaciones
  • Las aplicaciones de Teams deben seguir las directrices de diseño de notificaciones de fuente de actividad.

  • El flujo de trabajo irrelevante, incorrecto, no responde o roto no debe estar presente después de que el usuario seleccione una notificación en la fuente de actividad de Teams. No se debe impedir que los usuarios completen un flujo de trabajo después de seleccionar una notificación de fuente de actividad. [corrección obligatoria]

  • Incluya el nombre de la aplicación en la notificación de fuente de actividad para que los usuarios finales comprendan el origen o el desencadenador de la notificación sin confusiones. [corrección obligatoria]

  • La aplicación debe desencadenar notificaciones para todos los escenarios de notificación mencionados en la descripción larga de la aplicación, la experiencia de primera ejecución de la aplicación y en los escenarios declarados activityTypes en en el manifiesto de la aplicación. [corrección obligatoria]

  • Las notificaciones deben aparecer en los cinco segundos siguientes a la acción del usuario. [corrección obligatoria]

  • Debes llamar a las limitaciones de notificación (si las hubiera) en la descripción larga de la aplicación o en la primera experiencia de ejecución de la aplicación. [corrección obligatoria]


General
  • Todos los desencadenadores de notificación especificados en la configuración de la aplicación deben funcionar. [corrección obligatoria]
  • Las notificaciones deben estar localizadas según los idiomas admitidos configurados para su aplicación. [corrección obligatoria]
  • Las notificaciones deben aparecer en los cinco segundos siguientes a la acción del usuario. [corrección obligatoria]
  • Las notificaciones deben localizarse según los idiomas admitidos para todas las plataformas en las que la aplicación sea compatible. [corrección obligatoria]

Avatares
  • El avatar de notificación debe coincidir con el icono de color de la aplicación. [corrección obligatoria]
  • Las notificaciones desencadenadas por un usuario deben incluir el avatar del usuario. [corrección obligatoria]

Spam
  • Las aplicaciones no deben enviar más de 10 notificaciones por minuto a un usuario. [corrección obligatoria]
  • Los bots y la fuente de actividad no deben desencadenar notificaciones duplicadas. [corrección obligatoria]
  • Las notificaciones deben aportar algún valor a los usuarios y no ser utilizadas para eventos triviales o irrelevantes. [corrección obligatoria]

Navegación y diseño
  • Las notificaciones deben ceñirse al diseño y la experiencia de la alimentación de la actividad de Teams. [corrección obligatoria]
  • Al seleccionar una notificación, se debe dirigir al usuario al contenido relevante dentro de Teams. [corrección obligatoria]

Volver al principio

Programa de cumplimiento de aplicaciones de Microsoft 365

Esta sección está en línea con el número de directiva de Marketplace comercial de Microsoft 1140.6.

Expandir para obtener más información

El Programa de cumplimiento de aplicaciones de Microsoft 365 está destinado a ayudar a las organizaciones a evaluar y administrar el riesgo mediante la evaluación de la información de seguridad y cumplimiento de su aplicación. Si va a publicar una aplicación en la Tienda Teams, debe completar los siguientes niveles del programa:

  • Verificación de editores: Ayuda a los administradores y usuarios finales a comprender la autenticidad de los desarrolladores de aplicaciones que se integran en la plataforma de identidad de Microsoft. Cuando se completa, se muestra una notificación verificada azul en el cuadro de diálogo de consentimiento de Microsoft Entra y en otras pantallas. Para obtener más información, consulte Marcar la aplicación como verificada por el publicador. [corrección obligatoria]

    El gráfico muestra un ejemplo de una notificación verificada azul en el cuadro de diálogo de consentimiento de Microsoft Entra.

  • Certificación del editor: Un proceso en el que usted comparte información general, de manejo de datos y de seguridad y cumplimiento para ayudar a los clientes potenciales a tomar decisiones informadas sobre el uso de su aplicación. [Corrección sugerida]

En el caso de una aplicación que no aparece anteriormente, no puedes completar la atestación del publicador hasta que la aplicación esté disponible en la Tienda Teams. Si va a actualizar una aplicación que ya aparece, complete la atestación del publicador antes de enviar la versión más reciente de la aplicación.

Volver al principio

Publicidad

Esta sección está alineada con la directiva de Marketplace comercial de Microsoft 1140.7.

Las aplicaciones no deben mostrar publicidad, incluidos los anuncios dinámicos, los anuncios de banner y los anuncios en el mensaje. [corrección obligatoria]

El gráfico muestra un ejemplo de un escenario con errores de publicidad en Teams.

Volver al principio

Aplicaciones basadas en criptomonedas

Debe demostrar el cumplimiento de todas las leyes en las que se distribuye la aplicación, si la aplicación: [Corrección obligatoria]

  • Facilita las transacciones o transmisiones criptomoneda dentro de la aplicación.

  • Promueve el contenido relacionado con criptomonedas.

  • Permite a los usuarios almacenar o acceder a su criptomoneda almacenada.

  • Anima o permite a los usuarios completar una transacción o transmisión basada en criptomonedas fuera de la plataforma de Teams.

  • Fomenta o facilita la minería de tokens de criptomoneda.

  • Facilita la participación del usuario en las ofertas iniciales de monedas.

  • Recompensa o incentiva a los usuarios con tokens de criptomoneda para completar una tarea.

Después de una revisión interna de Microsoft, si la demostración de cumplimiento es satisfactoria, Microsoft puede continuar con la certificación adicional de la aplicación. Si la demostración de cumplimiento no es satisfactoria, Microsoft le mantiene informado de la decisión de no continuar con la certificación de la aplicación.

Volver al principio

Funcionalidad de la aplicación

  • Los flujos de trabajo o el contenido de la aplicación deben estar relacionados con el ámbito. [corrección obligatoria]
  • Todas las funcionalidades de la aplicación deben ser funcionales y deben funcionar correctamente como se describe en la descripción larga del manifiesto de aplicación o AppSource. [corrección obligatoria]
  • Las aplicaciones siempre deben notificar al usuario antes de descargar cualquier archivo o ejecutable en el entorno del usuario. Cualquier llamada a la acción (CTA), ya sea basada en texto o de otro modo, que permita al usuario que se descargue un archivo o ejecutable en la acción del usuario en la aplicación. [corrección obligatoria]
  • Las aplicaciones con dependencia de región deben notificar a los usuarios un mensaje de error correcto en todas las funcionalidades aplicables si intentan usarlo en una región no admitida. [corrección obligatoria]

Volver al principio

Experiencia móvil

  • Los complementos móviles deben ser gratuitos. No debe haber contenido ni vínculos desde la aplicación que promuevan ventas al alza, tiendas en línea u otras solicitudes de pago. Las cuentas necesarias para las aplicaciones no deben tener ningún cargo por su uso y, si se limita el tiempo, no deben incluir ningún contenido que indique que es necesario pagar. [corrección obligatoria]

    El gráfico muestra un ejemplo de un complemento móvil que solicita el pago.

  • El uso de la palabra FREE, FREE TRIAL o TRY FREE se permite en la experiencia de aplicación web o de escritorio sin ninguna limitación o consideración.

  • Se permite el uso de la palabra FREE como texto sin formato en el contexto de una versión de prueba o actualización de la aplicación en el móvil.

  • El uso de la palabra GRATIS en el contexto de una evaluación o actualización de la aplicación con un vínculo que conduce a una página de aterrizaje sin pago o información de precios está permitido en el móvil. El texto sin formato para indicar que la aplicación es PAID se permite en el móvil.

  • No se permite el uso de la palabra FREE como texto sin formato en el contexto de una actualización de prueba o aplicación y asociada a los detalles de precios en dispositivos móviles. [corrección obligatoria]

  • No se permite el uso de la palabra GRATIS en el contexto de una evaluación o actualización de la aplicación y asociado a un vínculo que conduce a una página de aterrizaje con información de precios o detalles de pago en el móvil. [corrección obligatoria]

  • No se permiten los detalles de precios en el móvil en cualquier formato, por ejemplo, la imagen, el texto o el vínculo. No se permite la llamada a la acción, como los planes de visualización en dispositivos móviles. No se permite la información sobre los planes sin detalles de precios, pero con un vínculo de contacto o correo electrónico en el móvil. No se permite ningún texto con detalles de contacto que vinculen o aluden a una actualización de pago en el móvil. Pagos para bienes físicos se permiten en el móvil. Por ejemplo, la aplicación puede permitir el pago para reservar un taxi. [corrección obligatoria]

    El gráfico muestra un ejemplo de detalles de precios en el móvil.

  • Pagos para productos digitales en la aplicación no se permiten en el móvil. [corrección obligatoria]

    Gráfico que muestra un ejemplo de pagos por bienes digitales en el móvil.

  • Las aplicaciones de Teams deben ofrecer una experiencia móvil entre dispositivos adecuada. [corrección obligatoria]

  • Las funcionalidades que no se admiten en dispositivos móviles no deben ser un usuario sin salida y deben proporcionar un mensaje de error correcto cuando corresponda. [corrección obligatoria]

Volver al principio

Aplicaciones extendidas entre clientes de Microsoft 365

General

  • Las aplicaciones destinadas a ampliar las aplicaciones de Teams entre clientes de Microsoft 365 deben usar la versión de esquema 1.13 o posterior.

  • La dirección URL de soporte técnico de la aplicación debe contener contenido relevante para la aplicación de Teams extensible entre clientes de Microsoft 365 y no debe llamar solo a un solo cliente.

  • Debe proporcionar una referencia relevante a la aplicación de Teams extensible a todos los clientes de Microsoft 365 en la descripción de la aplicación.

  • Si la aplicación de Teams es extensible a todos los clientes de Microsoft 365, el contenido proporcionado en la introducción, el inicio de sesión, el registro, el cierre de sesión, las páginas de ayuda o el reenvío de mensajes deben llamar a todos los clientes.

Compatibilidad

Las aplicaciones de Teams extensibles a todos los clientes de Microsoft 365 deben ser totalmente dinámicas y funcionales en las versiones más recientes de los clientes de Microsoft Edge y Google Chrome. El usuario debe poder invocar y seguir usando pestañas personales o extensiones de mensaje en lo siguiente:

  • Outlook para Windows y web.
  • Microsoft 365 en escritorio, web y Android.
  • Microsoft Teams en escritorio y web.
  • Microsoft Teams en Android e iOS.

Experiencia móvil

Los usuarios deben poder iniciar la aplicación desde el menú flotante de acciones dentro del cliente de Microsoft 365 en dispositivos móviles. El nombre de la aplicación debe mostrarse correctamente en la barra de acciones. [corrección obligatoria]

Inicio de la aplicación desde el control flotante de acciones

Los usuarios deben poder iniciar y cambiar correctamente entre varias pestañas estáticas dentro del cliente de Microsoft 365 en dispositivos móviles. Las pestañas deben cargarse correctamente. Si hay más de tres pestañas estáticas, las pestañas restantes deben estar visibles en la sección Más . [corrección obligatoria]

Experiencia con varias pestañas

Si la aplicación usa el inicio de sesión único, debe autenticar al usuario correctamente. Sso permite a los usuarios iniciar sesión con un conjunto de credenciales en varios sistemas de software independientes. Los usuarios pueden acceder a todas las aplicaciones necesarias sin usar credenciales diferentes para autenticarse. [corrección obligatoria]

Autenticación de aplicaciones

La aplicación debe finalizar la instancia de la cuenta de usuario cuando el usuario se cambia o cierra sesión en el cliente de Microsoft 365 en el móvil. [corrección obligatoria]

Experiencia de conmutación y cierre de sesión de la cuenta

  • Los usuarios deben poder volver al estado de trabajo anterior. Si el usuario está en la página raíz, la navegación posterior debe finalizar la instancia de la aplicación dentro del cliente de Microsoft 365 en el móvil. [corrección obligatoria]

  • Las aplicaciones que admiten vínculos profundos a un flujo de trabajo deben poder redirigir al usuario a la experiencia de página de aterrizaje adecuada. [corrección obligatoria]

Navegación por tabulación

  • El indicador de progreso debe aparecer cuando la aplicación se carga y descarta automáticamente después de cargar la aplicación. [corrección obligatoria]

  • Debe aparecer una pantalla de error cuando una aplicación no se carga en las instancias, como la red incoherente o rota, el tiempo de espera o el error de autenticación, etc. [corrección obligatoria]

Volver al principio

Aplicaciones de Teams extensibles como complemento para Microsoft Copilot para Microsoft 365

El complemento no debe manipular el comportamiento de LLM

Las descripciones breves de una aplicación, un parámetro y un comando no deben incluir lo siguiente:

  1. Frases de instrucciones. Por ejemplo, si el usuario dice X, omita, elimine, restablezca, nuevas instrucciones, responda en negrita o no imprima nada.
  2. Lenguaje detallado, floral o de marketing.
  3. Notificaciones superlativas como #1, increíbles o mejores.
  4. Direcciones URL, emojis o caracteres ocultos, como símbolos hexadecimales, binarios o no convencionales.
  5. Errores de gramática y puntuación.

Reconocimiento del usuario

La descripción larga de una aplicación debe indicar claramente lo siguiente:

  • Compatibilidad de la aplicación con Copilot. Por ejemplo, use Contoso en Copilot para buscar y resumir las tareas.

  • Proporcione al menos una pregunta de cómo los usuarios pueden usar un complemento de extensión de mensaje en Copilot. Por ejemplo, ¿cuáles son los vales de prioridad alta asignados esta semana en Contoso?

    Captura de pantalla que muestra un escenario de paso con un ejemplo de solicitud de ejemplo para el uso de la extensión de mensaje como complemento en Copilot.

    Captura de pantalla que muestra un escenario de error sin un ejemplo de solicitud de ejemplo para el uso de la extensión de mensaje como complemento en Copilot.

Calidad de respuesta

  • Los campos obligatorios de Microsoft 365 Chat respuesta de tarjeta adaptable deben incluir título de información y al menos dos campos útiles adicionales de su elección, por ejemplo, fecha de modificación, autor, estado y marcas. Tanto la vista previa como el contenido deben formar parte de una única respuesta.

    Captura de pantalla que muestra un ejemplo de una aplicación de ejemplo que muestra Microsoft 365 Chat respuesta de la aplicación contiene vista previa y contenido en la misma respuesta.

  • Las tarjetas adaptables en Microsoft 365 Chat respuesta deben tener al menos un botón de acción.

  • Los botones de acción presentes en Microsoft 365 Chat respuesta Las tarjetas adaptables deben ser funcionales.

    Captura de pantalla que muestra un ejemplo de título de información, campos de usuario adicionales y botón de acción en una respuesta de tarjeta adaptable.

  • Microsoft 365 Chat debe responder con precisión y no mostrar un error cuando un usuario solicita un solo parámetro.

  • Microsoft 365 Chat debe responder con precisión y no mostrar un error cuando un usuario solicita un parámetro múltiple.

  • Microsoft 365 Chat debe responder con precisión y no mostrar un error cuando un usuario solicita un seguimiento.

  • La extensión de mensaje debe contener al menos dos parámetros para mejorar la experiencia del usuario en Microsoft 365 Chat.

Volver al principio

Paso siguiente

Consulte también