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.
• Ciertas directrices se marcan como Debe corregirse. 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 pasa la validación de la Tienda Teams solo después de haber corregido los problemas.
• Otras directrices se marcan como Correcto para corregir. Para una experiencia de usuario ideal, te recomendamos que corrijas los problemas; sin embargo, el envío de la aplicación no está bloqueado para publicar 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. [Se debe corregir]

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.

Extensiones de mensaje

[Se debe corregir]

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.

   

   

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

[Se debe corregir]

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. [Se debe corregir]

• Nombres comunes con prefijos o sufijos con el nombre del desarrollador. Por ejemplo, Contoso Tasks en lugar de Tasks. [Se debe corregir]

• 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. [Se debe corregir]

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

• No debe contener términos profanos o despectivos. El nombre tampoco debe incluir lenguaje racial o culturalmente insensible. [Se debe corregir]

• 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. [Se debe corregir]
  • 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 . [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• No use paréntesis en la nomenclatura para incluir productos de Microsoft. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

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

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. [Se debe corregir]

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

  

  • 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

[Se debe corregir]

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. [Se debe corregir]

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. [Se debe corregir]

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. [Se debe corregir]

Plataformas y servicios similares

[Se debe corregir]

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

[Se debe corregir]

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. [Se debe corregir]
  • Cuando los usuarios cierran la sesión, deben cerrar sesión solo desde la aplicación y seguir con sesión iniciada en Teams. [Se debe corregir]
  • 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). [Se debe corregir]
  • 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Buena solución]

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

[Se debe corregir]

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. [Se debe corregir]

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. [Se debe corregir]

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. [Se debe corregir]

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. [Se debe corregir]

  

  

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

Bots

[Se debe corregir]

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.

Dominios externos

[Se debe corregir]

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. [Se debe corregir]

• No use dominios de nivel superior como .com, .in y .org como dominio válido. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

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

• No se permiten los siguientes dominios externos: [Se debe corregir]

  • *.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

[Se debe corregir]

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

[Se debe corregir]

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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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: [Se debe corregir]

  • 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

[Se debe corregir]

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

[Se debe corregir]

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. [Se debe corregir]
• Los bots deben responder a las órdenes del usuario en dos segundos o mostrar un indicador de escritura. [Se debe corregir]
• Las extensiones de mensaje deben responder a los comandos de usuario en dos segundos. [Se debe corregir]
• Las notificaciones deben mostrarse en los dos segundos siguientes a la acción del usuario. [Se debe corregir]

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. [Se debe corregir]

  • 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. [Buena solución]
    • 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. [Buena solución]
    • Agregue la funcionalidad de barrido de conversaciones, que le ayuda a supervisar las conversaciones e intervenir cuando las conversaciones se desatraen. [Buena solución]

• La aplicación debe proporcionar mecanismos para que los usuarios de la aplicación informen de contenido inadecuado, dañino o ofensivo al desarrollador mediante cualquiera de los siguientes mecanismos: [Debe corregir]

  • 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. [Se debe corregir]

• 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. [Se debe corregir].

  

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. [Se debe corregir]
• 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. [Se debe corregir]
  • 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

[Se debe corregir]

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.

Volver al principio

Manifiesto de la aplicación

[Se debe corregir]

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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• La presencia de archivos adicionales en el paquete de la aplicación no es aceptable. [Se debe corregir]

• 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. [Se debe corregir]

• 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). [Se debe corregir]

• 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. [Se debe corregir]

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

• 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 ... [Se debe corregir]

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

• Se recomienda declarar el identificador del programa de partners en la nube de Microsoft (id. de CCP), anteriormente conocido como Microsoft Partner Network (ID de MPN) en el manifiesto de la aplicación. El identificador de CCP ayuda a identificar la organización asociada que compila la aplicación. [Buena solución]

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

Iconos de la aplicación

[Se debe corregir]

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. [Se debe corregir]

  

  

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

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.

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. [Se debe corregir]

  

