Directrices de validación de la tienda de Teams

Las pestañas deben proporcionar valor añadido más allá de hospedar un sitio web ya existente. [Se debe corregir]

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.

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

   

   

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.

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]

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]

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.

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]

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.

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.

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

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.

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.

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.

  

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.

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

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

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

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

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.

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

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

  

  

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]

  

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

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

  

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

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]

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

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]

  

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

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

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.

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

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

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

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]

[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]

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

  

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.

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

  

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

  

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

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

  

  

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

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]

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

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

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

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

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

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.