Diretrizes de validação da Teams Store

As guias devem fornecer valor além de hospedar um site existente. [Deve corrigir]

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 exigem que o usuário navegue para fora do Teams para todo o resto não fornecem valor significativo dentro do Teams.

[Deve corrigir]

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 na validação de um aplicativo somente de extensão de mensagem baseada em pesquisa, os itens a seguir são necessários como linha de base para garantir que a experiência do usuário não seja interrompida. 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.

   

   

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 ele der suporte apenas ao descompactação de links e não tiver nenhuma outra funcionalidade.

O nome de um aplicativo desempenha um papel fundamental 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. [Deve corrigir]

• Prefixo ou sufixo substantivos comuns com o nome do desenvolvedor. Por exemplo, Tarefas da Contoso em vez de Tarefas. [Deve corrigir]

• 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 incorretamente 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. [Deve corrigir]

• Não deve copiar o nome de um aplicativo listado na Teams Store ou outra oferta no marketplace comercial. [Deve corrigir]

• Não deve conter termos profanos ou depreciativos. O nome também não deve incluir linguagem racial ou culturalmente insensível. [Deve corrigir]

• Deve ser exclusivo. Se o seu aplicativo (Contoso) estiver listado na Teams Store e no Microsoft AppSource e você quiser listar outro aplicativo específico para uma região geográfica, como a 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. [Deve corrigir]
  • Ao carregar o pacote do aplicativo no Partner Center, selecione os mercados corretos em que o aplicativo está disponível na seção Disponibilidade . [Deve corrigir]

• O nome do aplicativo não deve começar com um recurso principal do Teams, como Chat, Contatos, Calendário, Chamadas, Files, Atividade, Teams e Ajuda. O nome do aplicativo não é encurtado para Chat, Contatos, Calendário, Chamadas, Files, Atividade, Teams e Ajuda ao instalar no painel de navegação à esquerda. [Deve corrigir]

• Se o aplicativo fizer parte de uma parceria oficial com a Microsoft, o nome do aplicativo deverá vir em primeiro lugar. Por exemplo, conector Contoso para Microsoft Teams.

• O nome do aplicativo não deve ter nenhuma referência à Microsoft ou aos produtos da Microsoft. Não use Teams ou Microsoft no nome do aplicativo, a menos que ele esteja em parceria oficial com a Microsoft. Nesse caso, o nome do aplicativo deve vir primeiro antes de qualquer referência à Microsoft. Por exemplo, conector Contoso para Microsoft Teams. [Deve corrigir]

• Não use parênteses ao nomear para incluir produtos da Microsoft. [Deve corrigir]

• O nome do desenvolvedor deve ser o mesmo no manifesto do aplicativo (anteriormente chamado de manifesto do aplicativo do Teams) e no AppSource. [Deve corrigir]

• 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, Dev, Preview e UAT. [Deve corrigir]

• O nome do aplicativo no manifesto do aplicativo e o AppSource devem corresponder. [Deve corrigir]

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. [Deve corrigir]

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 de tempo substancial de mais de 60 minutos por sessão nem afetar a produtividade. [Deve corrigir]

Os aplicativos agregadores de conteúdo devem ter um mecanismo para que os usuários relatem um problema ou conteúdo inadequado ao editor do aplicativo. [Deve corrigir]

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. [Deve corrigir]
  • Quando os usuários se desconectam, eles devem se desconectar apenas do aplicativo e permanecer conectados ao Teams. [Deve corrigir]
  • 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 da guia ou página de configuração). [Deve corrigir]
  • Os aplicativos que exigem que um administrador conclua a configuração única devem chamar a dependência do administrador para configurar o aplicativo (antes que qualquer outro usuário do locatário possa instalar e usar o aplicativo). A dependência deve ser mencionada no manifesto do aplicativo, na descrição longa do AppSource, em todos os pontos de contato da experiência de primeira execução (mensagem de boas-vindas do bot, configuração da guia ou página de configuração), no texto de ajuda, conforme necessário, como parte da resposta do bot, nas extensões de redação ou no conteúdo da guia estática. [Deve corrigir]

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

• Pré-busca de token na autenticação aninhada: os aplicativos que usam autenticação aninhada e pré-busca de token devem:

  • Prefixar redirectURI domínios com brk-multihub://.

  • Evite subcaminhos em redirectURI domínios.

  • Verifique se o redirectURI domínio corresponde ao domínio do aplicativo usado no campo do manifesto validDomains do aplicativo.

    