• Detalles de contacto de hipervínculo, introducción, ayuda o registro en la descripción de la aplicación. [Buena solució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. [Se debe corregir]

• 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. [Se debe corregir]

• 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

  

  

• 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. [Se debe corregir]

  

  

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:

[Buena solución]

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:

[Se debe corregir]

• Superar las 500 palabras.

• Abreviar Microsoft como MS o MSFT.

  

  

• Indicar que la aplicación es una oferta de Microsoft, incluyendo el uso de eslóganes o 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.

  

  

• Incluir vínculos a AppSource.

  

• 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. [Se debe corregir]

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

  

• 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. [Se debe corregir]

• 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. [Se debe corregir]

  

  

• Debe representar la funcionalidad de la aplicación o la integración con Teams. [Se debe corregir]

  

• Las capturas de pantalla proporcionadas no deben hacer referencia incorrectamente a Microsoft Teams como MS, MSFT o MS Teams. [Se debe corregir]

• 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. [Se debe corregir]

  

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

  

• 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. [Se debe corregir]

  

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.

  

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. [Buena solución]

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. [Buena solución]

• 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. [Se debe corregir]

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

• El vídeo debe estar disponible como un vínculo funcional. [Se debe corregir]

• El vídeo debe tener el formato https://www.youtube.com/watch?v=:id o https://youtu.be/:id para YouTube y https://vimeo.com/:id Vimeo.

  

• 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. [Buena solución]

• 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

[Se debe corregir]

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

[Se debe corregir]

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.

Vínculos de soporte técnico

[Se debe corregir]

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.

Localización

[Se debe corregir]

• 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. [Se debe corregir]

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

• 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). [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

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. [Se debe corregir]

  

• 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. [Se debe corregir]

  

• 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. [Se debe corregir]

  

  

• 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. [Se debe corregir]

  • 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. [Se debe corregir]

    

    

• 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. [Se debe corregir]

• 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. [Buena solución]

Vistas

• El área de pantalla de inicio de sesión no debe usar logotipos grandes. [Se debe corregir]

  

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

  

• 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. [Buena solución]

  

  

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. [Se debe corregir]

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

  

  

• 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. [Se debe corregir]

  

• 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

    

• 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. [Se debe corregir]

  

• 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. [Se debe corregir]

  

  

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

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

  

  

  

  

  

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

  

  

• El desplazamiento horizontal en tarjetas adaptables no debe estar presente en Teams. [Se debe corregir]

• 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. [Se debe corregir]

  

Usabilidad

• El contenido no debe truncarse ni superponerse dentro de la pestaña. [Debe corregirse]

  

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

• 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. [Buena solución]

• 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. [Buena solución]

  

  

• 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. [Buena solución]

  

• Si la funcionalidad de la aplicación requiere cambios en la configuración, incluya una pestaña Configuración . [Correcto para corregir]

• 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. [Buena solución]

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

  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. [Se debe corregir]

  

• 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. [Se debe corregir]

• 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. [Se debe corregir]

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. [Se debe corregir]

  

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

• 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. [Se debe corregir]

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

  

• Las pestañas configurables deben tener una funcionalidad centrada. [Se debe corregir]

  

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, la fecha de nacimiento, el lugar y la designación en lugar de usar conversaciones de varios turnos. [Se debe corregir]

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

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. [Se debe corregir]

  

  

• Los comandos de bot no deben llevar a un usuario a un punto muerto; los comandos siempre deben proporcionar una manera de avanzar. [Se debe corregir]

  

• 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. [Buena solución]

• 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. [Se debe corregir]

• Los bots deben responder a los comandos del usuario sin mostrar un indicador de carga continua. [Se debe corregir]

• 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. [Se debe corregir]

  

• Los bots siempre deben proporcionar una respuesta válida a una entrada del usuario, incluso si la entrada es irrelevante o incorrecta. [Se debe corregir]

  

  

• Los caracteres especiales, como la barra diagonal (/), no deben ir precedidos de comandos de bot. [Se debe corregir]

  

• 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. [Se debe corregir]

  

  

• 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. [Se debe corregir]

• Los bots no deben contener comandos duplicados. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

  

  

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

  

• 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. [Se debe corregir]

  

  

• 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. [Se debe corregir]

  

• 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. [Se debe corregir]

  

  

• 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. [Se debe corregir]

Sugerencia

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

Experiencia de usuario de la primera ejecución del bot

• Un bot en el ámbito personal siempre debe enviar un mensaje de bienvenida o proporcionar inicios de aviso. [Se debe corregir]

  Si usa los inicios de aviso, asegúrese de que se cumplen las siguientes directrices:

  Los inicios de aviso ayudan a los usuarios a iniciar una conversación con el bot. Para habilitar los inicios de mensajes, es necesario definir la propiedad en el commands manifiesto de la aplicación.

  • El bot debe proporcionar al menos un comando que permita al usuario conocer la propuesta de valor de la aplicación. [Se debe corregir]
  • Los inicios o comandos de aviso deben ser funcionales y devolver respuestas. [Se debe corregir]
  • La descripción del comando debe ser coherente y comunicar claramente el valor del comando. [Se debe corregir]
  • Los inicios de mensajes o los comandos deben ser relevantes para la funcionalidad de la aplicación. [Se debe corregir]
  • El bot debe tener al menos tres comandos o inicios de aviso únicos. [Buena solución]

  Si la aplicación envía un mensaje de bienvenida, asegúrese de que se cumplen las siguientes directrices:

  • Si la aplicación tiene un flujo de configuración complejo (requiere una licencia empresarial o carece de un flujo de registro intuitivo), los bots de estas aplicaciones siempre deben incluir información relacionada con la configuración al 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.

    

    

• 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.

  

  

• 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. [Se debe corregir]

  

  

• 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. [Se debe corregir]

  

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• El mensaje de bienvenida del bot debe indicar claramente las limitaciones relacionadas con el uso del bot en el ámbito instalado. [Se debe corregir]

  

  

• 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. [Se debe corregir]

  

• 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. [Se debe corregir]

• Los mensajes de bienvenida no deben desencadenarse con todos los comandos del bot. Esto se considera spam. [Se debe corregir]

  

• 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. [Se debe corregir]

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

  

• 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. [Se debe corregir]

  

• 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. [Se debe corregir]

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

• 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. [Se debe corregir]

• 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. [Buena solución]

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. [Se debe corregir]

  

  

• mensajes de bot en aplicaciones personales:

  • No envíe varios mensajes en sucesión rápida. [Se debe corregir]

    

  • Envíe un mensaje con la información completa. [Se debe corregir]

  • Evite las conversaciones de varios turnos para completar un único flujo de trabajo repetitivo. [Se debe corregir]

  • Use un formulario (o cuadro de diálogo) para recopilar todas las entradas de un usuario a la vez. [Se debe corregir]

  • 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.

    

    

• 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. [Se debe corregir]

  

Notificaciones de bot

Las notificaciones del bot deben incluir contenido relevante para el ámbito que se defina para el bot (equipo, chat o personal). [Se debe corregir]

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:

• Diseño de tarjetas adaptables
• Referencia de tarjetas

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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

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. [Se debe corregir]

• 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. [Se debe corregir]

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

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.

  

• 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. [Se debe corregir]

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

  

  

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

• 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. [Se debe corregir]

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

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

• 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.

  

  

• Pasar el contexto del mensaje al siguiente estado de trabajo. [Se debe corregir]

  

  

• 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. [Buena solució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. [Se debe corregir]

  

• Los comandos de acción duplicados no deben estar presentes. [Se debe corregir]

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

• 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. [Se debe corregir]

  • 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. [Se debe corregir]

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

[Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Debe corregir]

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. [Se debe corregir]

  

  

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

  

Volver al principio

Diálogos

[Se debe corregir]

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.

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. [Se debe corregir]

• 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. [Se debe corregir]

  • 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.

  

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

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

  

• 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 siempre deben abrirse dentro de la instancia activa de Teams. [Se debe corregir]

• 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. [Se debe corregir]

  

• 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. [Se debe corregir]

  

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. [Se debe corregir]

• 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. [Se debe corregir]

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

  

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. [Se debe corregir]

• 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. [Se debe corregir]

  

• Las extensiones de mensaje deben funcionar igual durante las reuniones que fuera de ellas. [Se debe corregir]

Pestañas en reunión

• Debe ser receptivo. [Se debe corregir]

• Debe mantener el relleno y los tamaños de componentes. [Se debe corregir]

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

  

  

• 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. [Se debe corregir]

• No debe tener desplazamiento horizontal. [Se debe corregir]

  

  

Cuadros de diálogo en la reunión

• Debe usarse con moderación y para escenarios que sean ligeros y orientados a tareas. [Se debe corregir]

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

  

  

• No se deben usar cuadros de diálogo. [Se debe corregir]

• Debe alinearse con el centro del escenario de la reunión. [Se debe corregir]

  

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

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

  • 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 . [Se debe corregir]

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. [Se debe corregir]

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.

   

2. El usuario no debe encontrar ningún error al configurar 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

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

• 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. [Se debe corregir]

General

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

Avatares

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

Spamming

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

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. [Se debe corregir]
• Al seleccionar una notificación, se debe dirigir al usuario al contenido relevante dentro de Teams. [Se debe corregir]

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. [Se debe corregir]

  

• 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. [Buena solución]

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. [Se debe corregir]

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: [Debe corregir]

• 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. [Se debe corregir]
• 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. [Se debe corregir]
• 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. [Se debe corregir]
• 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. [Se debe corregir]

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. [Se debe corregir]

  

• 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. [Se debe corregir]

• 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. [Se debe corregir]

• 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. [Se debe corregir]

  

• Pagos para productos digitales en la aplicación no se permiten en el móvil. [Se debe corregir]

  

• Las aplicaciones de Teams deben ofrecer una experiencia móvil entre dispositivos adecuada. [Se debe corregir]

• 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. [Se debe corregir]

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. [Se debe corregir]

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 . [Se debe corregir]

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. [Se debe corregir]

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. [Se debe corregir]

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. [Se debe corregir]

• 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. [Se debe corregir]

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. [Se debe corregir]

• 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. [Se debe corregir]

Volver al principio

Aplicaciones de Teams extensibles como agentes para Microsoft 365 Copilot

• Los paquetes de aplicaciones tienen el formato correcto y se adhieren a la versión 1.13 o posterior del esquema de manifiesto.
• La aplicación debe pasar las comprobaciones de IA responsables.
• La aplicación debe cumplir los criterios compatibles con el agente.

El agente 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 Microsoft 365 Copilot. Por ejemplo, use Contoso en Microsoft 365 Copilot para buscar y resumir las tareas.

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

  

  

Calidad de respuesta

• Los campos obligatorios de Microsoft 365 Copilot 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.

  

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

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

  

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

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

• Microsoft 365 Copilot 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 Copilot.

Volver al principio

Paso siguiente

Crear una cuenta del Centro de partners

Consulte también

• Prueba y depuración de la aplicación
• Preparación del envío de la Tienda Teams
• Incluir una oferta de SaaS con la aplicación de Teams
• Crear estrategias y ejecutar el crecimiento de la aplicación
• Validación de la aplicación en el Portal para desarrolladores para Teams