Diretrizes de validação da Teams Store

Seguir essas diretrizes aumenta as chances de seu aplicativo passar pelo processo de envio da Microsoft Teams Store. As diretrizes específicas do Teams complementam as políticas de certificação do marketplace comercial da Microsoft e são atualizadas com frequência para refletir novos recursos, comentários do usuário e alterações nas regras de negócios.

Observação

• É possível que algumas diretrizes não sejam pertinentes ao seu aplicativo. Por exemplo, se seu aplicativo não incluir um bot, você poderá ignorar as diretrizes relacionadas ao bot.
• Cruzamos essas diretrizes com as políticas de certificação comercial da Microsoft e adicionamos o que fazer e o que não fazer com exemplos de cenários de aprovação ou reprovação encontrados em nosso processo de validação.
• Determinadas diretrizes são marcadas como Correção Obrigatória. Se o envio do aplicativo não atender a essas diretrizes obrigatórias, você receberá um relatório de falha conosco com etapas para atenuar. O envio do aplicativo passará pela validação do Teams Store somente depois que você tiver corrigido os problemas.
• Outras diretrizes são marcadas como Correção Sugerida. Para uma experiência ideal do usuário, sugerimos que você corrija os problemas, no entanto, seu envio de aplicativo não será impedido de publicar na Teams Store, se você optar por não corrigir os problemas.

Proposta de valor

Esta seção está em linha com a política de certificação comercial da Microsoft número 1140.1 e fornece mais diretrizes aos desenvolvedores de aplicativos do Microsoft Teams sobre a proposta de valor de sua oferta.

Os aplicativos devem fornecer valor aos usuários, permitindo que eles concluam fluxos de trabalho funcionais que incentivam o uso repetido. Expanda as seções a seguir para saber mais sobre a proposta de valor:

Guias

As guias devem fornecer valor além de hospedar um site existente. [Correção Obrigatória]

Bots de notificação

Uma notificação fornece valor no Teams se:

1. O cartão ou o texto postado fornece detalhes adequados que não exigem mais nenhuma ação do usuário.
2. O cartão ou texto postado fornece informações de visualização adequadas para que um usuário execute uma ação ou decida exibir mais detalhes em um link aberto fora do Teams.

Aplicativos que fornecem apenas notificações com conteúdo como, você tem uma nova notificação ou clique para exibir e exige que o usuário navegue fora do Teams para que tudo o resto não forneça um valor significativo no Teams.

Extensões de mensagem

[Correção Obrigatória]

Os aplicativos que consistem na extensão de mensagens baseada em pesquisa fornecem valor ao usuário compartilhando cartões que permitem conversas contextuais sem alternância de contexto.

Para passar a validação para um aplicativo somente de extensão de mensagem baseado em pesquisa, o seguinte é necessário como linha de base para garantir que a experiência do usuário não esteja quebrada. Um cartão compartilhado por meio de uma extensão de mensagens fornecerá valor no Teams se:

1. O cartão postado fornece detalhes adequados que não exigem mais nenhuma ação do usuário.

2. O cartão postado fornece informações de visualização adequadas para um usuário executar uma ação ou decidir exibir mais detalhes em um link que abre fora do Teams.

   

   

Desenrolamento de link

Os aplicativos de desbloqueio de links não fornecem um valor significativo para as equipes. Considere criar mais fluxos de trabalho em seu aplicativo, se seu aplicativo só dá suporte à desenrolação de link e não tem outra funcionalidade.

Voltar para o início

Nome do aplicativo

[Correção Obrigatória]

Esta seção está em linha com a política de certificação comercial da Microsoft número 1140.1.1 e fornece mais diretrizes aos desenvolvedores sobre como nomear seus aplicativos.

Expandir para saber mais

O nome de um aplicativo desempenha um papel crítico na forma como os usuários o descobrem na Teams Store. Use as seguintes diretrizes para nomear um aplicativo:

• O nome deve incluir termos relevantes aos seus usuários. [Correção Obrigatória]

• Prefixo ou sufixo substantivos comuns com o nome do desenvolvedor. Por exemplo, Tarefas da Contoso em vez de Tarefas. [Correção Obrigatória]

• Não deve usar o Teams ou outros nomes de produtos da Microsoft, como Excel, PowerPoint, Word, OneDrive, SharePoint, OneNote, Azure, Surface e Xbox que possam indicar falsamente co-branding ou co-venda. Para obter mais informações sobre como fazer referência a produtos e serviços de software da Microsoft, confira Marca Registrada e Diretrizes da Marca Microsoft. [Correção Obrigatória]

• Não é necessário copiar o nome de um aplicativo listado na Teams Store ou outra oferta no marketplace comercial. [Correção Obrigatória]

• Não deve conter termos profanos ou depreciativos. O nome também não deve incluir linguagem racial ou culturalmente insensível. [Correção Obrigatória]

• Deve ser exclusivo. Se seu aplicativo (Contoso) estiver listado na Teams Store e no Microsoft AppSource e você quiser listar outro aplicativo específico para uma geografia como Contoso México, seu envio deverá atender aos seguintes critérios:

  • Chame a funcionalidade específica da região do aplicativo no título, metadados, experiência do aplicativo de primeira resposta e seções de ajuda. Por exemplo, o título deve ser Contoso México. O título do aplicativo deve diferenciar claramente um aplicativo existente do mesmo desenvolvedor para evitar confusão para o usuário final. [Correção Obrigatória]
  • Ao carregar o pacote de aplicativos no Partner Center, selecione os Mercados certos em que o aplicativo está disponível na seção Disponibilidade . [Correção Obrigatória]

• O nome do aplicativo não deve liderar com um recurso principal do Teams, como Chat, Contatos, Calendário, Chamadas, Arquivos, Atividade, Equipes e Ajuda. O nome do aplicativo não é abreviado para Chat, Contatos, Calendário, Chamadas, Arquivos, Atividade, Equipes e Ajuda na instalação na navegação à esquerda. [Correção Obrigatória]

• Se seu aplicativo faz parte de uma parceria oficial com a Microsoft, o nome do seu aplicativo deve vir primeiro. Por exemplo, conector contoso para o Microsoft Teams.

• O nome do aplicativo não deve ter nenhuma referência aos produtos Microsoft ou Microsoft. Não use o Teams ou a Microsoft, no nome do aplicativo, a menos que seu aplicativo esteja em parceria oficial com a Microsoft. Em tal instância, o nome do aplicativo deve vir primeiro antes de qualquer referência à Microsoft. Por exemplo, conector contoso para o Microsoft Teams. [Correção Obrigatória]

• Não use parênteses na nomenclatura para incluir produtos da Microsoft. [Correção Obrigatória]

• O nome do desenvolvedor deve ser o mesmo no manifesto do aplicativo (anteriormente chamado de manifesto do aplicativo teams) e no AppSource. [Correção Obrigatória]

• Os manifestos de aplicativo enviados devem ser manifestos de produção. Assim, o nome do aplicativo não deve indicar que o aplicativo é um aplicativo de pré-produção. Por exemplo, o nome do aplicativo não deve conter palavras como Beta, Desenvolvimento, Visualização e UAT. [Correção Obrigatória]

• O nome do aplicativo no manifesto do aplicativo e o AppSource devem corresponder. [Correção Obrigatória]

Dica

A identidade visual do seu aplicativo na Teams Store e no AppSource, incluindo seu nome de aplicativo, nome do desenvolvedor, ícone do aplicativo, capturas de tela do AppSource, vídeo, descrição curta e site separados ou juntos não devem representar uma oferta oficial da Microsoft, a menos que seu aplicativo seja uma oferta oficial do Microsoft 1P.

Aplicativo duplicado

• Aplicativos do mesmo desenvolvedor que oferecem a mesma funcionalidade devem compartilhar uma listagem de aplicativo, a menos que os requisitos de conformidade de privacidade exijam listagens de aplicativos separadas ou listagem de aplicativos separados sejam necessários para dar suporte à nuvem governamental. Você deve criar em sua lógica de negócios e publicar apenas uma listagem. [Correção Obrigatória]

  • Para atender aos requisitos de suporte de várias regiões, você deve criar em sua lógica de negócios e publicar apenas uma listagem.

  

  • Para atender a vários requisitos de ponto de extremidade para implantação local e na nuvem, você deve criar em sua lógica de negócios e publicar apenas uma listagem.

Adequado para o consumo no local de trabalho

[Correção Obrigatória]

Esta seção está em linha com a política de certificação comercial da Microsoft número 1140.1.2, 100.8 e 100.10 e fornece diretrizes adicionais aos desenvolvedores sobre a criação de aplicativos apropriados para o local de trabalho.

Expandir para saber mais

O conteúdo do aplicativo deve ser adequado para consumo geral no local de trabalho e seguir todas as restrições listadas nas políticas de certificação do mercado comercial. É proibido o conteúdo relacionado à religião, política, jogos de azar e entretenimento prolongado. [Correção Obrigatória]

Seu aplicativo deve permitir a colaboração em grupo, melhorar a produtividade de um indivíduo ou ambos. Os aplicativos destinados à união e socialização da equipe devem ser colaborativos e projetados para vários participantes. Os aplicativos não devem exigir um investimento temporal substancial de mais de 60 minutos por sessão ou afetar a produtividade. [Correção Obrigatória]

Os aplicativos agregadores de conteúdo devem ter um mecanismo para que os usuários reportem um problema ou conteúdo inadequado ao editor do aplicativo. [Correção Obrigatória]

Plataformas e serviços semelhantes

[Correção Obrigatória]

Esta seção está em linha com a política de certificação comercial da Microsoft número 1140.1.3.

Os aplicativos devem se concentrar na experiência do Teams e não incluir nomes, ícones ou imagens de outras plataformas ou serviços de colaboração baseados em chat semelhantes no conteúdo do aplicativo ou nos metadados do aplicativo, a menos que o aplicativo forneça interoperabilidade específica.

Nomes de recursos

Nomes de recursos de aplicativo em botões e outros textos da interface do usuário não devem usar terminologia reservada para o Teams e outros produtos da Microsoft. Por exemplo, Iniciar reunião, Fazer chamada ou Iniciar chat são nomes de recursos em uso pela Microsoft no Microsoft Teams. Se necessário, inclua o nome do aplicativo para deixar a distinção clara, como Iniciar reunião contoso.

Autenticação

[Correção Obrigatória]

Esta seção está em linha com a política de certificação comercial da Microsoft número 1140.1.4 e fornece diretrizes aos desenvolvedores sobre como autenticar seus aplicativos com serviços externos.

Para obter mais informações sobre como implementar a autenticação de aplicativo, consulte autenticação em Teams.

Expandir para saber mais

Autenticação com serviços externos

Se seu aplicativo autentica usuários com um serviço externo, siga estas diretrizes:

• Entre, saia e inscreva-se em experiências:

  • Os aplicativos que dependem de contas ou serviços externos devem fornecer uma experiência de entrada, saída e inscrição clara e simples. [Correção Obrigatória]
  • Quando os usuários se desconectam, eles devem se desconectar apenas do aplicativo e permanecer conectados ao Teams. [Correção Obrigatória]
  • Os aplicativos que dependem de contas ou serviços externos devem fornecer um caminho a seguir para que novos usuários se inscrevam ou contatem o editor do aplicativo para saber mais sobre os serviços e obter acesso aos serviços. O caminho a seguir deve estar disponível no manifesto do aplicativo, na descrição longa do AppSource e na experiência de primeira execução do aplicativo (mensagem de boas-vindas do bot, configuração de guia ou página de configuração). [Correção Obrigatória]
  • Os aplicativos que exigem que o administrador de locatário conclua a instalação única devem chamar a dependência do administrador do locatário para configurar o aplicativo (antes que qualquer outro usuário locatário possa instalar e usar o aplicativo). A dependência deve ser chamada no manifesto do aplicativo, na descrição longa do AppSource, em todos os pontos de toque da experiência de primeira execução (mensagem de boas-vindas do bot, configuração de guia ou página de configuração), ajuda texto conforme considerado necessário como parte da resposta do bot, extensões de composição ou conteúdo de guia estática. [Correção Obrigatória]

• Experiências de compartilhamento de conteúdo: os aplicativos que requerem autenticação com um serviço externo para compartilhar conteúdo nos canais do Teams devem indicar claramente na documentação de ajuda (ou recursos semelhantes) como desconectar ou cancelar o compartilhamento de conteúdo se esse recurso for compatível com o serviço externo. Isso não significa que a capacidade de cancelar o compartilhamento de conteúdo deve estar presente no seu aplicativo do Teams.

Áudio

• Se a intenção principal do aplicativo é ouvir música, ele deve dar suporte a pelo menos um escopo colaborativo com fluxo de trabalho de ponta a ponta específico para o aplicativo. Por exemplo, compartilhamento de playlist, configuração ou fixação de lista de reprodução e escuta síncrona de música. [Correção Obrigatória]