Os aplicativos não devem solicitar que os usuários façam pagamentos na interface do Teams e transmitam informações financeiras aos usuários por meio de uma interface de bot. [Deve corrigir]

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. [Deve corrigir]

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. [Deve corrigir]

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 tenha como objetivo fazer upsell dos usuários para versões pagas ou lojas online para comprar outros conteúdos, aplicativos ou suplementos. [Deve corrigir]

  

  

• 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. [Deve corrigir]

• 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 pagar. [Deve corrigir]

• 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. [Deve corrigir]

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.

Não inclua domínios fora do controle da sua organização (incluindo curingas) e serviços de encapsulamento 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. [Deve corrigir]

• Não use domínios de nível superior, como .com, .in e .org , como um domínio válido. [Deve corrigir]

• Não use .onmicrosoft.com ou como um domínio válido em que a onmicrosoft não esteja sob seu controle. No entanto, você pode usar yoursite.com como um domínio válido em que seu site está sob seu controle, mesmo que o domínio inclua um caractere curinga. [Deve corrigir]

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

• Os domínios externos declarados para seu envio não devem conter URLs. Por exemplo, www ou https. [Deve corrigir]

• Se o aplicativo usar o OAuthCard do Azure Serviço de Bot, você deverá incluí 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 , pois caracteres curinga não são permitidos com este nome de domínio. [Deve corrigir]

• As URLs OpenAPI devem estar sob o controle do parceiro.

• Os seguintes domínios externos não são permitidos: [Deve corrigir]

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

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

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

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

• 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. [Deve corrigir]

• 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. [Deve corrigir]

• Adicione um ícone pop-out para que os usuários saibam que eles estão sendo navegados fora do Teams. Você pode usar o ícone pop-out à direita do link. [Deve corrigir]

• Se você não conseguir adicionar um ícone pop-out , poderá implementar qualquer uma das seguintes opções para informar ao usuário que ele está sendo navegado fora do Teams: [Deve corrigir]

  • Adicione uma observação no Cartão Adaptável que afirma que, quando os usuários selecionam Obter Ajuda para usar esse aplicativo, o usuário é levado para fora do Teams.
  • Adicionar caixas de diálogo intersticiais.

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

• A cor do aplicativo e o ícone de contorno enviados na listagem do aplicativo devem corresponder. [Deve corrigir]

  

  

• 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. [Deve corrigir]

• 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 no pacote do aplicativo. [Deve corrigir]

• 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. [Deve corrigir]

• 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. [Deve corrigir]

• O pacote do aplicativo deve incluir ícones formatados e dimensionados corretamente. Os ícones devem corresponder às informações contidas nos metadados de listagem da Store do Teams. [Deve corrigir]

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

As descrições não devem derrogar diretamente ou por sugestão outra marca (de 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 comparativas de marketing. Por exemplo, não use logotipos ou marcas comerciais de concorrentes na listagem de ofertas, incluindo marcas ou outros metadados que façam referência a ofertas ou mercados concorrentes. [Deve corrigir]

  

• Hiperlink detalhes de contato, introdução, ajuda ou inscrição na descrição do aplicativo. [Bom para consertar]

  

  

• A descrição do aplicativo deve identificar o público-alvo, explicar de forma breve e clara seu valor exclusivo e distinto, identificar os produtos e outros softwares da Microsoft com suporte e incluir todos os 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 nos materiais relacionados, antes que o cliente adquira sua oferta. As funcionalidades declaradas devem estar relacionadas às funções principais e à descrição de sua oferta. [Deve corrigir]

• 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. [Deve corrigir]

• As limitações e dependências da conta devem ser destacadas na Descrição do Aplicativo de manifesto, no AppSource e no Partner Center. Por exemplo:

  • Conta corporativa
  • Assinatura paga
  • Outra licença ou conta
  • Idioma
  • Discagem PSTN (Rede Telefônica Pública Comutada)
  • Dependência regional
  • Prazo de entrega para reserva de tradutores ou agentes ao vivo
  • Funcionalidade baseada em função
  • Dependência de aplicativo nativo

  

  

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

• Se você precisar referenciar o Teams, escreva a primeira referência na listagem do aplicativo como Microsoft Teams. Referências posteriores podem ser reduzidas para Teams. [Deve corrigir]

  

  

Descrição curta

Uma breve descrição deve ser um resumo conciso do seu aplicativo que destaque sua proposta de valor e seja 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:

[Bom para consertar]

Usar a palavra aplicativo na descrição curta.

Descrição longa

A descrição longa deve fornecer uma narrativa envolvente que destaque a proposta de valor do seu aplicativo, o público principal 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 destacar as vantagens de usar seu aplicativo. Adicione até três benefícios.

• Adicione a proposta de valor principal 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.

• Certifique-se de que a descrição do aplicativo corresponda à funcionalidade disponível no 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:

[Deve corrigir]

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

• Coloque em maiúscula 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 orientação sobre como criar uma descrição curta, longa e curta, precisa, concisa e informativa, consulte Lista de verificação para escrever descrições de aplicativos.

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 nos recursos 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 nítidas e contenham texto legível e claramente legível. [Deve corrigir]

• Pelo menos uma captura de tela deve mostrar a funcionalidade do seu aplicativo em dispositivos móveis. [Bom para consertar]

  

• 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. [Deve corrigir]

• Use modelos que retratem com precisão a interface do usuário real do aplicativo para o benefício dos usuários finais. As capturas de tela devem descrever com precisão a interface do usuário real do aplicativo ou cenários relevantes e relacionados ao aplicativo. [Deve corrigir]

  

  

• Deve descrever a funcionalidade do aplicativo ou a integração com o Teams. [Deve corrigir]

  

• As capturas de tela fornecidas não devem fazer referência incorreta ao Microsoft Teams como MS, MSFT ou MS Teams. [Deve corrigir]

• Se o aplicativo Teams for extensível entre clientes do Microsoft 365 (Microsoft 365, Outlook e Microsoft Teams), as capturas de tela fornecidas devem mostrar a funcionalidade do aplicativo em outros clientes do Microsoft 365. [Bom para consertar]

  

• Você deve fornecer legendas em suas capturas de tela para permitir que o usuário entenda claramente a funcionalidade do aplicativo. [Deve corrigir]

  

• Se o seu aplicativo der suporte a guias como um recurso, as capturas de tela que mostram o aplicativo no contexto de uma guia do Teams, na listagem do aplicativo, deverão conter o Chrome do Team. [Deve corrigir]

  

• Se o seu aplicativo Teams for extensível no Microsoft Copilot, as capturas de tela fornecidas devem mostrar a funcionalidade do aplicativo no Copilot. [Deve corrigir]

  

O que não fazer:

• Inclua modelos que reflitam de forma imprecisa a interface do usuário real do seu aplicativo, como mostrar seu aplicativo sendo usado fora do Teams.

  

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.

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

• Os metadados da oferta devem corresponder ao manifesto do aplicativo, à listagem do aplicativo Teams no AppSource e à oferta de SaaS no AppSource.
• O aplicativo Teams e a oferta de SaaS devem ser do mesmo editor ou desenvolvedor. A oferta de SaaS referenciada no manifesto do aplicativo deve pertencer ao mesmo editor que o aplicativo Teams é enviado para o marketplace comercial.
• Como sua oferta enviada é um aplicativo do Teams vinculado à oferta de 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 de configuração de produtos do Partner Center da sua listagem 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 mencionadas 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.

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

• Permitir que o assinante atribua licenças.

• Forneça diferentes maneiras de interagir com o 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.

• Oriente os usuários sobre como adicionar o aplicativo ao Teams e começar por meio do chatbot 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 aterrissagem 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.

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

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

• A configuração da guia não deve atrapalhar um novo usuário. Forneça uma mensagem sobre como concluir a ação ou o fluxo de trabalho. [Deve corrigir]

  

• O usuário não deve sair da 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. [Deve corrigir]

  

• A tela de configuração de guia não deve incorporar 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. [Deve corrigir]

  

  

• Os aplicativos que exigem que os usuários insiram uma URL durante a configuração de uma guia devem:

  • Forneça uma orientação apropriada para que o usuário adquira ou gere a URL. [Deve corrigir]
  • Verifique se há URLs relevantes ou apropriadas para a funcionalidade do aplicativo de acordo com a descrição do aplicativo. [Deve corrigir]

  

  

• Crie um hiperlink para as informações de contato na tela de configuração, em vez de texto sem formatação, para ajudar os usuários a entrar em contato com você para obter os requisitos de suporte. [Deve corrigir]

• Para uma experiência de usuário perfeita na primeira execução, recomendamos que você crie um hiperlink para sua URL de suporte ou email na tela de configuração. [Bom para consertar]

• A área da tela de entrada não deve usar logotipos grandes. [Deve corrigir]

  

• 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 I-frame, pois a estrutura da guia já exibe o ícone e o nome do aplicativo. [Bom para consertar]

  

  

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

• As guias não devem fornecer navegação que entre em conflito com a navegação principal 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 apenas texto ou use menus de hambúrguer em vez do painel esquerdo da tabulação. [Deve corrigir]

  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 painel esquerdo sem nenhum componente de navegação, a barra de ferramentas deverá deixar um espaçamento de 20 pixels da navegação à esquerda do Teams. [Deve corrigir]

  

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

  • Botões de voltar
  • Cabeçalhos da página
  • Menus de hambúrguer

  

• Os links profundos nas guias não devem ser vinculados a uma página da Web externa, mas dentro do Teams. Por exemplo, caixas de diálogo ou outras guias. [Deve corrigir]

  

• As guias não devem permitir que os usuários naveguem para 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. [Deve corrigir]

  

  

• A rolagem horizontal não deve estar presente em uma guia na reunião. [Deve corrigir]

• As caixas de diálogo na reunião usadas em seu aplicativo não devem permitir a rolagem horizontal. Use caixas de diálogo na reunião com moderação e para cenários leves e orientados a tarefas. Você pode especificar a largura do quadro em I do diálogo da reunião dentro do intervalo de tamanho compatível para levar em conta diferentes cenários. [Deve corrigir]

• As caixas de diálogo usadas em seu 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 em tela cheia para exibir seu conteúdo da Web) para concluir o fluxo de trabalho sem rolagem horizontal. [Deve corrigir]

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

  

  

  

  

  