• Os aplicativos publicados com a principal intenção de permitir que os usuários ouçam músicas no Teams são recomendados para incluir a experiência colaborativa de co-escuta. [Correção Sugerida]

Segurança

Esta seção está em linha com a política de certificação comercial da Microsoft número 1140.3.

Voltar para o início

Informações financeiras

[Correção Obrigatória]

Esta seção está em linha com a política de certificação comercial da Microsoft número 1140.3.1 e fornece diretrizes sobre a transmissão de informações financeiras dentro da interface do Teams e notifica os desenvolvedores de cenários de pagamento restritos na versão móvel (Android e iOS) de seu aplicativo teams.

Expandir para saber mais

Os aplicativos não devem pedir aos usuários que façam pagamentos na interface do Teams e transmitam informações financeiras aos usuários por meio de uma interface de bot. [Correção Obrigatória]

Você pode fornecer um link para proteger serviços de pagamento externos apenas se divulgá-lo em seus termos de uso, política de privacidade, página de perfil ou site antes de o usuário concordar em usar o aplicativo. [Correção Obrigatória]

Não facilite pagamentos por meio de um aplicativo de bens ou serviços proibidos pela política geral número 100.10 Conteúdo impróprio. [Correção Obrigatória]

Os aplicativos em execução na versão para iOS ou Android do Teams devem seguir as seguintes diretrizes:

• Os aplicativos não devem incluir compras no aplicativo, ofertas de avaliação ou interface do usuário que visa atualizar usuários para versões pagas ou lojas online para comprar outros conteúdos, aplicativos ou suplementos. [Correção Obrigatória]

  

  

• Se seu aplicativo exigir uma conta, os usuários poderão se inscrever para uma conta sem custo. É proibido o uso do termo gratuito ou conta gratuita. [Correção Obrigatória]

• Você pode determinar se uma conta está ativa indefinidamente ou por um tempo limitado. Quando a conta expirar, o aplicativo não deve mostrar interface do usuário, texto ou links indicando a necessidade de pagamento. [Correção Obrigatória]

• A política de privacidade e os termos de uso do seu aplicativo devem estar livres de qualquer interface do usuário ou links relacionados ao comércio. [Correção Obrigatória]

Bots

[Correção Obrigatória]

Esta seção está em linha com a política de marketplace comercial da Microsoft número 1140.3.2.

Expandir para saber mais

Para aplicativos que usam o Serviço de Bot do Microsoft Azure (como bots e extensões de mensagens), você deve seguir todos os requisitos definidos na Microsoft Termos dos Serviços Online.

Os bots sempre devem pedir permissão para fazer upload de um arquivo e exibir uma mensagem de confirmação.

Domínios externos

[Correção Obrigatória]

Esta seção está em linha com a política de marketplace comercial da Microsoft número 1140.3.3 e fornece diretrizes do desenvolvedor sobre o uso de domínios restritos na propriedade manifesto do validDomains aplicativo.

Expandir para saber mais

Não inclua domínios fora do controle da sua organização (incluindo curingas) e serviços de túnel nas configurações de domínio do seu aplicativo. As seguintes exceções incluem:

• Se seu aplicativo depender do SharePoint, você poderá incluir o site raiz associado do SharePoint como um domínio válido usando a {teamSiteDomain} propriedade do contexto. [Correção Obrigatória]

• Não use domínios de nível superior, como .com, .in e .org como um domínio válido. [Correção Obrigatória]

• Não use .onmicrosoft.com ou como um domínio válido em que o onmicrosoft não esteja sob seu controle. No entanto, você pode usar yoursite.com como um domínio válido em que seu local está sob seu controle, embora o domínio inclua um curinga. [Correção Obrigatória]

• Se seu aplicativo for um PowerApp criado no Microsoft Power Platform, você deverá incluir apps.powerapps.com como um domínio válido para permitir que seu aplicativo seja acessível e funcional no Teams.

• Domínios externos declarados para seu envio não devem conter URLs. Por exemplo, www ou https. [Correção Obrigatória]

• Se o aplicativo usar o OAuthCard do Azure Serviço de Bot, você deverá incluir token.botframework.com como um domínio válido ou então o botão Entrar não funcionará. Você não deve declarar .botframework.com como curingas não são permitidos com esse nome de domínio. [Correção Obrigatória]

• As URLs OpenAPI devem estar sob controle de parceiro.

• Domínios externos a seguir não são permitidos: [Correção obrigatória]

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

Ao usar curingas (*), as seguintes regras se aplicam:

• Se um segmento de subdomínio incluir um curinga, ele deve ser o único caractere no segmento.
• Qualquer segmento anterior a um segmento curinga também deve ser um segmento curinga.

Por exemplo, *.*.domain.com é válida, mas foo.*.myteam.domain.com não é válido.

Conteúdo confidencial

[Correção Obrigatória]

Seu aplicativo não deve postar dados confidenciais, como cartão de crédito, detalhes de pagamento financeiro, integridade, rastreamento de contatos ou outras informações pessoais identificáveis (PII) para um público que não pretende exibir o conteúdo.

O aplicativo deve avisar os usuários antes de baixar quaisquer arquivos ou executáveis (.exe) no computador ou ambiente do usuário.

Funcionalidade e desempenho gerais

Esta seção está em linha com a política de marketplace comercial da Microsoft número 1140.4.

• As diretrizes de encaminhamento são obrigatórias para usuários administradores e existentes. Você pode adicionar diretrizes de encaminhamento como hiperlinks para se inscrever, começar, entrar em contato conosco, links de ajuda ou email.
• Chamar a dependência ou limitações da conta sob a funcionalidade do aplicativo não é necessário, mas é obrigatório adicioná-la na descrição longa do manifesto do aplicativo e na listagem de aplicativos do AppSource.
• Você deve chamar qualquer dependência de administradores de locatários para novos usuários. Se não houver dependência, é obrigatório fornecer uma inscrição, entrar em contato conosco, iniciar link ou email.

Voltar para o início

Iniciar a funcionalidade externa

[Correção Obrigatória]

Os aplicativos não devem tirar os usuários do Teams para cenários principais de usuário. O conteúdo e as interações do aplicativo devem ocorrer dentro dos recursos do Teams, como bots, Cartões Adaptáveis, guias e caixas de diálogo (conhecidos como módulos de tarefa no TeamsJS v1.x).

Observação

Para redirecionar os usuários do aplicativo teams para sua experiência nativa por meio de um link profundo com um protocolo como , ou , inicie o link profundo em uma nova janela chamando o window.open método ou usando uma marca de âncora com target="_blank".webex:mailto:tel:

Expandir para saber mais

• Vincule usuários dentro do aplicativo Teams e não a um site ou aplicativo externo. Para cenários que exigem funcionalidade externa, seu aplicativo deve ter permissão explícita do usuário para iniciar a funcionalidade. [Correção Obrigatória]

• O texto do botão da interface do usuário que ativa a funcionalidade externa deve incluir conteúdo para indicar que o usuário foi retirado da instância do Teams. Por exemplo, inclua texto como Desta forma para Contoso.com ou Exibir em Contoso.com. [Correção Obrigatória]

• Adicione o ícone Pop-out para que os usuários saibam que estão sendo navegados fora do Teams. Você pode usar o ícone pop-out à direita do link. [Correção Obrigatória]

• Se você não conseguir adicionar um ícone Pop-out , poderá implementar qualquer uma das seguintes opções para que o usuário saiba que ele está sendo navegado fora do Teams: [Correção Obrigatória]

  • Adicione uma nota no Cartão Adaptável que afirma que quando os usuários selecionam Obter Ajuda usando este aplicativo, ele leva o usuário para fora do Teams.
  • Adicione caixas de diálogo intersticiais.

Compatibilidade

[Correção Obrigatória]

Os aplicativos devem estar totalmente funcionais nas versões mais recentes dos seguintes sistemas operacionais e navegadores:

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

Seu aplicativo deve mostrar uma mensagem de falha normal em navegadores e sistemas operacionais sem suporte.

Tempo de resposta

[Correção Obrigatória]

Os aplicativos do Teams devem responder dentro de um período de tempo razoável ou mostrar um indicador de carregamento ou digitação ou mensagem ou aviso.

• As guias devem responder dentro de dois segundos ou exibir uma mensagem de carregamento ou aviso. [Correção Obrigatória]
• Os bots devem responder aos comandos do usuário dentro de dois segundos ou exibir um indicador de digitação. [Correção Obrigatória]
• As extensões de mensagens devem responder aos comandos do usuário dentro de dois segundos. [Correção Obrigatória]
• As notificações devem ser exibidas dentro de dois segundos após a ação do usuário. [Correção Obrigatória]

Aplicativos alimentados por Inteligência Artificial

Explore recursos projetados para ajudá-lo com práticas responsáveis de IA (Inteligência Artificial) em todas as etapas de inovação, como o Microsoft RAI Toolkit e o HAX Toolkit Project.

Esta seção está em linha com a política de marketplace comercial da Microsoft para Aplicativos com conteúdo gerado por IA e política de marketplace comercial da Microsoft para Aplicativos usando recursos de reconhecimento facial.

Aplicativos com conteúdo gerado por IA

• O aplicativo não deve gerar, conter ou fornecer acesso a conteúdo gerado por IA inadequado, prejudicial ou ofensivo consistente com as políticas de marketplace comercial existentes descritas em 100.10. [Correção Obrigatória]

  • Considere usar qualquer um dos seguintes:
    • Use a biblioteca de IA do Teams, a interface centrada no Teams para modelos de linguagem comum baseados em GPT e mecanismos de intenção do usuário. [Correção Sugerida]
    • Uso de ganchos de moderação, que podem ser usados para regular as respostas do bot por meio da API de moderação. [Correção Sugerida]
    • Adicione a funcionalidade de varredura de conversa, que ajuda você a monitorar conversas e intervir quando as conversas se desviam. [Correção Sugerida]

• O aplicativo deve fornecer mecanismos para que os usuários de aplicativo denunciem conteúdo inadequado, prejudicial ou ofensivo ao desenvolvedor por qualquer um dos seguintes mecanismos: [Correção Obrigatória]

  • Descrição do aplicativo, incluindo ID de email ou link para o portal para registrar o problema.
  • No mecanismo de aplicativo para registrar o problema, juntamente com uma referência específica ao conteúdo inadequado.

• Você deve tomar medidas oportunas sobre as preocupações relatadas. [Correção Obrigatória]

• O aplicativo deve descrever claramente a funcionalidade de IA antes que o cliente adquira a oferta consistente com a política 100.1.3 e solicitar que o usuário examine as informações como parte da funcionalidade no aplicativo. [Correção Obrigatória].

  

Aplicativos que usam recursos de reconhecimento facial

Observação

Os aplicativos nessa categoria podem passar por uma revisão adicional para adesão aos princípios de IA Responsável da Microsoft.

• O aplicativo não deve permitir o uso de recursos de reconhecimento facial para identificar um indivíduo a ser usado por ou para um departamento de polícia no Estados Unidos. [Correção Obrigatória]
• Para aplicativos que utilizam tecnologias de reconhecimento facial ou inferência emocional, você deve fornecer uma marca ou indicação proeminente de cada uma dessas funcionalidades na descrição do aplicativo. [Correção Obrigatória]
  • Aplicativos que usam expressões faciais ou movimentos faciais para inferir estados emocionais, como raiva, nojo, felicidade, tristeza, surpresa, medo ou outros termos comumente usados para descrever o estado emocional de uma pessoa podem ser restritos com base na revisão.
  • O uso de expressões faciais e movimentos para detectar e classificar apenas elementos faciais individuais, como sorrisos ou sobrancelhas levantadas, é permitido. A distinção chave é entre a detecção de expressões faciais ou movimentos como sinais visuais versus a inferência de um estado emocional.

Pacote de aplicativos e listagem da Teams Store

[Correção Obrigatória]

Os pacotes de aplicativos devem ser formatados corretamente e incluir todas as informações e componentes necessários.

Dica

• Você deve garantir que as contas de teste fornecidas ou o ambiente de teste sejam válidos em perpetuidade, ou seja, até que o aplicativo esteja em tempo real no marketplace comercial.

• Você deve incluir as seguintes instruções de teste detalhadas para validar o envio do aplicativo:

  • Etapas para configurar as contas de teste do aplicativo caso o aplicativo dependa de contas externas para autenticação.
  • Resumo de comportamento esperado do aplicativo para os fluxos de trabalho principais no Teams.
  • Descreva claramente limitações, condições ou exceções à funcionalidade, aos recursos e aos entregadores na descrição longa do aplicativo e nos materiais relacionados.
  • Ênfase em quaisquer considerações para testadores ao validar o envio do aplicativo.
  • Pré-popular as contas de teste com dados fictícios para ajudar no teste.
  • Se você estiver fornecendo suas contas de teste, certifique-se de habilitar a integração de terceiros. Além disso, desabilite a autenticação de dois fatores ou multifator.