• O usuário deve ter uma opção para ir para o estado de trabalho anterior. [Deve corrigir]

  

  

• A rolagem horizontal em Cartões Adaptáveis não deve estar presente no Teams. [Deve corrigir]

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

  

• O conteúdo não deve ser truncado ou sobreposto dentro da guia. [Precisa ser corrigido]

  

• Os usuários devem ser capazes de desfazer a última ação na guia. [Deve corrigir]

• 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. [Bom para consertar]

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

  

  

• As guias devem usar componentes com estilo 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. [Bom para consertar]

  

• Se a funcionalidade do seu aplicativo exigir alterações nas configurações, inclua uma guia Configurações . [Bom consertar]

• 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 IU Fluente do Microsoft Teams. [Bom para consertar]

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

  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 impeçam completamente os fluxos de trabalho dentro da guia. Por exemplo, bot dentro de uma guia que não pode ser minimizado. [Deve corrigir]

  

• A guia não deve ter uma funcionalidade interrompida. Sua oferta deve ser uma solução de software utilizável e deve fornecer a funcionalidade, os recursos e as entregas conforme descrito em sua listagem e em outros materiais relacionados. [Deve corrigir]

• Se suas guias contiverem um rodapé, certifique-se de remover todos os links não relacionados à funcionalidade do aplicativo do rodapé. [Deve corrigir]

• O conteúdo na página de aterrissagem das guias configuráveis não deve ter escopo para uso individual e não deve incluir conteúdo pessoal, como Minhas Tarefas ou Meu Painel. [Deve corrigir]

  

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

• 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. [Deve corrigir]

• As guias de canal, chat e reunião são espaços colaborativos. O conteúdo nessas guias não deve ter escopo para uso individual.

  

• As guias configuráveis devem ter a funcionalidade focalizada. [Deve corrigir]

  

• O aplicativo do 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 envolver o usuário executando tarefas repetitivas. Por exemplo, use uma caixa de diálogo para capturar repetidamente o nome, a data de nascimento, o local e a designação, em vez de usar conversas com vários turnos. [Deve corrigir]

• Quaisquer links, respostas ou fluxos de trabalho desfeitos em seu aplicativo devem ser corrigidos. [Deve corrigir]

• Os escopos definidos e bot.scopesbot.commandList.scopes os nós do manifesto devem corresponder para manter uma boa experiência do usuário.

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.

• Os bots devem dar suporte a fluxos de trabalho corporativos funcionais. Se os comandos de bot forem declarados no manifesto, os Title campos e Description serão obrigatórios e deverão ser claramente definidos e alinhados de forma consistente. O bot deve permitir que os usuários saibam sobre a proposta de valor do aplicativo. O bot deve responder com vários fluxos de trabalho aos quais dá suporte para pedir ajuda ou valor que ele fornece. O bot deve fornecer uma resposta válida mesmo quando o usuário não estiver conectado aos aplicativos.

  

• Todos os comandos compatíveis com o bot devem funcionar corretamente, incluindo comandos genéricos como Oi, Oláe Ajuda. [Deve corrigir]

  

  

• 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. [Deve corrigir]

  

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

• 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. [Deve corrigir]

  

• Os bots sempre devem fornecer uma resposta válida a uma entrada do usuário, mesmo que a entrada seja irrelevante ou imprópria. [Deve corrigir]

  

  

• Caracteres especiais, como barra (/), não devem ser prefixados aos comandos de bot. [Deve corrigir]

  

• Os bots devem fornecer uma resposta válida para comandos de usuário inválidos. Os bots não devem enganar o usuário ou exibir um erro se um usuário enviar um comando de bot inválido. [Deve corrigir]

  

  

• 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. [Deve corrigir]

• Os bots não devem conter comandos duplicados. [Deve corrigir]

• 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 enquanto respondem ao comando do usuário. [Deve corrigir]

  

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

  

• As respostas de bot em dispositivos móveis devem ser responsivas, sem nenhum truncamento de dados que dificulte o uso do bot do usuário final para concluir os fluxos de trabalho desejados. [Deve corrigir]

  

  

• Todos os links em um Cartão Adaptável de resposta de bot devem responder. Qualquer link que leve o usuário para fora da plataforma do Teams deve ter um texto de redirecionamento claro, como Exibir em... ou Este caminho 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. [Deve corrigir]

  

• Por design, se o bot não responder ou der suporte a qualquer comando do usuário e for um bot unidirecional destinado apenas a notificar os usuários. Você deve definir isNotificationOnly como true no manifesto do aplicativo. [Deve corrigir]

  

  

• A experiência do usuário do bot não deve ser interrompida em plataformas móveis. Seu bot deve ser totalmente responsivo em dispositivos móveis. [Deve corrigir]

• Para habilitar cartões de perfil do aplicativo para agentes ou bots, adicione um campo de recursos em descrição no manifesto do aplicativo. Verifique se ele atende a todas as políticas de metadados e casos de teste e inclua apenas detalhes de funcionalidade com suporte.

• Certifique-se de que os comandos do bot sejam consistentes –

  • Dentro de cada escopo (pessoal/groupChat/equipe/copiloto) e verifique se os commandList.type valores são consistentes.
  • O promptcomando , description, e para cada bot deve ser consistente e title coerente entre si.

• Um bot em escopo pessoal sempre deve enviar uma mensagem de boas-vindas ou fornecer prompt-starters. [Deve corrigir]

  Se você estiver usando os iniciadores de prompt, verifique se as seguintes diretrizes foram atendidas:

  Os iniciadores de prompt ajudam os usuários a iniciar uma conversa com seu bot. Para habilitar os inicializadores de prompt, a propriedade no manifesto commands do aplicativo precisa ser definida.

  • O bot deve permitir que os usuários saibam sobre a proposta de valor do aplicativo.
  • O bot deve responder com vários fluxos de trabalho aos quais dá suporte para pedir ajuda ou valor que ele fornece. O bot deve fornecer uma resposta válida mesmo quando o usuário não estiver conectado aos aplicativos. [Deve corrigir]
  • Os prompts de partida ou comandos devem funcionar e retornar respostas. [Deve corrigir]
  • A descrição do comando deve ser coerente e comunicar claramente o valor do comando. [Deve corrigir]
  • Os comandos ou inícios de prompt devem ser relevantes para a funcionalidade do aplicativo. [Deve corrigir]
  • O bot deve ter pelo menos três iniciadores de prompt ou comandos exclusivos. [Bom para consertar]

  Se o aplicativo enviar uma mensagem de boas-vindas, verifique se as seguintes diretrizes foram atendidas:

  • Se o aplicativo tiver um fluxo de configuração complexo (exigir uma licença corporativa ou não tiver um fluxo de inscrição intuitivo), os bots nesses aplicativos sempre deverão incluir informações relacionadas à configuração ao 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, quem instalou 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 (isso é considerado spam). A mensagem também deve mencionar a pessoa que adicionou o bot.

  

  