Voltar para o início

Manifesto do aplicativo

[Correção Obrigatória]

O manifesto do aplicativo define a configuração do aplicativo.

• O manifesto do aplicativo deve estar em conformidade com um esquema de manifesto de aplicativo lançado publicamente. Para obter mais informações, consulte referência de manifesto do aplicativo. Não envie seu aplicativo usando uma versão prévia do manifesto do aplicativo.
• Se seu aplicativo incluir um bot ou uma extensão de mensagens, os detalhes no manifesto do aplicativo deverão ser consistentes com os metadados da Estrutura do Bot, incluindo o nome do bot, o logotipo, o link da política de privacidade e o link de termos de serviço.
• Se o aplicativo usar Microsoft Entra ID para autenticação, inclua a ID do aplicativo Microsoft Entra (cliente) no manifesto do aplicativo. Para obter mais informações, consulte a referência de manifesto do aplicativo.

Usos do esquema de manifesto de aplicativo mais recente

• Se o aplicativo usar o SSO (logon único), você deverá declarar Microsoft Entra ID no manifesto do aplicativo para autenticação do usuário. [Correção Obrigatória]

• Você deve usar um esquema de manifesto de aplicativo lançado publicamente. Você pode atualizar seu pacote de aplicativo para usar uma versão pública do esquema de manifesto do aplicativo 1.10 ou posterior. [Correção Obrigatória]

• Quando você envia uma atualização de aplicativo, só aumenta o número da versão do aplicativo. A ID do aplicativo atualizado deve corresponder à ID do aplicativo publicado. [Correção Obrigatória]

• A presença de arquivos adicionais no pacote de aplicativos não é aceitável. [Correção Obrigatória]

• O número da versão deve ser o mesmo no esquema de arquivo de manifesto do aplicativo e no esquema de manifesto de aplicativo de idiomas adicionais. [Correção Obrigatória]

• Você deve usar o esquema de manifesto do aplicativo versão 1.5 ou posterior para localizar seu aplicativo. Para usar o esquema de aplicativo versão 1.5 ou posterior no arquivo manifest.json, atualize o $schema atributo para 1,5 ou posterior. Atualize a manifestVersion propriedade para a $schema versão (1.5 nesse caso). [Correção Obrigatória]

• Quando você adiciona, atualiza ou remove um recurso existente, adiciona ou remove o manifesto do aplicativo ou metadados do Partner Center, você deve aumentar o número da versão do aplicativo e enviar o novo manifesto do aplicativo em sua conta do Partner Center para validação. [Correção Obrigatória]

• A cadeia de caracteres de versão deve seguir o padrão SemVer (Especificação de Versão Semântica) (MAJOR). MENOR. PATCH). [Correção Obrigatória]

• Se o aplicativo exigir que os administradores examinem as permissões e concedam o consentimento no centro de administração do Teams, você deve declarar webapplicationinfo no manifesto do aplicativo. Se webapplicationinfo não for declarado no manifesto do aplicativo, a página Permissões do seu aplicativo no centro de administração do Teams será mostrada como ... [Correção Obrigatória]

• Como parte da certificação de aplicativo do Teams, você deve enviar uma versão de produção do manifesto do aplicativo. [Correção Obrigatória]

• Recomendamos declarar a ID do MPN (Microsoft Partner Network) no manifesto do aplicativo. A ID do MPN ajuda a identificar a organização parceira que cria o aplicativo. [Correção Sugerida]

• Escopos e/ou contexto declarados no manifesto do aplicativo devem estar visíveis no aplicativo. [Correção Obrigatória]

Ícones do aplicativo

[Correção Obrigatória]

Os ícones são um dos elementos main que as pessoas veem ao navegar na Teams Store.

Expandir para saber mais

Seus ícones devem comunicar a marca e a finalidade do aplicativo, aderindo aos seguintes requisitos:

• O ícone de cor e contorno do aplicativo enviado na listagem do aplicativo deve corresponder. [Correção Obrigatória]

  

  

• O pacote do aplicativo deve incluir duas versões .png do ícone do aplicativo: um ícone de cor e um ícone de estrutura de tópicos. [Correção Obrigatória]

• O ícone do marketplace carregado como parte da listagem do marketplace do aplicativo em sua conta do Partner Center deve corresponder ao ícone de cor fornecido em seu pacote de aplicativos. [Correção Obrigatória]

• A versão de cor do ícone deve ter 192 x 192 pixels. O símbolo de ícone pode ser qualquer cor ou cores, mas deve ficar em um plano de fundo quadrado sólido ou totalmente transparente. [Correção Obrigatória]

• A versão de estrutura de tópicos do ícone é exibida nos seguintes cenários:

  • Quando seu aplicativo está em uso e hospedado na barra de aplicativos no lado esquerdo do Teams.
  • Quando um usuário fixa a extensão de mensagens do aplicativo.

• A estrutura de tópicos deve ter 32 x 32 pixels e pode ser branca com uma tela de fundo transparente ou transparente com uma tela de fundo branca. O ícone não deve ter nenhum preenchimento extra ao redor do símbolo. [Correção Obrigatória]

• O pacote do aplicativo deve incluir ícones formatados e dimensionados corretamente. Os ícones devem corresponder às informações nos metadados de listagem da Teams Store. [Correção Obrigatória]

Para obter mais informações, consulte diretrizes do ícone.

Descrições do aplicativo

Você deve ter uma descrição curta e longa para seu aplicativo. A descrição do aplicativo ajuda a melhorar a descoberta do aplicativo na Teams Store. As descrições na configuração do aplicativo e no Partner Center devem ser as mesmas.

Expandir para saber mais

As descrições não devem ser diretas ou por sugestão desrogar outra marca (propriedade da Microsoft ou não). Verifique se sua descrição não inclui declarações que não podem ser comprovadas. Por exemplo, Aumento garantido de 200% na eficiência.

• A descrição do aplicativo não deve conter informações de marketing comparativas. Por exemplo, não use logotipos ou marcas comerciais concorrentes na listagem de ofertas, incluindo marcas ou outros metadados que fazem referência a ofertas ou marketplaces concorrentes. [Correção Obrigatória]

  

• Detalhes de contato do hiperlink, introdução, ajuda ou inscrição na descrição do aplicativo. [Correção Sugerida]

  

  

• A descrição do aplicativo deve identificar o público-alvo, explicar brevemente e claramente seu valor exclusivo e distinto, identificar produtos microsoft compatíveis e outros softwares e incluir quaisquer pré-requisitos ou requisitos para seu uso. Você deve descrever claramente quaisquer limitações, condições ou exceções à funcionalidade, recursos e entregas, conforme descrito na listagem e materiais relacionados antes que o cliente adquira sua oferta. As funcionalidades que você declara devem estar relacionadas com as funções principais e a descrição de sua oferta. [Correção Obrigatória]

• Se você atualizar o nome do aplicativo, substitua o nome do aplicativo antigo pelo novo nome do aplicativo nos metadados de oferta no manifesto do aplicativo, AppSource e sempre que aplicável. [Correção Obrigatória]

• Limitações e dependências da conta devem ser chamadas no manifesto Descrição do Aplicativo, AppSource e Partner Center. Por exemplo:

  • Conta corporativa
  • Assinatura paga
  • Outra licença ou conta
  • Idioma
  • Discagem PSTN (rede telefônica comutador público)
  • Dependência regional
  • Tempo de execução para tradutores de reserva ou agentes ao vivo
  • Funcionalidade baseada em função
  • Dependência do aplicativo nativo

  

  

• Se o aplicativo tiver suporte para regiões específicas ou locais geográficos, você deverá chamar essa dependência de região específica na descrição do aplicativo no manifesto do aplicativo, no Partner Center e no AppSource para essa oferta.

• Se você precisar fazer referência ao Teams, escreva a primeira referência na listagem do aplicativo como Microsoft Teams. Referências posteriores podem ser reduzidas para Teams. [Correção Obrigatória]

  

  

Descrição curta

Uma breve descrição deve ser um resumo conciso do seu aplicativo que realça sua proposta de valor e é direcionado ao seu público-alvo.

O que fazer:

• Manter a descrição curta em uma frase.
• Colocar primeiro as informações mais importantes.
• Incluir palavras-chave que os clientes provavelmente procurarão.
• Faça uso eficiente do limite de caracteres disponível. Por exemplo, não repita o nome do aplicativo.

Não fazer:

[Correção Sugerida]

Usar a palavra aplicativo na descrição curta.

Descrição longa

A longa descrição deve fornecer uma narrativa envolvente que realça a proposta de valor do seu aplicativo, o público-alvo primário e o setor de destino. Embora a descrição possa ter até 4.000 caracteres, recomendamos que você tenha uma descrição concisa de cerca de 1000 caracteres.

O que fazer:

• Usar Markdown para formatar sua descrição.

• Usar a voz ativa e falar diretamente com os usuários. Por exemplo, Você pode....

• Liste os principais benefícios para realçar as vantagens de usar seu aplicativo. Adicione três benefícios.

• Adicione a proposta de valor chave do seu aplicativo no Teams.

• Listar os recursos com marcadores para que seja mais fácil escanear a descrição.

• Descreva claramente as limitações, os recursos, as condições ou as exceções à funcionalidade e as entregas na listagem e nos materiais relacionados antes que o usuário instale seu aplicativo. As funcionalidades do Teams devem estar relacionadas às funções principais descritas na listagem.

• Verifique se a descrição do aplicativo corresponde à funcionalidade disponível dentro do aplicativo teams. Qualquer referência a fluxos de trabalho fora do aplicativo Teams deve ser limitada e distintamente chamada a partir da funcionalidade do aplicativo Teams.

• Inclua uma ajuda ou um link de suporte.

• Consulte Microsoft 365 em vez de Office 365.

• Use a seguinte linguagem ao descrever como o aplicativo funciona com o Teams (ou com o Microsoft 365):

  • ... funciona com o Microsoft Teams.
  • ... trabalhando com o Microsoft Teams.
  • ... no Microsoft Teams.
  • ... para o Microsoft Teams.
  • ... integrado ao Microsoft Teams.
  • ... criado para...
  • ... desenvolvido para...
  • .. projetado para...

O que não fazer:

[Correção Obrigatória]

• Exceder 500 palavras.

• Abreviar Microsoft como MS ou MSFT.

  

  

• Indicar que o aplicativo é uma oferta da Microsoft, incluindo o uso de lemas ou linhas de marcação da Microsoft.

  

  

• Use o seguinte idioma, a menos que você seja um parceiro certificado da Microsoft:

  • ... certificado para ...
  • ... da plataforma ...

• Incluir erros de digitação, erros gramaticais.

• Capitalize desnecessariamente todo o manifesto do aplicativo ou a descrição longa do AppSource ou o conteúdo do aplicativo.

  

  

• Incluir links ao AppSource.

  

• Faça declarações não verificadas. Por exemplo, melhor, superior e classificado, a menos que ele venha com a origem da declaração.

• Compare sua oferta com outras ofertas do marketplace.

Para obter diretrizes sobre como criar uma descrição precisa, concisa e informativa curta e longa, confira lista de verificação para gravar descrições do aplicativo.

Capturas de tela

As capturas de tela fornecem uma visualização panorâmica proeminente do seu aplicativo para complementar seu nome, ícone e descrições.

Expandir para saber mais

Lembre-se do seguinte:

• Você pode ter até cinco capturas de tela por lista.
• Os tipos de arquivo com suporte incluem PNG, JPEG e GIF.
• As dimensões devem ter 1366 x 768 pixels.
• Tamanho máximo de 1.024 KB.

O que fazer:

• Concentre-se nas funcionalidades do seu aplicativo. Por exemplo, como as pessoas podem se comunicar com seu bot.

• Incluir conteúdo que represente com precisão seu aplicativo.

• Usar texto de forma criteriosa.

• Capturas de tela de quadro com uma cor que reflete sua marca e inclui conteúdo de marketing.

• Use capturas de tela de alta resolução que sejam afiadas e contenham texto legível e claramente legível. [Correção Obrigatória]

• Pelo menos uma captura de tela deve retratar a funcionalidade do aplicativo em dispositivos móveis. [Correção Obrigatória]

  

• Você pode ter até cinco capturas de tela por listagem. Você deve ter no mínimo três e no máximo cinco capturas de tela na listagem do aplicativo. [Correção Obrigatória]

• Use maquetes que retratam com precisão a interface do usuário real do aplicativo em benefício dos usuários finais. As capturas de tela devem retratar com precisão a interface do usuário real do aplicativo ou cenários relevantes e relacionados ao aplicativo. [Correção Obrigatória]

  

  

• Deve retratar a funcionalidade do aplicativo ou a integração com o Teams. [Correção Obrigatória]

  

• As capturas de tela fornecidas não devem referenciar incorretamente o Microsoft Teams como MS, MSFT ou MS Teams. [Correção Obrigatória]

• Se o aplicativo teams for extensível entre clientes do Microsoft 365 (Microsoft 365, Outlook e Microsoft Teams), as capturas de tela fornecidas devem representar a funcionalidade do aplicativo em outros clientes do Microsoft 365. [Correção Obrigatória]

  

• Você deve fornecer legendas em suas capturas de tela para permitir que o usuário entenda claramente a funcionalidade do aplicativo. [Correção Obrigatória]

  

• Se seu aplicativo dá suporte a Tabs como um recurso, as capturas de tela que mostram o aplicativo no contexto de uma guia do Teams, na listagem de aplicativos, devem conter o cromo da Equipe. [Correção Obrigatória]

  

O que não fazer:

• Inclua maquetes que refletem imprecisamente a interface do usuário real do aplicativo, como mostrar seu aplicativo sendo usado fora do Teams.

  

Vídeos

Um vídeo na listagem de aplicativos é uma das maneiras mais eficazes de comunicar por que as pessoas devem usar seu aplicativo. Você pode adicionar sua URL de vídeo do YouTube ou vimeo que fornece o valor do seu aplicativo. Além disso, como uma prática recomendada, recomendamos que você adicione um vídeo que forneça o passo a passo de demonstração ou cenário do seu aplicativo. [Correção sugerida]

Se você optar por enviar um vídeo como parte da listagem do aplicativo em sua conta do Partner Center, verifique se você atende aos seguintes critérios:

• O vídeo deve ser curto, claro, envolvente e de boa qualidade.

• O vídeo deve demonstrar como configurar e usar o aplicativo.

• O vídeo deve estar em um formulário narrativo.

• A duração do vídeo deve estar dentro de 60-90 segundos para um vídeo de valor e a duração recomendada para um vídeo passo a passo é de 3 a 5 minutos. [Correção Sugerida]

• Você deve desativar anúncios de suas configurações de conta do YouTube ou vimeo antes de enviar o link de vídeo na listagem do aplicativo. [Correção Obrigatória]

• O vídeo deve realçar as funcionalidades e a integração do aplicativo no Teams. [Correção Obrigatória]

• O vídeo deve estar disponível como um link funcional. [Correção Obrigatória]

• O vídeo deve estar no formato https://www.example.com/123456789.

  

• O vídeo pode ser exibido na primeira posição do carrossel de capturas de tela ou vídeos nos detalhes do aplicativo (Teams Store e Administração Center) e nas páginas AppSource. [Correção Sugerida]

• O vídeo sobre demonstração ou passo a passo do cenário deve ter a intenção de instruir os usuários e não promover seu aplicativo.

Para obter mais informações sobre os critérios para criar um vídeo de valor de aplicativo ou vídeo passo a passo, confira a lista de verificação para criar um vídeo.

Política de privacidade

[Correção Obrigatória]

A política de privacidade pode ser específica para seu aplicativo Teams ou uma política geral para todos os seus serviços.

• Se você usar um modelo de política de privacidade genérico, deverá adicionar uma referência a serviços, aplicativos ou plataformas no escopo de sua política de privacidade. Você não precisará especificar seu aplicativo teams no escopo, se incluir uma referência a serviços, aplicativos e plataformas. O processo de validação do aplicativo interpreta essas referências para incluir seu aplicativo teams junto com seus outros serviços ou sites.
• Deve incluir como você lida com o armazenamento, retenção e exclusão de dados do usuário. Você deve descrever os controles de segurança para proteção de dados.
• Deve incluir suas informações de contato.
• Não deve incluir URLs que estão quebradas ou para fins beta ou de preparo.
• Não deve incluir links para AppSource.
• Não deve exigir autenticação para acessar a política de privacidade.
• Não deve incluir nenhuma interface do usuário de comércio ou links da store.
• Deve ter o mesmo link no manifesto do aplicativo e no AppSource.

Termos de uso

[Correção Obrigatória]

Use as seguintes diretrizes para escrever o Termos de uso:

• Deve ser específico e aplicável à sua oferta.
• Deve ser hospedado em seu próprio domínio.
• Deve ter um link seguro (HTTPS).
• O acesso aos Termos de uso não deve exigir autenticação.
• Deve ter o mesmo link no manifesto do aplicativo e no AppSource.

Links de suporte

[Correção Obrigatória]

As URLs de suporte do aplicativo não devem exigir autenticação. Por exemplo, os usuários devem ter permissão para entrar em contato com você sem entrar.

Expandir para saber mais

As URLs de suporte devem incluir seus detalhes de contato ou uma maneira de avançar para que os usuários gerem um tíquete de suporte. Por exemplo, se a URL de suporte estiver hospedada no GitHub, a página do GitHub deverá estar sob sua propriedade e deverá incluir os detalhes do contato ou uma maneira de avançar para que os usuários gerem um tíquete de suporte.

Localização

[Correção Obrigatória]

• Se o seu aplicativo oferece suporte à localização, o pacote do aplicativo deve incluir um arquivo com traduções de idiomas que são exibidos com base na configuração de idioma do Teams. O arquivo deve estar em conformidade com o esquema de Localização do Teams. Para obter mais informações, confira esquema de localização do Teams. [Correção Obrigatória]

• O conteúdo de metadados de aplicativo deve ser o mesmo em en-us outros idiomas de localização. [Correção Obrigatória]

• Os idiomas com suporte devem ser exibidos na descrição do aplicativo AppSource. Por exemplo, esse aplicativo está disponível no idioma localizado X (X=). [Correção Obrigatória]

• Se as configurações de cliente do usuário não corresponderem a nenhum de seus idiomas adicionais, o idioma padrão será usado como o idioma de fallback final. Atualize a localizationInfo propriedade com o idioma padrão correto que seu aplicativo dá suporte. [Correção Obrigatória]

• Atualize a localizationInfo propriedade com o idioma padrão correto que seu aplicativo dá suporte ou adicione conteúdo localizado para o manifesto do aplicativo e a descrição longa e curta do Partner Center. [Correção Obrigatória]

Aplicativos vinculados à oferta de SaaS

Esta seção está em linha com a política de marketplace comercial da Microsoft número 1140.5. Se você estiver criando um aplicativo do Teams vinculado a uma oferta saaS (Software como serviço), verifique se ele segue essas diretrizes.

Geral

• Os ISVs devem dar suporte à capacidade de vários usuários (Assinantes) no mesmo locatário gerenciarem sua própria assinatura e atribuir licenças aos usuários no locatário.
• A oferta deve atender a todos os requisitos técnicos para aplicativos Teams vinculados a uma oferta SaaS.
• Os aplicativos Teams vinculados à oferta SaaS devem atender a todos os requisitos definidos em 1000 Software as a Service (SaaS).
• subscriptionOffer os detalhes mencionados no arquivo de manifesto do aplicativo devem estar corretos. No manifesto do seu aplicativo, adicione ou atualize o nó subscriptionOffer com valor publisherId.offerId. Por exemplo, se seu ID de editor é contoso1234 e seu ID de oferta é offer01, o valor que você especifica no manifesto do aplicativo deve ser contoso1234.offer01.
• A oferta do SaaS vinculada ao aplicativo Teams deve estar ativa no AppSource e as ofertas de visualização não são aceitas para aprovação da Teams Store.

Oferecer metadados

• Os metadados de oferta devem corresponder ao manifesto do aplicativo, à listagem de aplicativos do Teams no AppSource e à oferta saaS no AppSource.
• O aplicativo Teams e a oferta de SaaS devem ser do mesmo editor ou desenvolvedor. A oferta saaS referenciada no manifesto do aplicativo deve pertencer ao mesmo editor que o aplicativo teams é enviado ao marketplace comercial.
• Como sua oferta enviada é um aplicativo do Teams vinculado à oferta do SaaS, você deve selecionar Compras adicionais como Sim, meu produto requer a compra de um serviço ou oferece compras adicionais no aplicativo na seção configuração de produtos do Partner Center da lista de ofertas.
• As descrições do plano e os detalhes de preços devem fornecer informações suficientes para que os usuários entendam claramente as listagens de ofertas.
• Quaisquer limitações, dependências de serviços adicionais e exceções aos recursos oferecidos devem ser chamados com precisão nas descrições do plano.
• Os aplicativos do Teams vinculados à oferta de SaaS foram projetados para dar suporte a licenças atribuídas por usuário. Às vezes, a oferta de SaaS é criada com outro método ou tem fluxos de compra especializados. Você deve mencionar claramente nos metadados do aplicativo e nos detalhes do plano de assinatura sobre o método e os fluxos de compra.
• A oferta de SaaS deve fornecer mensagens e diretrizes para todos os usuários em todos os estados aplicáveis do fluxo de compra.

SaaS oferece home page e gerenciamento de licenças

• Forneça uma introdução aos assinantes sobre como usar o produto.

• Permitir que o assinante atribua licenças.

• Forneça diferentes maneiras de se envolver com suporte para problemas, como perguntas frequentes, base de dados de conhecimento e email.

• Valide os usuários para garantir que eles ainda não tenham licença atribuída por meio de outro usuário.

• Notifique os usuários após a atribuição de licença.

• Orientar os usuários sobre como adicionar o aplicativo ao Teams e começar a usar o bot de chat ou email do Teams.

• Se um aplicativo SaaS usar o gerenciamento de licenças da Microsoft, após a confirmação da assinatura do aplicativo na página de destino do ISV, o usuário deverá ser redirecionado para o gerenciamento de licenças da Microsoft no Teams para evitar um beco sem saída e permitir que o usuário gerencie licenças no Teams.

Usabilidade e funcionalidade

• Após a compra bem-sucedida e atribuição de licenças, você deve fornecer o seguinte:
  • Acesso aos usuários para recursos do plano assinado.
  • Adição de valor e benefícios significativos do plano de assinatura aos usuários.
  • No aplicativo Teams, forneça um link para o aplicativo SaaS home page os assinantes gerenciem as licenças no futuro.

Configurar e testar o aplicativo SaaS

Se a instalação do aplicativo para fins de teste for complexa, forneça um documento funcional de ponta a ponta, as etapas de configuração da oferta de SaaS vinculadas e instruções para licença e gerenciamento de usuário como parte de suas Anotações para Certificação.

Dica

Você pode adicionar um vídeo sobre como o gerenciamento de aplicativos e licenças funciona para ajudar a equipe a testar.

Voltar para o início

Guias

Esta seção está em linha com a política de marketplace comercial da Microsoft número 1140.4.2. Se o aplicativo incluir uma guia, verifique se ele segue essas diretrizes.

Dica

Para obter mais informações sobre como criar uma experiência de aplicativo de alta qualidade, consulte as diretrizes de design da guia do Teams.

              

                             

Configurar

• A configuração da guia não deve acabar com um novo usuário. Forneça uma mensagem sobre como concluir a ação ou o fluxo de trabalho. [Correção Obrigatória]

  

• O usuário não deve deixar a experiência de configuração de guia dentro do Teams para criar conteúdo fora do Teams e, em seguida, retornar ao Teams para fixá-lo. A tela de configuração da guia deve explicar o valor da configuração e como configurá-lo. [Correção Obrigatória]

  

• A tela de configuração da guia não deve inserir um site inteiro. Mantenha sua experiência de configuração focada. Por exemplo, se você estiver criando um aplicativo de gerenciamento de projeto que permite que os usuários configurem um projeto em um canal, mantenha a tela de configuração da guia focada em permitir que o usuário selecione um projeto de seu aplicativo para configurar no canal. [Correção Obrigatória]

  

  

• Aplicativos que exigem que os usuários insiram uma URL ao configurar uma guia devem:

  • Forneça uma orientação adequada para que o usuário adquira ou gere a URL. [Correção Obrigatória]

  • Verifique se há URL relevante ou apropriada para a funcionalidade do aplicativo de acordo com a descrição do aplicativo. [Correção Obrigatória]

    

    

• Hiperlink as informações entre em contato conosco na tela de configuração em vez de texto simples para ajudar os usuários a entrar em contato com você para obter requisitos de suporte. [Correção Obrigatória]

• Para uma experiência de usuário de primeira execução contínua, recomendamos que você hiperlink sua URL de suporte ou email na tela de configuração. [Correção Sugerida]

Modos de exibição

• A área de tela de entrada não deve usar logotipos grandes. [Correção Obrigatória]

  

• O conteúdo pode ser simplificado por meio da divisão entre várias guias.

  