• A mensagem de boas-vindas não deve incomodar 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. [Deve corrigir]

  

  

• 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 individual. [Deve corrigir]

  

• Somente notificação O bot poderá 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 são acionadas. [Deve corrigir]

• O bot instalado em um escopo de chat de grupo ou canal não deve enviar mensagens proativas (não apenas uma mensagem de boas-vindas) que sejam irrelevantes para todos os usuários no chat de grupo ou canal, em vez disso, deve enviar mensagens proativas para o usuário por chat individual. [Deve corrigir]

• 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 em um chat individual com o usuário. [Deve corrigir]

• A mensagem de boas-vindas do bot deve chamar claramente a atenção para as limitações relacionadas ao uso do bot no escopo instalado. [Deve corrigir]

  

  

• A mensagem de boas-vindas deve ser disparada 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 será levado a um beco sem saída. Se o aplicativo não incluir um fluxo de trabalho de configuração complexo, é opcional para o desenvolvedor disparar uma mensagem de boas-vindas no escopo do canal ou chat em grupo. [Deve corrigir]

  

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

• As mensagens de boas-vindas não devem ser disparadas com todos os comandos do bot. Isso é considerado spam. [Deve corrigir]

  

• O conteúdo da mensagem de boas-vindas deve estar relacionado ao fluxo de trabalho do bot mencionado na descrição longa do aplicativo e no escopo da 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. [Deve corrigir]

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

  

• O nome do aplicativo na mensagem de boas-vindas deve corresponder ao nome do aplicativo no manifesto do aplicativo. [Deve corrigir]

  

• A mensagem de boas-vindas não deve exibir nomes de plataformas colaborativas baseadas em chat da concorrência, 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 incentivar o usuário a concluir sua primeira tarefa e descrever brevemente todos os comandos de bot com suporte no aplicativo. [Deve corrigir]

• A mensagem de boas-vindas não deve conter links para nenhum marketplace de aplicativos, incluindo o AppSource. [Deve corrigir]

• Se o seu aplicativo tiver um fluxo de trabalho de configuração complexo que exija instalação conduzida pelo administrador, 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 deverá enviar uma mensagem de boas-vindas proativa em um escopo de equipe ou chat em grupo após a instalação. [Deve corrigir]

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

• Os bots que enviam várias mensagens devem garantir que as mensagens não sejam repetitivas ou redundantes por natureza.

• As mensagens de bot disparadas a partir de interações do usuário devem conter atribuição de usuário representando o nome do usuário que executa a ação. [Deve corrigir]

• No escopo do canal, a mensagem de boas-vindas deve ser enviada somente para o canal em que o usuário iniciou a ação de instalação do bot.

• 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. [Deve corrigir]

  

  

• Mensagens de bot em aplicativos pessoais:

  • Evite conversas de vários turnos para concluir um único fluxo de trabalho repetitivo. [Deve corrigir]
  • Use um formulário (ou caixa de diálogo) para coletar todas as entradas de um usuário de uma vez. [Deve corrigir]
  • 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. [Deve corrigir]

  

As notificações de bot devem incluir conteúdo relevante ao escopo definido pelo bot (equipe, bate-papo ou pessoal). [Deve corrigir]

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

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.

• As informações do bot no manifesto do aplicativo (nome do bot, logotipo, link de privacidade e link dos termos de serviço) devem ser consistentes com os metadados do Bot Framework. [Deve corrigir]

• 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. Alterar 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 seu aplicativo e inicia uma nova cadeia de conversas com a nova ID do Bot. [Deve corrigir]

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

• O nome do aplicativo na mensagem de boas-vindas do bot ou as respostas do bot devem corresponder ao nome do aplicativo no manifesto do aplicativo. [Deve corrigir]

• Instalação de bot em um canal ou escopo de chat em grupo para obter a lista de equipe para enviar notificações proativas para usuários como chats 1:1 para gatilhos específicos da equipe não é permitida. Por exemplo, aplicativo que emparelha pessoas para um encontro. [Deve corrigir]