• As guias não devem ter um cabeçalho duplicado. Remova logotipos duplicados do quadro I, pois a estrutura de guias já exibe o ícone e o nome do aplicativo. [Correção Sugerida]

  

  

Navegação

Estas são as diretrizes de navegação:

• As guias não devem fornecer navegação que entre em conflito com a navegação primária do Teams. Se você fornecer uma navegação à esquerda em sua guia, ela não deverá incluir apenas ícones ou ícones com texto empilhado. Não deve ser um trilho dobrável com a opção de ver ícones com texto empilhado (imitando a barra de navegação do Teams). Inclua ícones com texto em linha ou somente texto ou use menus de hambúrguer em vez de corrimão esquerdo de guia. [Correção Obrigatória]

  Projete seu aplicativo com componentes da interface do usuário do Fluent básicos e avançados.

  

  

• Se sua guia tiver uma barra de ferramentas no trilho esquerdo sem nenhum componente de navegação, a barra de ferramentas deverá deixar o espaçamento de 20 pixels da navegação esquerda do Teams. [Correção Obrigatória]

  

• As páginas secundárias e terciárias em uma guia devem ser abertas em uma exibição de nível dois (L2) e nível três (L3) na área da guia main, que é navegada por meio de migalhas de pão ou navegação à esquerda. Você também pode usar os seguintes componentes para ajudar a navegação em uma guia:

  • Botões de voltar

  • Cabeçalhos da página

  • Menus de hambúrguer

    

• Links profundos em guias não devem ser vinculados a uma página da Web externa, mas ao Teams. Por exemplo, caixas de diálogo ou outras guias. [Correção Obrigatória]

  

• As guias não devem permitir que os usuários naveguem fora do Teams para a experiência principal do aplicativo. As guias podem redirecionar para fora do Teams para fluxos de trabalho não principais. Por exemplo, para gerar um tíquete de suporte. [Correção Obrigatória]

  

  

• O rolamento horizontal não deve estar presente em uma guia na reunião. [Correção Obrigatória]

• As caixas de diálogo na reunião usadas no aplicativo não devem permitir a rolagem horizontal. Use diálogos na reunião com moderação e para cenários leves e orientados para tarefas. Você pode especificar a largura do quadro I da caixa de diálogo na reunião dentro do intervalo de tamanho com suporte para considerar diferentes cenários. [Correção Obrigatória]

• As caixas de diálogo usadas no aplicativo não devem permitir a rolagem horizontal. As caixas de diálogo permitem selecionar tamanhos diferentes para tornar o conteúdo responsivo sem a necessidade de rolagem horizontal. Se necessário, você pode usar um Stageview (um componente de interface do usuário de tela inteira para exibir seu conteúdo da Web) para concluir o fluxo de trabalho sem rolagem horizontal. [Correção Obrigatória]

• A rolagem horizontal presente na guia em uma guia de detalhes de chat, canal e reunião pessoal em qualquer escopo não é permitida se a tela da guia inteira for rolável, a menos que sua guia use uma tela infinita com elementos de interface do usuário fixos. [Correção Obrigatória]

  

  

  

  

  

• O usuário deve ter uma opção para acessar o estado de trabalho anterior. [Correção Obrigatória]

  

  

• A rolagem horizontal em Cartões Adaptáveis não deve estar presente no Teams. [Correção Obrigatória]

• O trilho inferior usado para navegação em guias não deve entrar em conflito com a navegação de aplicativo móvel nativo do Teams. [Correção Obrigatória]

  

Usabilidade

• O conteúdo não deve truncar ou se sobrepor na guia. [Correção Obrigatória]

  

• Os usuários devem ser capazes de desfazer sua última ação na guia. [Correção Obrigatória]

• As guias em um contexto pessoal podem agregar conteúdo de instâncias compartilhadas do aplicativo. Por exemplo, um aplicativo de gerenciamento de projeto com uma guia configurável que permite aos membros do canal comentar sobre o projeto em cartões Kanban, deve agregar esse conteúdo e exibir no aplicativo pessoal. [Correção Sugerida]

• As guias devem responder aos temas do Teams. Quando um usuário altera o tema, o tema do aplicativo deve refletir a seleção. [Correção Sugerida]

  

  

• As guias devem usar componentes estilizados do Teams, como fontes do Teams, rampas de tipo, paletas de cores, sistema de grade, movimento, tom de voz, sempre que possível. Para obter mais informações, confira diretrizes de design de guia. [Correção Sugerida]

  

• Se a funcionalidade do aplicativo exigir alterações nas configurações, inclua uma guia Configurações. [Correção Sugerida]

• As guias devem seguir o design de interação do Teams, como navegação na página, posição e uso de caixas de diálogo, hierarquias de informações. Para obter mais informações, consulte Kit de interface do usuário fluente do Microsoft Teams. [Correção Sugerida]

• As experiências de tabulação devem ser totalmente responsivas em dispositivos móveis (Android e iOS). [Correção Obrigatória]

  Dica

  • Inclua um bot pessoal junto com uma guia pessoal.
  • Permitir que os usuários compartilhem o conteúdo da sua guia pessoal.

• A guia não deve conter elementos que obstruam ou impedem completamente os fluxos de trabalho dentro da guia. Por exemplo, bot dentro de uma guia que não pode ser minimizada. [Correção Obrigatória]

  

• Tab não deve ter uma funcionalidade quebrada. Sua oferta deve ser uma solução de software utilizável e deve fornecer as funcionalidades, recursos e entregas, conforme descrito em sua listagem e outros materiais relacionados. [Correção Obrigatória]

• Se suas guias contiverem um rodapé, verifique se você remove todos os links não relacionados à funcionalidade do aplicativo do rodapé. [Correção Obrigatória]

Seleção de escopo

• O conteúdo na página de destino de guias configuráveis não deve ser escopo para uso individual e não incluir conteúdo pessoal, como Minhas Tarefas ou Meu Painel. [Correção Obrigatória]

  

• Após a experiência de configuração, a página de destino deve mostrar uma exibição colaborativa para toda a equipe. [Correção Obrigatória]

• Se seu aplicativo exigir o provisionamento de uma exibição de escopo pessoal para o usuário melhorar a eficiência ou a produtividade do local de trabalho, use exibições filtradas, links profundos para aplicativos pessoais ou navegue até modos de exibição L2 ou L3 dentro da guia configurável e mantenha a página de aterrissagem contextualmente igual para todos os usuários. [Correção Obrigatória]

• O conteúdo na página de aterrissagem das guias configuráveis deve ser contextualmente o mesmo para todos os membros do canal. [Correção Obrigatória]

  

• As guias configuráveis devem ter a funcionalidade focalizada. [Correção Obrigatória]

  

Voltar para o início

Bots

Esta seção está em linha com a política de marketplace comercial da Microsoft número 1140.4.3.

Se o aplicativo incluir um bot, verifique se ele segue essas diretrizes.

Dica

Para obter mais informações sobre como criar uma experiência de aplicativo de alta qualidade, confira Diretrizes de design de bot do Teams.

Diretrizes de design do bot

• Seu aplicativo teams deve seguir as diretrizes de design de bot do Teams.

• Você deve implementar uma caixa de diálogo para evitar a resposta de bot de várias voltas quando o fluxo de trabalho envolve o usuário executando tarefas repetitivas. Por exemplo, use uma caixa de diálogo para capturar repetidamente nome, dob, place e designação em vez de usar conversas de várias voltas. [Correção Obrigatória]

• Quaisquer links, respostas ou fluxos de trabalho quebrados em seu aplicativo devem ser corrigidos. [Correção Obrigatória]

Comandos bot

Analisar a entrada do usuário e prever a intenção do usuário é difícil. Os comandos de bot fornecem aos usuários um conjunto de palavras ou frases para o bot entender.

• Todos os comandos compatíveis com o bot devem funcionar corretamente, incluindo comandos genéricos como Oi, Oláe Ajuda. [Correção Obrigatória]

  

  

• Os comandos de bot não devem levar um usuário a um beco sem saída, os comandos devem sempre fornecer um caminho a seguir. [Correção Obrigatória]

  

• Você deve listar pelo menos um comando bot válido na items.commands.title seção do manifesto do aplicativo e adicionar uma descrição adequada que dê clareza ao usuário no comando bot e seu uso. Os comandos de bot listados na commandLists seção da superfície do manifesto do aplicativo como comandos prepovoados no menu de comando do bot e fornecem um caminho a seguir para que o novo usuário interaja com o bot. [Correção Sugerida]

• A resposta do bot não deve conter imagens ou avatares oficiais do produto da Microsoft. Use seus próprios ativos em seu aplicativo. O uso de imagens de produto da Microsoft em seu aplicativo não é permitido. Você só poderá copiar, modificar, distribuir, exibir, licença ou vender imagens de produto com direitos autorais da Microsoft se receber permissão explícita no EULA (Contrato de Licença End-User), termos de licença que acompanham o conteúdo ou nas diretrizes de Marca e Marca da Microsoft. [Correção Obrigatória]

• Os bots devem responder a comandos de usuário sem exibir um indicador de carregamento contínuo. [Correção Obrigatória]

• A resposta do comando de ajuda do bot não deve redirecionar o usuário para fora do Teams. A resposta do comando de ajuda do bot pode redirecionar o usuário para uma tela dentro do aplicativo teams ou fornecer uma resposta de caminho a seguir em um Cartão Adaptável. [Correção Obrigatória]

  

• Os bots sempre devem fornecer uma resposta válida a uma entrada do usuário, mesmo que a entrada seja irrelevante ou imprópria. [Correção Obrigatória]

  

  

• Caracteres especiais, como barra (/), não devem ser prefixados em comandos de bot. [Correção Obrigatória]

  

• Os bots devem fornecer uma resposta válida a comandos de usuário inválidos. Os bots não devem acabar com o usuário ou exibir um erro se um usuário enviar um comando de bot inválido. [Correção Obrigatória]

  

  

• A funcionalidade do bot deve ser relevante para o escopo no qual o bot está instalado e o bot deve fornecer valor no escopo instalado. [Correção Obrigatória]

• Os bots não devem conter comandos duplicados. [Correção Obrigatória]

• Os bots não devem exibir um indicador de digitação depois de responder ao comando do usuário, mas podem exibir um indicador de digitação ao responder ao comando do usuário. [Correção Obrigatória]

• Os bots devem fornecer uma resposta válida ao comando de ajuda digitado em minúsculas ou maiúsculas que fornece ao usuário um caminho a seguir ou permite que o usuário acesse o conteúdo de ajuda relacionado ao uso do bot. Os bots devem fornecer uma resposta válida mesmo quando o usuário não tiver feito logon no aplicativo. [Correção Obrigatória]

  

  

• Os bots devem fornecer uma resposta válida para ajudar o comando.

  

• As respostas do bot no celular devem ser responsivas sem qualquer truncamento de dados que dificulte o uso do bot do usuário final para concluir os fluxos de trabalho desejados. [Correção Obrigatória]

  

  

• Todos os links em um cartão adaptável de resposta de bot devem ser responsivos. Qualquer link que leve o usuário para fora da plataforma do Teams deve ter um texto de redirecionamento claro, como, Exibir in.. ou Dessa forma para.., um ícone pop-out no botão de ação de resposta do bot ou ter um texto de redirecionamento adequado no corpo da mensagem de resposta do bot. [Correção Obrigatória]

  

• Por design, se o bot não responder ou dar suporte a nenhum comando de usuário e for um bot de uma maneira única, o bot só pretende notificar os usuários. Você deve definir isNotificationOnly como true no manifesto do aplicativo. [Correção Obrigatória]

  

  

• A experiência do usuário do bot não deve ser quebrada em plataformas móveis. Seu bot deve estar totalmente responsivo no celular. [Correção Obrigatória]

Dica

Quanto aos bots pessoais, inclua uma guia Ajuda que descreve ainda mais o que seu bot pode fazer.

Mensagens de boas-vindas do bot

• Se o aplicativo tiver um fluxo de configuração complexo (requer uma licença corporativa ou não tem um fluxo de inscrição intuitivo), os bots nesses aplicativos sempre deverão enviar uma mensagem de boas-vindas durante a primeira execução.

  Para obter a melhor experiência, a mensagem de boas-vindas deve incluir o valor oferecido pelo bot aos usuários, que instalaram o bot no canal, como configurar o bot e descrever brevemente todos os comandos de bot com suporte. Você pode exibir a mensagem de boas-vindas usando um Cartão Adaptável com botões para melhorar a usabilidade. Para obter mais informações, consulte como acionar uma mensagem de boas-vindas do bot. Para aplicativos sem um fluxo de configuração complexo, você pode optar por disparar uma mensagem de boas-vindas durante a experiência de primeira execução do bot. No entanto, se uma mensagem de boas-vindas for disparada, ela deverá seguir as diretrizes da mensagem de boas-vindas.

  

  

• As mensagens de boas-vindas do bot em canais e bate-papos são opcionais durante a primeira execução, especialmente se o bot estiver disponível para uso pessoal e executar ações semelhantes. Seu bot não deve enviar mensagens de boas-vindas aos usuários individualmente (é considerado spam). A mensagem também deve mencionar a pessoa que adicionou o bot.

  

  

• Somente bots de notificação devem enviar uma mensagem de boas-vindas que esclarece que o bot é apenas um bot de notificação e os usuários não poderão interagir com o bot. [Correção Obrigatória]

  

• A mensagem de boas-vindas não deve acabar com o usuário. A mensagem de boas-vindas deve incluir o valor oferecido pelo bot aos usuários que instalaram o bot no canal, como configurar o bot e descrever brevemente todos os comandos de bot com suporte. Você pode exibir a mensagem de boas-vindas usando um Cartão Adaptável com botões para melhorar a usabilidade. [Correção Obrigatória]

  

  

• O bot instalado em um canal ou escopo de chat em grupo não deve enviar uma mensagem de boas-vindas proativa a todos os membros da equipe no chat 1:1. [Correção Obrigatória]

  

• Somente o bot de notificação pode enviar uma mensagem de boas-vindas proativa em um canal somente se a mensagem contiver informações importantes para qualquer usuário concluir a configuração do bot ou esclarecer os cenários quando as notificações forem disparadas. [Correção Obrigatória]

• O bot instalado em um canal ou escopo de chat em grupo não deve enviar mensagens proativas (não apenas mensagens de boas-vindas) irrelevantes para todos os usuários no chat de canal ou grupo, em vez disso, deve enviar mensagens proativas para o usuário durante o chat 1:1. [Correção Obrigatória]

• O bot instalado em um escopo de chat de canal ou grupo não deve permitir que os usuários iniciem fluxos de trabalho individuais. Os bots devem concluir fluxos de trabalho individuais no chat 1:1 com o usuário. [Correção Obrigatória]

• A mensagem de boas-vindas do bot deve chamar claramente as limitações relacionadas ao uso do bot no escopo instalado. [Correção Obrigatória]

  

  

• A mensagem de boas-vindas deve disparar automaticamente na instalação do aplicativo em um escopo pessoal. Se o bot não enviar uma mensagem de boas-vindas em um escopo pessoal, o usuário levará a um beco sem saída. Se o aplicativo não incluir um fluxo de trabalho de configuração complexo, será opcional que o desenvolvedor acione uma mensagem de boas-vindas no escopo do canal ou do chat em grupo. [Correção Obrigatória]

  

• As mensagens de boas-vindas devem ser disparadas apenas uma vez na instalação do bot. Mensagens de boas-vindas não devem ser disparadas sempre que o usuário invoca o comando de ajuda. A resposta de comando de ajuda deve estar focada para incluir uma maneira de o usuário acessar a ajuda relacionada ao bot. [Correção Obrigatória]

• Mensagens de boas-vindas não devem ser disparadas com todos os comandos de bot. Isso é considerado spam. [Correção Obrigatória]

  

• O conteúdo da mensagem de boas-vindas deve estar relacionado ao fluxo de trabalho do bot mencionado na longa descrição do aplicativo e no escopo de instalação. A mensagem de boas-vindas deve incluir o valor oferecido pelo bot aos usuários que instalaram o bot no canal, como configurar o bot e descrever brevemente todos os comandos de bot com suporte. [Correção Obrigatória]

• O bot não deve enviar várias mensagens de boas-vindas quando disparado na instalação do aplicativo. [Correção Obrigatória]

  

• O nome do aplicativo na mensagem de boas-vindas deve corresponder ao nome do aplicativo no manifesto do aplicativo. [Correção Obrigatória]

  

• A mensagem de boas-vindas não deve exibir nomes de plataforma colaborativa baseados em chat concorrente, a menos que o aplicativo forneça interoperabilidade específica.

• A mensagem de boas-vindas não deve redirecionar o usuário para outro aplicativo do Teams, em vez disso, a mensagem de boas-vindas deve estimular o usuário a concluir sua primeira tarefa e descrever brevemente todos os comandos de bot com suporte no aplicativo. [Correção Obrigatória]

• A mensagem de boas-vindas não deve conter links para nenhum marketplace de aplicativos, incluindo o AppSource. [Correção Obrigatória]

• Se seu aplicativo tiver um fluxo de trabalho de configuração complexo que requer a instalação liderada por administradores, não tiver um fluxo de inscrição intuitivo e prontamente disponível ou exigir que os usuários concluam as etapas de configuração fora da experiência do Teams e retornem, o bot deve enviar uma mensagem de boas-vindas proativa em um escopo de chat de equipe ou grupo após a instalação. [Correção Obrigatória]

• Se o bot enviar uma mensagem de boas-vindas no canal, ele não deverá enviá-lo aos usuários individualmente (é considerado spam). A mensagem de boas-vindas também deve menção a pessoa que adicionou o bot. [Correção Sugerida]

Dica

Em mensagens de boas-vindas a usuários individuais, um tour por carrossel pode fornecer uma visão geral eficaz do bot e de qualquer outro recurso de aplicativo para incentivar os usuários a experimentar comandos de bot. Por exemplo, Criar uma tarefa.

Spam de mensagem de bot

Os bots não devem enviar spam aos usuários enviando várias mensagens em curta duração.

• Mensagens de bot em canais e bate-papos: não enviar spam aos usuários criando postagens separadas. Crie uma única postagem com respostas na mesma conversa. [Correção Obrigatória]

  

  

• Mensagens de bot em aplicativos pessoais:

  • Não envie várias mensagens em sequência rápida. [Correção Obrigatória]

    

  • Envie uma mensagem com informações completas. [Correção Obrigatória]

  • Evite conversas de vários turnos para concluir um único fluxo de trabalho repetitivo. [Correção Obrigatória]

  • Use um formulário (ou caixa de diálogo) para coletar todas as entradas de um usuário ao mesmo tempo. [Correção Obrigatória]

  • Chatbots conversacionais baseados em NLP podem usar conversas de vários turnos para tornar a discussão mais envolvente e concluir um fluxo de trabalho.

    

    

• Mensagens de boas-vindas: não repita a mesma mensagem de boas-vindas em intervalos regulares. Por exemplo, quando um novo membro é adicionado a uma equipe, não crie spam para outros membros com uma mensagem de boas-vindas. Envie uma mensagem ao novo membro pessoalmente. [Correção Obrigatória]

  

Notificações de bot

As notificações de bot devem incluir conteúdo relevante ao escopo definido pelo bot (equipe, bate-papo ou pessoal). [Correção Obrigatória]

Bots e cartões adaptáveis

Os Cartões Adaptáveis são uma forma altamente recomendada de exibir mensagens de bot. Os cartões devem ser leves e incluir apenas até seis ações. Para exibir mais conteúdo, considere usar uma caixa de diálogo ou uma guia.

Para obter mais informações sobre cartões, consulte:

• Design dos Cartões Adaptáveis
• Referência dos cartões

A experiência do bot deve ser totalmente responsiva em dispositivos móveis. As respostas do bot devem fornecer uma maneira de avançar quando aplicável. O bot deve ser responsivo e falhar com uma mensagem de erro normal para falhas. As mensagens de bot enviadas no escopo pessoal para a base do usuário em gatilhos em um escopo colaborativo devem fornecer informações contextuais (incluindo a origem ’ da mensagem).

Bots somente de notificação

Aplicativos que consistem em bots somente de notificação fornecem valor ao usuário disparando notificações do usuário com base em determinados gatilhos ou eventos no aplicativo principal ou back-end. Por exemplo, um novo cliente potencial de vendas é adicionado para a equipe de vendas acompanhar. Um bot somente de notificação de alta qualidade notifica os usuários regularmente sobre determinadas conclusões de eventos, como preenchimentos de fluxo de trabalho ou alertas.

Dica

Visualizar informações e fornecer ações básicas do usuário de linha no cartão postado para que o usuário não seja obrigado a navegar fora do Teams para todas as ações (independentemente da complexidade).

Informações de metadados do bot

• As informações do bot no manifesto do aplicativo (nome do bot, logotipo, link de privacidade e termos de vínculo de serviço) devem ser consistentes com os metadados do Bot Framework. [Correção Obrigatória]

• Verifique se a ID do bot no manifesto do aplicativo corresponde à ID do bot na última versão publicada da Teams Store do seu aplicativo. A alteração de IDs de bot em uma atualização de aplicativo leva à perda permanente de todo o histórico de interação do usuário com o bot para usuários existentes do aplicativo e inicia uma nova cadeia de conversas com a nova ID do Bot. [Correção Obrigatória]

• Qualquer alteração no nome do aplicativo, metadados, mensagem de boas-vindas do bot ou respostas de bot deve ser atualizada com novo nome. [Correção Obrigatória]

• O nome do aplicativo na mensagem de boas-vindas do bot ou respostas de bot deve corresponder ao nome do aplicativo no manifesto do aplicativo. [Correção Obrigatória]

Bot no escopo colaborativo

• A instalação do bot em um canal ou escopo de chat em grupo para obter a lista de equipes para o envio de notificações proativas para usuários, pois chats 1:1 para gatilhos específicos da equipe não são permitidos. Por exemplo, aplicativo que emparelha pessoas para um meetup. [Correção Obrigatória]

• Bot em um canal ou um chat em grupo usado apenas para obter as mensagens ou postagens para enviar notificações proativas para usuários, pois chats 1:1 não são permitidos. [Correção Obrigatória]

• Os bots instalados no escopo colaborativo devem fornecer um valor de usuário no escopo colaborativo. [Correção Obrigatória]

Voltar para o início

Extensões de mensagens

Esta seção está em linha com a política de marketplace comercial da Microsoft número 1140.4.4.

Se o aplicativo incluir uma extensão de mensagem, verifique se ele segue essas diretrizes.

Dica

Para obter mais informações sobre como criar uma experiência de aplicativo de alta qualidade, consulte as diretrizes de design de extensão de mensagens do Teams.

Diretrizes de design de extensões de mensagens

• Se o aplicativo teams usar o recurso de extensão de mensagens, seu aplicativo deverá seguir as diretrizes de design de extensão de mensagens.

  

• Extensões de mensagens são atalhos para inserir conteúdo do aplicativo ou agir em uma mensagem sem sair da conversa. Mantenha a extensão de mensagens simples e exiba apenas os componentes necessários para concluir efetivamente a ação. O site completo não deve ser enquadrado em I na extensão de mensagens. [Correção Obrigatória]

• As imagens de visualização em Cartões Adaptáveis em extensões de mensagens devem ser carregadas corretamente. [Correção Obrigatória]

  

  

• A resposta de extensão de mensagens cartão deve incluir o ícone do aplicativo para evitar confusão do usuário final. [Correção Obrigatória]

• Seu aplicativo não deve ter nenhuma funcionalidade quebrada. O aplicativo não deve ser sem saída nem impedir que o usuário conclua um fluxo de trabalho em uma extensão de mensagens. [Correção Obrigatória]

• As extensões de mensagens devem responder ou funcionar conforme o planejado em escopos de chat em grupo e canal. [Correção Obrigatória]

• Você deve incluir uma maneira de o usuário entrar ou sair da extensão de mensagens. [Correção Obrigatória]

• As extensões de mensagem que usam urls OpenAPI não devem fornecer redirecionamento em nenhuma chamada de API. As chamadas de API reais devem ser atendidas do mesmo domínio ou subdomínio do domínio raiz.

Comandos de ação para extensões de mensagem baseadas em ação

As extensões de mensagens baseadas em ação devem fazer o seguinte:

• Permitir que os usuários disparem ações em uma mensagem sem concluir etapas intermediárias, como entrar.

  

  

• Transferir o contexto da mensagem ao próximo estado de trabalho. [Correção Obrigatória]

  

  

• Incorpore o nome do aplicativo host em vez de um verbo genérico para comandos de ação disparados de uma mensagem de chat, postagem de canal ou chamada para ação em aplicativos. Por exemplo, use Iniciar um Reunião do Skype para Iniciar Reunião, Carregar arquivo no DocuSign para Carregar arquivo. [Correção Sugerida]

  

  

• Invocar uma ação de mensagem deve permitir que o usuário conclua o fluxo de trabalho. Erros, respostas em branco ou indicadores de carregamento contínuo para tornar a ação da mensagem funcional, conforme pretendido, não devem estar presentes. [Correção Obrigatória]

  

• Comandos de ação duplicados não devem estar presentes. [Correção Obrigatória]