• O bot em um canal ou chat em grupo é usado apenas para obter mensagens ou postagens para enviar notificações proativas para usuários, pois chats 1:1 não é permitido. [Deve corrigir]

• Os bots instalados no escopo colaborativo devem fornecer um valor de usuário no escopo colaborativo. [Deve corrigir]

• Se o aplicativo do Teams usa o recurso de extensão de mensagens, seu aplicativo deve 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 sua 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 na extensão de mensagens. [Deve corrigir]

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

  

  

• O card de resposta da extensão de mensagens deve incluir o ícone do aplicativo para evitar confusão para o usuário final. [Deve corrigir]

• Seu aplicativo não deve ter nenhuma funcionalidade interrompida. O aplicativo não deve criar um beco sem saída ou impedir que o usuário conclua um fluxo de trabalho em uma extensão de mensagens. [Deve corrigir]

• As extensões de mensagens devem responder ou funcionar conforme o esperado nos escopos de chat e canal em grupo. [Deve corrigir]

• Você deve incluir uma maneira de o usuário entrar ou sair da extensão de mensagens. [Deve corrigir]

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

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. [Deve corrigir]

  

  

• 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 uma Reunião do Skype para Iniciar Reunião, Carregar arquivo no DocuSign para Carregar arquivo. [Bom para consertar]

  

  

• A invocação de 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 o esperado não devem estar presentes. [Deve corrigir]

  

• Comandos de ação duplicados não devem estar presentes. [Deve corrigir]

• As ações da mensagem devem permitir que o usuário conclua o fluxo de trabalho conforme o esperado, sem uma resposta inválida. [Deve corrigir]

• Os aplicativos com apenas extensão de mensagens baseada 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. [Deve corrigir]

  • Permitir que os usuários compartilhem cartões com outros usuários com base na ação realizada. Isso é para garantir que os aplicativos não executem ações silenciosas. Por exemplo, um ticket é 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 ticket após a criação do ticket. [Deve corrigir]

[Deve corrigir]

• 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á ser descompactado e mostrar a caixa de diálogo adicionar aplicativo depois que o card for selecionado. [Deve corrigir]

• 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. [Deve corrigir]

• Os aplicativos só devem declarar que estão sob a propriedade direta do editor do aplicativo na messageHandler seção de descompactação de links do manifesto do aplicativo. Ele não deve conter *.botframework.com. [Deve corrigir]

• Extensões de mensagens baseadas em pesquisa devem fornecer texto que ajude os usuários a pesquisar com eficiência. [Deve corrigir]

  

  

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

  

Uma caixa de diálogo (referida como módulo de tarefa no TeamsJS v1.x) deve incluir um ícone e o nome abreviado do aplicativo ao qual ela está associada. As caixas de diálogo não devem incorporar 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.

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

• Com a experiência do aplicativo na reunião, você pode envolver os participantes durante a reunião usando as guias na reunião, a caixa de diálogo e o recurso de compartilhamento na reunião com o estágio. Se o aplicativo der suporte à extensão de reunião do Teams, você deverá fornecer uma experiência responsiva na reunião alinhada à experiência de reunião do Teams. [Deve corrigir]

• Os aplicativos de extensibilidade de reunião devem oferecer uma experiência responsiva na reunião 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 as experiências pré e pós-reunião não são obrigatórias. [Deve corrigir]

  • 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 realizar tarefas pré-reunião, como desenvolver uma votação para pesquisar 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 visualizar os resultados da reunião, como resultados de pesquisas 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 conferência no Teams. [Deve corrigir]

• Os aplicativos direcionados em experiências de reunião devem declarar meetingSidePanelou usar APIs para habilitar o compartilhamento em estágio de reunião e incluir groupChat em configurableTabs, meetingDetailsTab, e meetingChatTab.

• As telas de reunião e chamada não devem deixar um participante sem saída. As telas de reunião e chamada devem mostrar uma mensagem de falha normal para limitações do aplicativo, como dependência específica da região. [Deve corrigir]

• O cabeçalho da tela de reunião e chamada deve exibir o nome correto do aplicativo para evitar confundir o participante da reunião. [Deve corrigir]

• Você deve incluir uma opção para que o usuário saia ou saia da reunião e da chamada de extensão. [Deve corrigir]

• 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. [Deve corrigir]

• O Meeting Stage é uma tela de participação focada, intuitiva e colaborativa. O estágio de reunião não deve incorporar a experiência completa do site. [Deve corrigir]

• O aplicativo não deve mostrar uma tela de carregamento contínuo, erro ou funcionalidade interrompida que interrompa o usuário ou bloqueie a conclusão de um fluxo de trabalho em um cenário de reunião e chamada. [Deve corrigir]

  

• 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 ativa do Teams. [Deve corrigir]

• Os aplicativos de reunião devem concluir fluxos de trabalho na plataforma Microsoft Teams sem redirecionar para plataformas baseadas em chat da concorrência. [Deve corrigir]

  

• Se o seu aplicativo for compatível com exibições baseadas em funções e determinados fluxos de trabalho não estiverem disponíveis para todos os participantes, recomendamos que você implemente mensagens adequadas para os 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 notas da reunião, itens de ação e agendas de atualização. [Deve corrigir]

  

• 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. [Deve corrigir]

• 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. [Deve corrigir]

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

  

• Os aplicativos só devem usar um tema escuro durante reuniões e chamadas. Para obter mais informações, confira diretrizes de design do Teams. [Deve corrigir]

• Uma dica de ferramenta deve exibir o nome do aplicativo ao passar o mouse sobre o ícone do aplicativo durante reuniões e chamadas. [Deve corrigir]

  

• As extensões de mensagem devem funcionar da mesma forma durante reuniões e chamadas que funcionam fora das reuniões ou chamadas. [Deve corrigir]

• Deve responder. [Deve corrigir]

• Deve manter o preenchimento e os tamanhos dos componentes. [Deve corrigir]

• Deve ter um botão Voltar se houver mais de uma camada de navegação. [Deve corrigir]

  

  

• Não deve incluir mais de um botão fechar. Isso pode confundir os usuários, pois já existe um botão de cabeçalho embutido para ignorar a guia. [Deve corrigir]

• Não deve ter rolagem horizontal. [Deve corrigir]

  

  

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

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

  

  

• Não deve usar caixas de diálogo. [Deve corrigir]

• Deve alinhar-se ao centro do estágio da reunião. [Deve corrigir]

  

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

• Modo juntos: considere as seguintes práticas recomendadas para uma experiência de construção de cena: [Deve corrigir]

  • Todas as imagens estão no formato .png.
  • O pacote final com todas as imagens juntas não deve exceder a resolução de 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.

Você deve declarar pessoal como um escopo e meetingSidePanel como uma propriedade de contexto no staticTabs nó do manifesto do aplicativo para habilitar seu aplicativo para chamadas individuais do Teams. [Deve corrigir]

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 propriedade como MeetingStage.Write.Chat e type a name propriedade como Delegated no resourceSpecific campo. [Deve corrigir]

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. [Deve corrigir]

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

• O fluxo de trabalho irrelevante, impróprio, sem resposta ou interrompido não deve estar presente depois que o usuário seleciona 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 selecionarem uma notificação do feed de atividades. [Deve corrigir]

• Inclua o nome do aplicativo na notificação do feed de atividades para que os usuários finais entendam a origem ou o gatilho da notificação sem confusão. [Deve corrigir]

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

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

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

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

• O avatar de notificação deve corresponder ao ícone de cor do aplicativo. Como alternativa, se você estiver usando ícones de atividade personalizados para seu aplicativo ou agente, os ícones deverão estar de acordo com as seguintes diretrizes: [Deve corrigir]

  • Os ícones de atividade devem ter 32 * 32 pixels de tamanho e uma extensão de arquivo .png.
  • Os ícones de atividade não devem ser inadequados, prejudiciais ou ter conteúdo ofensivo.
  • O @mention ícone deve ser usado exclusivamente para indicar a marcação de usuário ou grupo, semelhante ao seu uso no Microsoft Teams.

• As notificações disparadas por um usuário devem incluir o avatar do usuário. [Deve corrigir]

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

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

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 estiver publicando um aplicativo na Teams Store, você 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 azul de verificado é exibido na caixa de diálogo de consentimento do Microsoft Entra e em outras telas. Para obter mais informações, consulte Marcar seu aplicativo como verificado pelo editor. [Deve corrigir]

  

• 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. [Bom para consertar]

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