• As ações de mensagem devem permitir que o usuário conclua o fluxo de trabalho conforme pretendido sem uma resposta inválida. [Correção Obrigatória]

• Aplicativos com apenas extensão de mensagens baseadas em ação devem ter o seguinte estado final:

  • Poste uma ação relevante como uma notificação no contexto em que a extensão da mensagem é invocada ou no chat de bot 1:1 com base no cenário do usuário. [Correção Obrigatória]

  • Permitir que os usuários compartilhem cartões com outros usuários com base na ação tomada. Isso é para garantir que os aplicativos não tomem ações silenciosas. Por exemplo, um tíquete é criado com base em uma mensagem em um canal, mas o aplicativo não envia uma notificação ou não fornece uma maneira de solicitar que o usuário compartilhe detalhes do tíquete após a criação do tíquete. [Correção Obrigatória]

Links de visualização (unfurling de link)

[Correção Obrigatória]

• Se o aplicativo tiver declarado a supportsAnonymizedPayloads propriedade no manifesto do aplicativo e o usuário não tiver instalado o aplicativo, o link do aplicativo deverá se desenrolar e mostrar a caixa de diálogo adicionar aplicativo depois que o cartão for selecionado. [Correção Obrigatória]

• As extensões de mensagens devem visualizar links reconhecidos na caixa de redação do Teams. Não adicione domínios que estão fora do seu controle (URLs absolutas ou curingas). Por exemplo, yourapp.onmicrosoft.com é válido, *.onmicrosoft.com não é válido. Domínios de nível superior também são proibidos. Por exemplo: *.com ou *.org. [Correção Obrigatória]

• Os aplicativos só devem declarar que estão sob a propriedade direta do editor de aplicativos na messageHandler seção de desenrolamento de link do manifesto do aplicativo. Ele não deve conter *.botframework.com. [Correção Obrigatória]

comandos Pesquisa

• Extensões de mensagens baseadas em pesquisa devem fornecer texto que ajude os usuários a pesquisar com eficiência. [Correção Obrigatória]

  

  

• @mention executáveis devem ser claros, fáceis de entender e legíveis.

  

Voltar para o início

Diálogos

[Correção Obrigatória]

Esta seção está em linha com a política de marketplace comercial da Microsoft número 1140.4.5.

Expandir para saber mais

Uma caixa de diálogo (conhecida como módulo de tarefa no TeamsJS v1.x) deve incluir um ícone e o nome curto do aplicativo ao qual ele está associado. As caixas de diálogo não devem inserir um aplicativo inteiro e exibir apenas os componentes necessários para concluir uma ação específica.

Para obter mais informações, consulte Diretrizes de design da caixa de diálogo do Teams.

Dica

Para obter mais informações sobre como criar uma experiência de aplicativo de alta qualidade, confira Diretrizes de design do módulo de tarefas do Teams.

Voltar para o início

Extensões de reunião

Esta seção está em linha com a política de marketplace comercial da Microsoft número 1140.4.6.

Dica

Para obter mais informações sobre como criar uma experiência de aplicativo de alta qualidade, confira as diretrizes de design de extensão de reunião do Teams.

Diretrizes de design de extensão de reunião

• Seus aplicativos do Teams devem seguir as diretrizes de design de extensão de reunião.

• Com a experiência do aplicativo em reunião, você pode envolver os participantes durante a reunião usando guias de reunião, caixa de diálogo e o recurso de compartilhamento na reunião para o estágio. Se seu aplicativo dá suporte à extensão de reunião do Teams, você deve fornecer uma experiência de reunião responsiva alinhada com a experiência de reunião do Teams. [Correção Obrigatória]

• Os aplicativos de extensibilidade de reunião devem oferecer uma experiência de reunião responsiva alinhada à experiência de reunião do Teams. A experiência na reunião é obrigatória para um aplicativo do Teams que dá suporte à extensibilidade da reunião, mas experiências pré e pós-reunião não são obrigatórias. [Correção Obrigatória]

  • Com a experiência de aplicativo de pré-reunião, os usuários podem encontrar e adicionar aplicativos de reunião. Os usuários também podem executar tarefas de pré-reunião, como desenvolver uma pesquisa para examinar os participantes da reunião. Se seu aplicativo fornecer uma experiência de pré-reunião, ele deverá ser relevante para o fluxo de trabalho da reunião.

  • Com a experiência do aplicativo pós-reunião, os usuários podem exibir os resultados da reunião, como resultados da pesquisa de pesquisa ou comentários e outros conteúdos do aplicativo. Se seu aplicativo fornecer uma experiência pós-reunião, ele deverá ser relevante para o fluxo de trabalho da reunião.

  • Com a experiência do aplicativo na reunião, você pode envolver os participantes da reunião durante a reunião e aprimorar a experiência de reunião para todos os participantes. Os participantes não devem ser levados para fora da reunião do Teams para concluir os principais fluxos de trabalho do usuário do seu aplicativo.

  

• Seu aplicativo deve oferecer valor além de fornecer apenas cenas personalizadas do Modo Juntos no Teams. [Correção Obrigatória]

• Você deve declarar groupChat como um escopo em configurableTabs e meetingDetailsTab, meetingChatTabe meetingSidePanel como uma propriedade de contexto no manifesto do aplicativo para habilitar seu aplicativo para reuniões no teams móvel. [Correção Obrigatória]

• As telas da reunião não devem acabar com um participante da reunião. As telas de reunião devem mostrar uma mensagem de falha graciosa para limitações de aplicativo, como dependência específica da região. [Correção Obrigatória]

• O cabeçalho da tela da reunião deve exibir o nome correto do aplicativo para evitar confundir o participante da reunião. [Correção Obrigatória]

• Você deve incluir uma opção para o usuário sair ou sair da extensão de reunião. [Correção Obrigatória]

• As guias de reunião em plataformas móveis devem incluir fluxos de trabalho relevantes. Páginas em branco não devem estar presentes em uma guia de reunião. [Correção obrigatória]

• O estágio de reunião é uma tela de participação focada, intuitiva e colaborativa. O estágio de reunião não deve inserir a experiência completa do site. [Correção Obrigatória]

• O aplicativo não deve mostrar a tela de carregamento contínua, o erro ou a funcionalidade quebrada que acaba com o usuário ou bloqueia a conclusão de um fluxo de trabalho em um cenário de reunião. [Correção Obrigatória]

  

• O aplicativo não deve abrir uma nova instância do Teams ao iniciar uma reunião. As telas de reunião são uma extensão dos recursos do Teams que promovem a colaboração em tempo real e novas reuniões devem sempre ser abertas na instância do Teams atualmente ativa. [Correção Obrigatória]

• Os aplicativos de reunião devem concluir fluxos de trabalho na plataforma do Microsoft Teams sem redirecionar para plataformas baseadas em chat concorrentes. [Correção Obrigatória]

  

• Se o aplicativo der suporte a exibições baseadas em função e determinados fluxos de trabalho não estiverem disponíveis para todos os participantes, recomendamos que você implemente mensagens adequadas para participantes na guia e no painel lateral informando que o aplicativo é para exibição do organizador e forneça detalhes sobre como os participantes recebem as anotações da reunião, itens de ação e agendas de atualização. [Correção Obrigatória]

  

Experiência pré e pós-reunião

• As telas de pré e pós-reunião devem seguir as diretrizes gerais de design de guia. Para obter mais informações, confira diretrizes de design do Teams. [Correção Obrigatória]

• As guias devem ter um layout organizado ao exibir vários itens. Por exemplo, mais de 10 enquetes ou pesquisas, veja o layout de exemplo. [Correção Obrigatória]

• Seu aplicativo deve notificar os usuários quando os resultados de uma pesquisa ou votação são exportados, declarando Resultados baixados com êxito. [Correção Obrigatória]

  

Experiência em reunião

• Os aplicativos só devem usar um tema escuro durante as reuniões. Para obter mais informações, confira diretrizes de design do Teams. [Correção Obrigatória]

• Uma dica de ferramenta deve exibir o nome do aplicativo ao passar o mouse sobre o ícone do aplicativo durante as reuniões. [Correção Obrigatória]

  

• As extensões de mensagens devem funcionar da mesma forma durante as reuniões, assim como fora delas. [Correção Obrigatória]

Guias de reunião

• Deve responder. [Correção Obrigatória]

• Deve manter o preenchimento e os tamanhos dos componentes. [Correção Obrigatória]

• Deve ter um botão Voltar se houver mais de uma camada de navegação. [Correção Obrigatória]

  

  

• Não deve incluir mais de um botão fechar. Isso pode confundir os usuários, já que já há um botão de cabeçalho interno para descartar a guia. [Correção Obrigatória]

• Não deve ter rolagem horizontal. [Correção Obrigatória]

  

  

Caixas de diálogo na reunião

• Deve ser usado com moderação e para cenários que são leves e orientados a tarefas. [Correção Obrigatória]

• Deve exibir o conteúdo em uma única coluna e não possuir vários níveis de navegação. [Correção Obrigatória]

  

  

• Não deve usar caixas de diálogo. [Correção Obrigatória]

• Deve alinhar-se ao centro do estágio da reunião. [Correção Obrigatória]

  

• Deve ser ignorado depois que um usuário seleciona um botão ou executa uma ação. [Correção Obrigatória]

• Modo juntos: verifique se você considera as seguintes práticas recomendadas para uma experiência de construção de cena: [Correção Obrigatória]

  • Todas as imagens estão no formato .png.
  • O pacote final com todas as imagens montadas não deve exceder a resolução 1920x1080. A resolução é um número par. Essa resolução é um requisito para que as cenas sejam mostradas com êxito.
  • O tamanho máximo da cena é de 10 MB.
  • O tamanho máximo de cada imagem é de 5 MB. Uma cena é uma coleção de várias imagens. O limite é para cada imagem individual.
  • Selecione Transparente conforme necessário. Essa caixa de seleção está disponível no painel direito quando uma imagem é selecionada. As imagens sobrepostas devem ser marcadas como Transparentes para indicar que estão sobrepondo imagens na cena.

Estágio de Reunião Compartilhada

Para usar a API shareAppContentToStage , você deve declarar as permissões RSC corretas. No manifesto do aplicativo, você deve configurar a authorization propriedade. Atualize a name propriedade como MeetingStage.Write.Chat e type a propriedade como Delegated no resourceSpecific campo. [Correção Obrigatória]

O recurso de estágio de reunião compartilhada só pode ser iniciado por meio do aplicativo da área de trabalho do Teams. No entanto, a experiência de consumo do estágio de reunião compartilhada deve ser utilizável e não interrompida quando exibida em dispositivos móveis. [Correção Obrigatória]

Voltar para o início

Conector

1. O nome do conector deve ser o mesmo que o nome do aplicativo no aplicativo e no manifesto do aplicativo.

   

2. O usuário não deve encontrar nenhum erro ao configurar o conector.

   

Notificações

Esta seção está em linha com a política de marketplace comercial da Microsoft número 1140.4.7.

Se o aplicativo usar as APIs de feed de atividades fornecidas pelo Microsoft Graph, verifique se ele segue as diretrizes a seguir.

Dica

Se seus aplicativos dão suporte a cenários de notificação em que as notificações são disparadas após longos intervalos, por exemplo, após um dia ou um mês. Antes de enviar para revisão, verifique se você dispara essas notificações em segundo plano para testar as notificações.

Diretrizes de design de notificação

• Os aplicativos do Teams devem seguir as diretrizes de design de notificações do feed de atividades.

• Fluxo de trabalho irrelevante, impróprio, sem resposta ou quebrado não deve estar presente depois que o usuário selecionar uma notificação no feed de atividades do Teams. Os usuários não devem ser impedidos de concluir um fluxo de trabalho depois de selecionar uma notificação do feed de atividades. [Correção Obrigatória]

• Inclua o nome do aplicativo na notificação do feed de atividades para os usuários finais entenderem a origem ou o gatilho da notificação sem confusão. [Correção Obrigatória]

• O aplicativo deve disparar notificações para todos os cenários de notificação mencionados na descrição longa do aplicativo, experiência de execução do aplicativo e em cenários declarados activityTypes no manifesto do aplicativo. [Correção Obrigatória]

• As notificações devem ser exibidas em cinco segundos a partir da ação do usuário. [Correção Obrigatória]

• Você deve chamar limitações de notificação (se houver) na descrição longa do aplicativo ou na primeira experiência de execução do aplicativo. [Correção Obrigatória]

Geral

• Todos os gatilhos de notificação especificados na configuração do aplicativo devem funcionar. [Correção Obrigatória]
• As notificações devem ser localizadas de acordo com os idiomas suportados configurados no seu aplicativo. [Correção Obrigatória]
• As notificações devem ser exibidas em cinco segundos a partir da ação do usuário. [Correção Obrigatória]
• As notificações devem ser localizadas de acordo com os idiomas com suporte para todas as plataformas em que seu aplicativo é compatível. [Correção Obrigatória]

Avatares

• O avatar de notificação deve corresponder ao ícone de cor do aplicativo. [Correção Obrigatória]
• As notificações disparadas por um usuário devem incluir o avatar do usuário. [Correção Obrigatória]

Spam

• Os aplicativos não devem enviar mais de 10 notificações por minuto para um usuário. [Correção Obrigatória]
• Bots e o feed de atividades não devem disparar notificações duplicadas. [Correção Obrigatória]
• As notificações devem fornecer valor aos usuários e não devem ser usadas em eventos triviais ou irrelevantes. [Correção Obrigatória]

Navegação e layout

• As notificações devem aderir ao layout e à experiência do feed de atividades do Teams. [Correção Obrigatória]
• Ao selecionar uma notificação, o usuário deve ser direcionado ao conteúdo relevante no Teams. [Correção Obrigatória]

Voltar para o início

Programa de Conformidade do Aplicativo do Microsoft 365

Esta seção está em linha com a política de marketplace comercial da Microsoft número 1140.6.

Expandir para saber mais

O Programa de Conformidade dos Aplicativos do Microsoft 365 tem como objetivo ajudar as organizações a avaliarem e gerenciarem riscos através da avaliação de informações de segurança e conformidade do seu aplicativo. Se você estiver publicando um aplicativo na Teams Store, deverá concluir as seguintes camadas do programa:

• Verificação do Editor: ajuda os administradores e usuários finais a entenderem a autenticidade dos desenvolvedores de aplicativos que se integram à plataforma de identidade da Microsoft. Quando concluído, um selo verificado azul é exibido na caixa de diálogo Microsoft Entra consentimento e em outras telas. Para obter mais informações, consulte Marcar seu aplicativo como verificado pelo editor. [Correção Obrigatória]

  

• Atestado do Editor: um processo no qual você compartilha informações gerais, de tratamento de dados, e de segurança e conformidade para ajudar os clientes em potencial a tomarem decisões informadas sobre como usar seu aplicativo. [Correção Sugerida]

Para um aplicativo que não está listado anteriormente, você não pode concluir o Publisher Attestation até que o aplicativo esteja disponível na Teams Store. Se você estiver atualizando um aplicativo já listado, conclua o Publisher Attestation antes de enviar a versão mais recente do aplicativo.

Voltar para o início

Publicidade

Esta seção está alinhada com a política do marketplace comercial da Microsoft número 1140.7.

Os aplicativos não devem exibir publicidade, incluindo anúncios dinâmicos, anúncios de faixa e anúncios na mensagem. [Correção Obrigatória]

Voltar para o início

Aplicativos baseados em criptomoedas

Você deve demonstrar a conformidade com todas as leis em que seu aplicativo é distribuído, se seu aplicativo: [Correção Obrigatória]

• Facilita transações ou transmissões de criptomoedas no aplicativo.

• Promove conteúdo relacionado à criptomoeda.

• Permite que os usuários armazenem ou acessem sua criptomoeda armazenada.

• Incentiva ou permite que os usuários concluam uma transação ou transmissão baseada em criptomoedas fora da plataforma do Teams.

• Incentiva ou facilita a mineração de tokens de criptomoeda.

• Facilita a participação do usuário em Ofertas Iniciais de Moedas.

• Recompensa ou incentiva usuários com tokens de criptomoeda para concluir uma tarefa.

Após uma revisão interna da Microsoft, se a demonstração de conformidade for satisfatória, a Microsoft poderá prosseguir com a certificação adicional do seu aplicativo. Se a demonstração de conformidade for insatisfatória, a Microsoft mantém você informado da decisão de não prosseguir com a certificação do seu aplicativo.

Voltar para o início

Funcionalidade do aplicativo

• Fluxos de trabalho ou conteúdo no aplicativo devem estar relacionados ao escopo. [Correção Obrigatória]
• Todos os recursos do aplicativo devem ser funcionais e devem funcionar corretamente, conforme descrito na descrição longa do manifesto AppSource ou aplicativo. [Correção Obrigatória]
• Os aplicativos devem sempre notificar o usuário antes de baixar qualquer arquivo ou executável no ambiente do usuário. Qualquer CTA (chamada à ação), baseada em texto ou não, que deixa claro para o usuário que um arquivo ou executável é baixado na ação do usuário é permitido no aplicativo. [Correção Obrigatória]
• Os aplicativos com dependência de região devem notificar os usuários com uma mensagem de falha graciosa em todos os recursos aplicáveis se tentarem usá-la em uma região sem suporte. [Correção Obrigatória]

Voltar para o início

Experiência móvel

• Os suplementos móveis devem ser gratuitos. Não deve haver nenhum conteúdo no aplicativo ou links que promovam a venda, lojas online ou outras solicitações de pagamento. Todas as contas necessárias para aplicativos não devem ter nenhum custo para uso e, se tiverem tempo limitado, não devem incluir nenhum conteúdo que indique a necessidade de pagamento. [Correção Obrigatória]

  

• O uso da palavra FREE, FREE TRIAL ou TRY FREE é permitido na experiência de desktop ou aplicativo Web sem qualquer limitação ou consideração.

• O uso da palavra FREE como texto simples no contexto de uma avaliação ou atualização de aplicativo é permitido no celular.

• O uso da palavra FREE no contexto de uma avaliação ou atualização de aplicativo com um link que leva a uma página de destino sem informações de pagamento ou preços é permitido no celular. O texto simples para sinalizar aplicativo é PAGO é permitido no celular.

• O uso da palavra FREE como texto simples no contexto de uma avaliação ou atualização de aplicativo e associado a detalhes de preços não é permitido no celular. [Correção Obrigatória]

• O uso da palavra FREE no contexto de uma avaliação ou atualização de aplicativo e associado a um link que leva a uma página de destino com informações de preço ou detalhes de pagamento no celular não é permitido. [Correção Obrigatória]

• Detalhes de preço no celular em qualquer formato, por exemplo, imagem, texto ou link não são permitidos. CTA, como exibir planos no celular, não é permitido. Informações sobre planos sem detalhes de preços, mas com um link de contato ou email no celular não são permitidas. Qualquer texto com detalhes de contato vinculando ou alusão a uma atualização paga não é permitido no celular. Pagamentos para bens físicos são permitidos no celular. Por exemplo, seu aplicativo pode permitir que o pagamento reserve um táxi. [Correção Obrigatória]

  

• Pagamentos para bens digitais no aplicativo não são permitidos no celular. [Correção Obrigatória]

  

• Os aplicativos do Teams devem oferecer uma experiência móvel entre dispositivos apropriados. [Correção Obrigatória]

• Os recursos que não têm suporte no celular não devem acabar com um usuário sem saída e devem fornecer uma mensagem de falha graciosa quando aplicável. [Correção Obrigatória]

Voltar para o início

Aplicativos estendidos entre clientes do Microsoft 365

Geral

• Os aplicativos destinados a estender aplicativos do Teams entre clientes do Microsoft 365 devem usar o esquema versão 1.13 ou posterior.

• A URL de suporte do aplicativo deve conter conteúdo relevante para o aplicativo teams extensível entre clientes do Microsoft 365 e não deve chamar apenas um único cliente.

• Você deve fornecer referência relevante ao aplicativo teams extensível entre clientes do Microsoft 365 na descrição do aplicativo.

• Se o aplicativo do Teams for extensível entre clientes do Microsoft 365, o conteúdo fornecido no início do aplicativo, entrar, se inscrever, sair, ajudar páginas ou encaminhar mensagens deve chamar todos os clientes.

Compatibilidade

Os aplicativos do Teams extensíveis entre clientes do Microsoft 365 devem ser totalmente responsivos e funcionais nas versões mais recentes dos clientes do Microsoft Edge e do Google Chrome. O usuário deve ser capaz de invocar e continuar a usar guias pessoais ou extensões de mensagem no seguinte:

• Outlook para Windows e Web.
• Microsoft 365 na área de trabalho, Web e Android.
• Microsoft Teams na área de trabalho e na Web.
• Microsoft Teams no Android e iOS.

Experiência móvel

Os usuários devem ser capazes de iniciar o aplicativo no menu de sobrevoo de ações no cliente do Microsoft 365 no celular. O nome do aplicativo deve ser exibido corretamente na barra de ações. [Correção Obrigatória]

Lançamento de aplicativo do flyout de ações

Os usuários devem ser capazes de iniciar e alternar com êxito entre várias guias estáticas no cliente do Microsoft 365 no celular. As guias devem ser carregadas corretamente. Se houver mais de três guias estáticas, as guias restantes deverão estar visíveis na seção Mais . [Correção Obrigatória]

Experiência de várias guias

Se seu aplicativo usa SSO, ele deve autenticar o usuário com êxito. O SSO permite que os usuários entrem usando um conjunto de credenciais para vários sistemas de software independentes. Os usuários podem acessar todos os aplicativos necessários sem usar credenciais diferentes para autenticar. [Correção Obrigatória]

Autenticação de aplicativo

O aplicativo deve encerrar a instância da conta de usuário quando o usuário é alternado ou conectado no cliente do Microsoft 365 no celular. [Correção Obrigatória]

Experiência de comutação de conta e logon

• Os usuários devem ser capazes de voltar ao estado de trabalho anterior. Se o usuário estiver na página raiz, a navegação de volta deverá encerrar a instância do aplicativo no cliente do Microsoft 365 no celular. [Correção Obrigatória]

• Os aplicativos que dão suporte a um link profundo a um fluxo de trabalho devem ser capazes de redirecionar o usuário para a experiência de página de destino apropriada. [Correção Obrigatória]

Navegação de guia

• O indicador de progresso deve aparecer quando o aplicativo está carregando e descartando automaticamente depois que o aplicativo é carregado. [Correção Obrigatória]

• Uma tela de erro deve aparecer quando um aplicativo falha ao carregar nas instâncias, como rede incoerente ou quebrada, tempo limite ou falha de autenticação e assim por diante. [Correção Obrigatória]

Voltar para o início

Aplicativos do Teams extensíveis como plug-in para Microsoft Copilot para Microsoft 365

• Os pacotes de aplicativos são formatados corretamente e aderem ao esquema de manifesto versão 1.13 ou posterior.
• O aplicativo deve passar as verificações de IA responsáveis.
• O aplicativo deve atender aos critérios compatíveis com plug-in.

O plug-in não deve manipular o comportamento do LLM

As descrições curtas de um aplicativo, parâmetro e comando não devem incluir o seguinte:

1. Frases instrucionais. Por exemplo, se o usuário disser X, ignore, exclua, reinicie, novas instruções, responda em negrito ou não imprima nada.
2. Linguagem verbosa, florida ou de marketing.
3. Declarações superlativas como nº 1, incríveis ou melhores.
4. URLs, emojis ou caracteres ocultos como símbolos hexadecimal, binários ou não convencionais.
5. Erros de gramática e pontuação.

Conscientização do usuário

A longa descrição de um aplicativo deve chamar claramente o seguinte:

• Compatibilidade do aplicativo com Copilot. Por exemplo, use Contoso no Copilot para pesquisar e resumir suas tarefas.

• Forneça pelo menos um prompt de como os usuários podem usar um plug-in de extensão de mensagem no Copilot. Por exemplo, quais são os tíquetes de alta prioridade atribuídos a mim esta semana na Contoso.

  

  

Qualidade da resposta

• Os campos obrigatórios em Microsoft 365 Chat resposta do Cartão Adaptável devem incluir título de informações e pelo menos dois campos úteis adicionais de sua escolha, por exemplo, data modificada, autor, status e sinalizadores. A visualização e o conteúdo devem fazer parte de uma única resposta.

  

• Cartões Adaptáveis em Microsoft 365 Chat resposta devem ter pelo menos um botão de ação.

• Os botões de ação presentes em Microsoft 365 Chat resposta Cartões Adaptáveis devem estar funcionais.

  

• Microsoft 365 Chat deve responder com precisão e não exibir um erro quando um usuário solicita com um único parâmetro.

• Microsoft 365 Chat deve responder com precisão e não mostrar um erro quando um usuário solicita com um parâmetro multi.

• Microsoft 365 Chat deve responder com precisão e não mostrar um erro quando um usuário solicita com um acompanhamento.

• A extensão de mensagem deve conter pelo menos dois parâmetros para uma experiência avançada do usuário em Microsoft 365 Chat.

Voltar para o início

Próxima etapa

Criar uma conta do Partner Center

Confira também

• Testar e depurar seu aplicativo
• Distribuir seu aplicativo
• Preparar o envio do Teams Store
• Incluir uma oferta de SaaS com seu aplicativo Teams
• Planejar e executar o crescimento do seu aplicativo