Diretrizes de validação da Teams Store

As guias devem fornecer valor além de hospedar um site existente. [Tem de 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.

Aplicações que fornecem apenas notificações com conteúdos como, por exemplo, Tem uma nova notificação ou clique para ver e exige que o utilizador navegue para fora do Teams para que tudo o resto não forneça um valor significativo no Teams.

[Tem de 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 a validação de uma aplicação apenas de extensão de mensagem baseada em pesquisa, é necessário o seguinte como linha de base para garantir que a experiência do utilizador não é 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.

   

   

Os aplicativos de desbloqueio de links não fornecem um valor significativo para as equipes. Considere criar mais fluxos de trabalho na sua aplicação, se a sua aplicação apenas suportar a desfraldamento de ligações e não tiver outras funcionalidades.

O nome de uma aplicação desempenha um papel fundamental na forma como os utilizadores a detetam na Loja Teams. Use as seguintes diretrizes para nomear um aplicativo:

• O nome deve incluir termos relevantes aos seus usuários. [Tem de corrigir]

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

• Não é possível utilizar o Teams ou outros nomes de produtos Microsoft, como Excel, PowerPoint, Word, OneDrive, SharePoint, OneNote, Azure, Surface e Xbox, que possam indicar falsamente a co-imagem corporativa ou a venda conjunta. 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. [Tem de corrigir]

• Não é possível copiar o nome de uma aplicação listada na Loja Teams ou outra oferta no marketplace comercial. [Tem de corrigir]

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

• Deve ser exclusivo. Se a sua aplicação (Contoso) estiver listada na Loja Teams e no Microsoft AppSource e quiser listar outra aplicação específica para uma geografia como a Contoso México, a sua submissão tem de cumprir os 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. [Tem de corrigir]
  • Ao carregar o pacote de aplicações no Centro de Parceiros, selecione os Mercados corretos onde a aplicação está disponível na secção Disponibilidade . [Tem de corrigir]

• O nome da aplicação não pode ser apresentado com uma funcionalidade principal do Teams, como Chat, Contactos, Calendário, Chamadas, Ficheiros, Atividade, Teams e Ajuda. O nome da aplicação não abrevia para Chat, Contactos, Calendário, Chamadas, Ficheiros, Atividade, Teams e Ajuda na instalação no painel de navegação esquerdo. [Tem de corrigir]

• Se a sua aplicação fizer parte de uma parceria oficial com a Microsoft, o nome da sua aplicação tem de estar em primeiro lugar. Por exemplo, conector contoso para o Microsoft Teams.

• O nome da aplicação não pode ter qualquer referência aos produtos Microsoft ou Microsoft. Não utilize o Teams ou a Microsoft, no nome da aplicação, a menos que a sua aplicação esteja em parceria oficial com a Microsoft. Nesse caso, o nome da aplicação tem de estar em primeiro lugar antes de qualquer referência à Microsoft. Por exemplo, conector contoso para o Microsoft Teams. [Tem de corrigir]

• Não utilize parênteses na nomenclatura para incluir produtos Microsoft. [Tem de corrigir]

• O nome do programador tem de ser o mesmo no manifesto da aplicação (anteriormente denominado manifesto de aplicação do Teams) e no AppSource. [Tem de corrigir]

• Os manifestos de aplicação submetidos têm de ser manifestos de produção. Assim, o nome da aplicação não deve indicar que a aplicação é uma aplicação de pré-produção. Por exemplo, o nome da aplicação não deve conter palavras como Beta, Dev, Preview e UAT. [Tem de corrigir]

• O nome da aplicação no manifesto da aplicação e o AppSource têm de corresponder. [Tem de 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. [Tem de 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. As aplicações não devem exigir um investimento de tempo substancial superior a 60 minutos por sessão ou afetar a produtividade. [Tem de corrigir]

As aplicações do agregador de conteúdos têm de ter um mecanismo para os utilizadores comunicarem um problema ou conteúdo inadequado ao publicador da aplicação. [Tem de 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. [Tem de corrigir]
  • Quando os usuários se desconectam, eles devem se desconectar apenas do aplicativo e permanecer conectados ao Teams. [Tem de 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 tem de estar disponível no manifesto da aplicação, na descrição longa do AppSource e na experiência de primeira execução da aplicação (mensagem de boas-vindas do bot, configuração do separador ou página de configuração). [Tem de corrigir]
  • As aplicações que exigem que o administrador de inquilinos conclua a configuração única têm de chamar a atenção para a dependência do administrador de inquilinos para configurar a aplicação (antes que qualquer outro utilizador inquilino possa instalar e utilizar a aplicação). A dependência tem de ser destacada no manifesto da aplicação, descrição longa do AppSource, todos os pontos táteis de experiência de primeira execução (mensagem de boas-vindas do bot, configuração do separador ou página de configuração), texto de ajuda conforme considerado necessário como parte da resposta do bot, extensões de composição ou conteúdo de separador estático. [Tem de 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.

As aplicações não devem pedir aos utilizadores que efetuem pagamentos na interface do Teams e transmitam informações financeiras aos utilizadores através de uma interface de bot. [Tem de 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. [Tem de 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. [Tem de corrigir]

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

• As aplicações não devem incluir compras via aplicação, ofertas de avaliação ou IU que vise a venda de utilizadores a versões pagas ou lojas online para comprar outros conteúdos, aplicações ou suplementos. [Tem de 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. [Tem de corrigir]

• Você pode determinar se uma conta está ativa indefinidamente ou por um tempo limitado. Quando a conta expira, a aplicação não tem de mostrar IU, texto ou ligações que indiquem a necessidade de pagamento. [Tem de 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. [Tem de 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 controlo da sua organização (incluindo carateres universais) e serviços de túnel nas configurações de domínio da sua aplicação. 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. [Tem de corrigir]

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

• Não utilize .onmicrosoft.com ou como um domínio válido em que a onmicrosoft não esteja sob o seu controlo. No entanto, pode utilizar yoursite.com como um domínio válido onde o seu local está sob o seu controlo, mesmo que o domínio inclua um caráter universal. [Tem de corrigir]

• Se a sua aplicação for um PowerApp criado no Microsoft Power Platform, tem de incluir apps.powerapps.com como um domínio válido para permitir que a sua aplicação seja acessível e funcional no Teams.

• Os domínios externos declarados para a submissão não podem conter URLs. Por exemplo, www ou https. [Tem de corrigir]

• Se a sua aplicação utilizar o OAuthCard do Azure Serviço de Bot, tem de incluir token.botframework.com como um domínio válido ou o botão Iniciar sessão não funcionará. Não deve declarar .botframework.com porque não são permitidos carateres universais com este nome de domínio. [Tem de corrigir]

• Os URLs openAPI têm de estar sob controlo de parceiros.

• Não são permitidos os seguintes Domínios Externos: [Tem de corrigir]

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

Ao utilizar carateres universais (*), aplicam-se as seguintes regras:

• Se um segmento de subdomínio incluir um caráter universal, tem de ser o único caráter no segmento.
• Qualquer segmento anterior a um segmento de caráter universal também tem de ser um segmento de carateres universais.

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

• Adicione o ícone de Destaque para informar os utilizadores de que estão a ser navegados fora do Teams. Pode utilizar o ícone de destaque à direita da ligação. [Tem de corrigir]

• Se não conseguir adicionar um ícone de Destaque , pode implementar qualquer uma das seguintes opções para informar o utilizador de que está a ser navegado fora do Teams: [Tem de corrigir]

  • Adicione uma nota no Cartão Ajustável que indica que, quando os utilizadores selecionam Obter Ajuda com esta aplicação, este leva o utilizador para fora do Teams.
  • Adicionar caixas de diálogo interstitiais.

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

• A cor e o ícone de destaque da aplicação submetidos na listagem de aplicações têm de corresponder. [Tem de 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. [Tem de corrigir]

• O ícone do marketplace carregado como parte da listagem do marketplace da aplicação na sua conta do Centro de Parceiros tem de corresponder ao ícone de cor fornecido no pacote de aplicações. [Tem de 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. [Tem de 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 adicional à volta do símbolo. [Tem de corrigir]

• O pacote do aplicativo deve incluir ícones formatados e dimensionados corretamente. Os ícones têm de corresponder às informações na Lista de metadados da Loja Teams. [Tem de corrigir]

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

As descrições não devem ser desativadas diretamente ou através de sugestões para desativar outra marca (propriedade da Microsoft ou outra). Certifique-se de que a sua descrição não inclui afirmações que não podem ser fundamentadas. Por exemplo, Aumento garantido de 200% na eficiência.

• A descrição da aplicação não pode conter informações de marketing comparativas. Por exemplo, não utilize logótipos ou marcas comerciais concorrentes na listagem de ofertas, incluindo etiquetas ou outros metadados que referenciem ofertas ou marketplaces concorrentes. [Tem de corrigir]

  

• Detalhes de contacto da hiperligação, introdução, ajuda ou inscrição na descrição da aplicação. [Boa solução]

  

  

• A descrição da aplicação tem de identificar a audiência pretendida, explicar resumida e claramente o seu valor exclusivo e distinto, identificar produtos Microsoft suportados e outro software e incluir quaisquer pré-requisitos ou requisitos para a sua utilização. Tem de descrever claramente quaisquer limitações, condições ou exceções à funcionalidade, funcionalidades e materiais a entregar, conforme descrito na listagem e materiais relacionados antes de o cliente adquirir a oferta. As capacidades que declarar têm de estar relacionadas com as funções principais e a descrição da oferta. [Tem de corrigir]

• Se atualizar o nome da aplicação, substitua o nome da aplicação antigo pelo novo nome da aplicação nos metadados da oferta no manifesto da aplicação, no AppSource e sempre que aplicável. [Tem de corrigir]

• As limitações e as dependências da conta têm de ser destacadas no manifesto Descrição da Aplicação, AppSource e Centro de Parceiros. Por exemplo:

  • Conta empresarial
  • Subscrição paga
  • Outra licença ou conta
  • Idioma
  • Marcação pública da rede telefónica comutado (RTPC)
  • Dependência regional
  • Tempo de entrega para tradutores de reservas ou agentes em direto
  • Funcionalidade baseada em funções
  • Dependência na aplicação nativa

  

  

• Se a sua aplicação for suportada para regiões ou localizações geográficas específicas, tem de chamar a atenção para essa dependência de região específica na descrição da aplicação no manifesto da aplicação, no Centro de Parceiros e no AppSource para essa oferta.

• Se precisar de referenciar o Teams, escreva a primeira referência na listagem de aplicações como Microsoft Teams. Referências posteriores podem ser reduzidas para Teams. [Tem de corrigir]

  

  

Descrição curta

Uma breve descrição tem de ser um resumo conciso da sua aplicação que realce a sua proposta de valor e é direcionada para o 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:

[Boa solução]

Usar a palavra aplicativo na descrição curta.

Descrição longa

A descrição longa tem de fornecer uma narrativa envolvente que realce a proposta de valor da sua aplicação, a audiência primária e a indústria de destino. Embora a descrição possa ter até 4000 carateres, recomendamos que tenha uma descrição concisa de cerca de 1000 carateres.

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 as principais vantagens para realçar as vantagens de utilizar a sua aplicação. Adicione até três benefícios.

• Adicione a proposta de valor chave da sua aplicação 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 da aplicação corresponde à funcionalidade disponível na aplicação 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...
  • .. concebido para...

O que não fazer:

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

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

  

  

• 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ções sobre como criar uma descrição curta e longa precisa, concisa e informativa, veja a lista de verificação para escrever descrições de aplicações.

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 capacidades da sua aplicação. Por exemplo, como as pessoas podem comunicar com o 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.

• Utilize capturas de ecrã de alta resolução que sejam nítidas e contenham texto legível e claramente legível. [Tem de corrigir]

• Pelo menos uma captura de ecrã tem de mostrar a funcionalidade da sua aplicação em dispositivos móveis. [Tem de corrigir]

  

• Você pode ter até cinco capturas de tela por listagem. Tem de ter um mínimo de três e um máximo de cinco capturas de ecrã na listagem de aplicações. [Tem de corrigir]

• Utilize maquetes que retratam com precisão a IU real da aplicação em benefício dos utilizadores finais. As capturas de ecrã têm de ilustrar com precisão a IU real da aplicação ou os cenários relevantes e relacionados com a aplicação. [Tem de corrigir]

  

  

• Tem de representar a funcionalidade da aplicação ou a integração com o Teams. [Tem de corrigir]

  

• As capturas de ecrã fornecidas não devem referenciar incorretamente o Microsoft Teams como MS, MSFT ou MS Teams. [Tem de corrigir]

• Se a sua aplicação Teams for extensível em todos os clientes do Microsoft 365 (Microsoft 365, Outlook e Microsoft Teams), as capturas de ecrã fornecidas têm de mostrar a funcionalidade da aplicação noutros clientes do Microsoft 365. [Tem de corrigir]

  

• Tem de fornecer legendas nas suas capturas de ecrã para que o utilizador compreenda claramente a capacidade da aplicação. [Tem de corrigir]

  

• Se a sua aplicação suportar Separadores como uma capacidade, as capturas de ecrã que mostram a aplicação no contexto de um separador do Teams, na listagem de aplicações, têm de conter o cromado da Equipa. [Tem de corrigir]

  

O que não fazer:

• Inclua maquetes que refletem incorretamente a IU real da sua aplicação, como mostrar a sua aplicação a ser utilizada 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 ficheiro de manifesto da aplicação têm de 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 SaaS associada à aplicação Teams tem de estar em direto no AppSource e as ofertas de pré-visualização não são aceites para aprovação da Loja Teams.

• Os metadados da oferta têm de corresponder ao manifesto da aplicação, à listagem da aplicação 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 da aplicação tem de pertencer ao mesmo publicador que a aplicação Teams é submetida para o marketplace comercial.
• Uma vez que a oferta submetida é uma aplicação do Teams associada à oferta SaaS, tem de selecionar Compras adicionais como Sim, o meu produto requer a compra de um serviço ou oferece compras adicionais na aplicação na secção de configuração de produtos do Centro de Parceiros 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 a funcionalidades oferecidas têm de ser destacadas 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 formas de interagir com o suporte para problemas, tais como FAQ, base de dados de conhecimento e e-mail.

• 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 utilizadores sobre como adicionar a aplicação ao Teams e começar a utilizar o chatbot ou o e-mail do Teams.

• Se uma aplicação SaaS utilizar a gestão de licenças da Microsoft, após a confirmação da subscrição da aplicação na página de destino do ISV, o utilizador tem de ser redirecionado para a gestão de licenças da Microsoft no Teams para evitar um beco sem saída e permitir que o utilizador faça a gestão de 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 da sua aplicação para fins de teste for complexa, forneça um documento funcional ponto a ponto, passos de configuração de ofertas SaaS ligados e instruções para gestão de licenças e utilizadores como parte das suas Notas de Certificação.

• A configuração da tabulação não pode ser um novo utilizador sem saída. Forneça uma mensagem sobre como concluir a ação ou o fluxo de trabalho. [Tem de corrigir]

  

• O utilizador não deve deixar a experiência de configuração do separador no Teams para criar conteúdos fora do Teams e, em seguida, regressar ao Teams para afixá-lo. A tela de configuração da guia deve explicar o valor da configuração e como configurá-lo. [Tem de corrigir]

  

• O ecrã de configuração do separador 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. [Tem de corrigir]

  

  

• As aplicações que exigem que os utilizadores introduzam um URL durante a configuração de um separador têm de:

  • Forneça uma orientação adequada para o utilizador adquirir ou gerar o URL. [Tem de corrigir]

  • Verifique se existe um URL relevante ou adequado à funcionalidade da aplicação de acordo com a descrição da aplicação. [Tem de corrigir]

    

    

• Hiperligação as informações de contacto no ecrã de configuração em vez de texto simples para ajudar os utilizadores a contactá-lo para obter requisitos de suporte. [Tem de corrigir]

• Para uma experiência de utilizador de primeira execução totalmente integrada, recomendamos que hiperliga o URL de suporte ou o e-mail no ecrã de configuração. [Boa solução]

• A área de ecrã de início de sessão não deve utilizar logótipos grandes. [Tem de 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 os logótipos duplicados da moldura I, uma vez que a arquitetura de separador já apresenta o ícone e o nome da aplicação. [Boa solução]

  

  

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

• Os separadores não devem fornecer navegação que entre em conflito com a navegação principal do Teams. Se fornecer uma navegação à esquerda no seu separador, este não deve incluir apenas ícones ou ícones com texto empilhado. Não pode ser um trilho minimizá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 utilize menus de opções em vez de tabulação à esquerda. [Tem de corrigir]

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

  

  

• Se o separador tiver uma barra de ferramentas no trilho esquerdo sem qualquer componente de navegação, a barra de ferramentas tem de deixar um espaçamento de 20 píxeis no painel de navegação esquerdo do Teams. [Tem de corrigir]

  

• As páginas secundárias e terciárias num separador têm de ser abertas numa vista de nível dois (L2) e nível três (L3) na área do separador main, que é navegada através de trilhos ou navegação à esquerda. Também pode utilizar os seguintes componentes para ajudar na navegação num separador:

  • Botões de voltar

  • Cabeçalhos da página

  • Menus de hambúrguer

    

• As ligações avançadas nos separadores não podem ligar a uma página Web externa, mas sim ao Teams. Por exemplo, caixas de diálogo ou outros separadores. [Tem de corrigir]

  

• Os separadores não podem permitir que os utilizadores naveguem fora do Teams para obter a experiência principal da aplicação. As guias podem redirecionar para fora do Teams para fluxos de trabalho não principais. Por exemplo, para gerar um tíquete de suporte. [Tem de corrigir]

  

  

• O deslocamento horizontal não pode estar presente num separador na reunião. [Tem de corrigir]

• As caixas de diálogo na reunião utilizadas na sua aplicação não devem permitir o deslocamento horizontal. Utilize caixas de diálogo na reunião com moderação e para cenários leves e orientados para tarefas. Pode especificar a largura da moldura I da caixa de diálogo na reunião dentro do intervalo de tamanho suportado para ter em conta diferentes cenários. [Tem de corrigir]

• As caixas de diálogo utilizadas na sua aplicação não podem permitir o deslocamento horizontal. As caixas de diálogo permitem-lhe selecionar tamanhos diferentes para tornar o conteúdo reativo sem a necessidade de deslocamento horizontal. Se necessário, pode utilizar um Stageview (um componente de IU de ecrã inteiro para apresentar o conteúdo Web) para concluir o fluxo de trabalho sem deslocamento horizontal. [Tem de corrigir]

• O deslocamento horizontal presente no separador num separador pessoal de chat, canal e detalhes na reunião não é permitido em qualquer âmbito se toda a tela de separador for deslocável, a menos que o seu separador utilize uma tela infinita com elementos de IU fixos. [Tem de corrigir]

  

  

  

  

  

• O utilizador tem de ter uma opção para ir para o estado de trabalho anterior. [Tem de corrigir]

  

  

• O deslocamento horizontal em Cartões Ajustáveis não pode estar presente no Teams. [Tem de corrigir]

• O trilho inferior utilizado para a navegação nos separadores não pode entrar em conflito com a navegação da aplicação móvel nativa do Teams. [Tem de corrigir]

  

• O conteúdo não pode truncar ou sobrepor-se no separador. [Tem de corrigir]

  

• Os utilizadores têm de conseguir anular a última ação no separador. [Tem de 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. [Boa solução]

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

  

  

• Os separadores têm de utilizar componentes com estilo teams, tais como tipos de letra do Teams, rampas de tipo, paletas de cores, sistema de grelha, movimento, tom de voz, sempre que possível. Para obter mais informações, confira diretrizes de design de guia. [Boa solução]

  

• Se a funcionalidade da aplicação exigir alterações nas definições, inclua um separador Definições . [Boa solução]

• Os separadores têm de seguir o design de interação do Teams, como a navegação na página, a posição e a utilização de caixas de diálogo, hierarquias de informações. Para obter mais informações, consulte Microsoft Teams Fluent UI Kit. [Boa solução]

• As experiências de tabulação devem ser totalmente responsivas em dispositivos móveis (Android e iOS). [Tem de 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 tecla de tabulação não pode conter elementos que obstruam ou impeçam completamente os fluxos de trabalho no separador. Por exemplo, bot dentro de um separador que não pode ser minimizado. [Tem de corrigir]

  

• A tecla de tabulação não pode ter uma funcionalidade quebrada. A oferta tem de ser uma solução de software utilizável e tem de fornecer a funcionalidade, as funcionalidades e os materiais a entregar, conforme descrito na listagem e noutros materiais relacionados. [Tem de corrigir]

• Se os separadores contiverem um rodapé, certifique-se de que remove todas as ligações não relacionadas com a funcionalidade da aplicação do rodapé. [Tem de corrigir]

• Os conteúdos na página de destino dos separadores configuráveis não devem ter o âmbito de utilização individual e não incluir conteúdo pessoal, como As Minhas Tarefas ou O Meu Dashboard. [Tem de corrigir]

  

• Após a experiência de configuração, a página de destino tem de mostrar uma vista de colaboração para toda a equipa. [Tem de 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. [Tem de corrigir]

• O conteúdo na página de aterrissagem das guias configuráveis deve ser contextualmente o mesmo para todos os membros do canal. [Tem de corrigir]

  

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

  

• A sua aplicação teams tem de seguir as diretrizes de design do bot do Teams.

• Tem de implementar uma caixa de diálogo para evitar uma resposta de bot multi-turn quando o fluxo de trabalho envolve o utilizador a realizar tarefas repetitivas. Por exemplo, utilize uma caixa de diálogo para capturar repetidamente o nome, a data de nascimento, o local e a designação em vez de utilizar conversações multiturno. [Tem de corrigir]

• Todas as ligações, respostas ou fluxos de trabalho danificados na sua aplicação têm de ser corrigidos. [Tem de corrigir]

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

  

  

• Os comandos do bot não devem levar um utilizador a um beco sem saída. Os comandos têm de fornecer sempre um caminho a seguir. [Tem de corrigir]

  

• Tem de listar pelo menos um comando de bot válido na items.commands.title secção do manifesto da aplicação e adicionar uma descrição adequada que dê clareza ao utilizador no comando do bot e à respetiva utilização. Os comandos do bot listados na commandLists secção do manifesto da aplicação são apresentados como comandos pré-preenchidos no menu de comandos do bot e fornecem um caminho a seguir para o novo utilizador interagir com o bot. [Boa solução]

• A resposta do bot não pode conter quaisquer avatares ou imagens oficiais do produto Microsoft. Utilize os seus próprios recursos na sua aplicação. A utilização de imagens de produtos Microsoft na sua aplicação não é permitida. Só pode copiar, modificar, distribuir, apresentar, licenciar ou vender imagens de produtos com direitos de autor da Microsoft se lhe for concedida permissão explícita no Contrato de Licença (EULA) End-User, termos de licenciamento que acompanham o conteúdo ou nas diretrizes da Marca e Marca Microsoft. [Tem de corrigir]

• Os bots têm de responder aos comandos do utilizador sem apresentar um indicador de carregamento contínuo. [Tem de corrigir]

• A resposta ao comando ajuda do bot não deve redirecionar o utilizador para fora do Teams. A resposta ao comando ajuda do bot pode redirecionar o utilizador para uma tela na aplicação Teams ou fornecer uma resposta rápida num Cartão Ajustável. [Tem de corrigir]

  

• Os bots têm sempre de fornecer uma resposta válida a uma entrada de utilizador, mesmo que a entrada seja irrelevante ou incorreta. [Tem de corrigir]

  

  

• Os carateres especiais, como a barra (/), não têm de ter o prefixo prefixo nos comandos do bot. [Tem de corrigir]

  

• Os bots têm de fornecer uma resposta válida a comandos de utilizador inválidos. Os bots não devem eliminar o utilizador ou apresentar um erro se um utilizador enviar um comando de bot inválido. [Tem de corrigir]

  

  

• A funcionalidade do bot tem de ser relevante para o âmbito no qual o bot está instalado e o bot tem de fornecer valor no âmbito instalado. [Tem de corrigir]

• Os bots não podem conter comandos duplicados. [Tem de corrigir]

• Os bots não devem apresentar um indicador de escrita depois de responderem ao comando do utilizador, mas podem apresentar um indicador de escrita enquanto respondem ao comando do utilizador. [Tem de corrigir]

• Os bots têm de fornecer uma resposta válida ao comando de ajuda escrito em minúsculas ou em maiúsculas que forneça ao utilizador um caminho a seguir ou permita que o utilizador aceda ao conteúdo de ajuda relacionado com a utilização do bot. Os bots têm de fornecer uma resposta válida mesmo quando o utilizador não iniciou sessão na aplicação. [Tem de corrigir]

  

  

• Os bots têm de fornecer uma resposta válida ao comando de ajuda .

  

• As respostas do bot em dispositivos móveis têm de ser reativas sem qualquer truncagem de dados que dificulte a utilização do bot do utilizador final para concluir os fluxos de trabalho pretendidos. [Tem de corrigir]

  

  

• Todas as ligações numa resposta de bot adaptável card têm de ser reativas. Qualquer ligação que coloque o utilizador fora da plataforma do Teams tem de ter um texto de redirecionamento claro, como Ver em.. ou Desta forma para.., um ícone de destaque 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. [Tem de corrigir]

  

• Por predefinição, se o bot não responder ou suportar qualquer comando de utilizador e for um bot unidirecional destinado apenas a notificar os utilizadores. Tem de definir isNotificationOnly como verdadeiro no manifesto da aplicação. [Tem de corrigir]

  

  

• A experiência de utilizador do bot não pode ser interrompida em plataformas móveis. O bot tem de estar totalmente reativo em dispositivos móveis. [Tem de corrigir]

• Um bot no âmbito pessoal tem de enviar sempre uma mensagem de boas-vindas ou fornecer iniciadores de pedidos. [Tem de corrigir]

  Se estiver a utilizar iniciadores de pedidos, certifique-se de que as seguintes diretrizes são cumpridas:

  Os iniciadores de pedidos ajudam os utilizadores a iniciar uma conversa com o bot. Para ativar os iniciadores de pedidos, a commands propriedade no manifesto da aplicação tem de ser definida.

  • O bot tem de fornecer pelo menos um comando que permita ao utilizador conhecer a proposta de valor da aplicação. [Tem de corrigir]
  • Os comandos ou iniciadores de linha de comandos têm de estar funcionais e devolver respostas. [Tem de corrigir]
  • A descrição do comando tem de ser coerente e comunicar claramente o valor do comando. [Tem de corrigir]
  • Os comandos ou iniciadores de pedidos têm de ser relevantes para a funcionalidade da aplicação. [Tem de corrigir]
  • O bot tem de ter, pelo menos, três comandos ou iniciais de linha de comandos exclusivos. [Boa solução]

  Se a sua aplicação enviar uma mensagem de boas-vindas, certifique-se de que as seguintes diretrizes são cumpridas:

  • Se a aplicação tiver um fluxo de configuração complexo (requer uma licença empresarial ou não tem um fluxo de inscrição intuitivo), os bots nessas aplicações têm de incluir sempre informações relacionadas com a configuração enquanto enviam uma mensagem de boas-vindas durante a primeira execução.

    Para uma melhor experiência, a mensagem de boas-vindas tem de incluir o valor oferecido pelo bot aos utilizadores, que instalaram o bot no canal, como configurar o bot e descrever resumidamente todos os comandos de bot suportados. 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. O bot não pode enviar mensagens de boas-vindas aos utilizadores individualmente (considera-se spaming). A mensagem também deve mencionar a pessoa que adicionou o bot.

  

  

• A mensagem de boas-vindas não pode ser apresentada sem êxito ao utilizador. A mensagem de boas-vindas tem de incluir o valor oferecido pelo bot aos utilizadores que instalaram o bot no canal, como configurar o bot e descrever resumidamente todos os comandos de bot suportados. Você pode exibir a mensagem de boas-vindas usando um Cartão Adaptável com botões para melhorar a usabilidade. [Tem de corrigir]

  

  

• O bot instalado num âmbito de chat de canal ou grupo não deve enviar uma mensagem de boas-vindas proativa a todos os membros da equipa no chat 1:1. [Tem de corrigir]

  

• O bot apenas de notificação só pode enviar uma mensagem de boas-vindas proativa num canal se a mensagem contiver informações importantes para que qualquer utilizador conclua a configuração do bot ou esclareça os cenários quando as notificações são acionadas. [Tem de corrigir]

• O bot instalado num âmbito de chat de canal ou grupo não deve enviar mensagens proativas (e não apenas mensagens de boas-vindas) irrelevantes para todos os utilizadores no chat de canal ou de grupo. Em vez disso, tem de enviar mensagens proativas ao utilizador através do chat 1:1. [Tem de corrigir]

• O bot instalado num âmbito de chat de canal ou grupo não deve permitir que os utilizadores iniciem fluxos de trabalho individuais. Os bots têm de concluir fluxos de trabalho individuais no chat 1:1 com o utilizador. [Tem de corrigir]

• A mensagem de boas-vindas do bot tem de chamar claramente a atenção para as limitações relacionadas com a utilização do bot no âmbito instalado. [Tem de corrigir]

  

  

• A mensagem de boas-vindas tem de ser acionada automaticamente na instalação da aplicação num âmbito pessoal. Se o bot não enviar uma mensagem de boas-vindas num âmbito pessoal, o utilizador será apresentado como um beco sem saída. Se a aplicação não incluir um fluxo de trabalho de configuração complexo, é opcional que o programador acione uma mensagem de boas-vindas no âmbito de chat do canal ou do grupo. [Tem de corrigir]

  

• As mensagens de boas-vindas só têm de ser acionadas uma vez na instalação do bot. As mensagens de boas-vindas não devem ser acionadas sempre que o utilizador invocar o comando de ajuda. A resposta do comando de ajuda tem de estar focada para incluir uma forma de o utilizador aceder à ajuda relacionada com o bot. [Tem de corrigir]

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

  

• O conteúdo da mensagem de boas-vindas tem de estar relacionado com o fluxo de trabalho do bot mencionado na descrição longa da aplicação e no âmbito da instalação. A mensagem de boas-vindas tem de incluir o valor oferecido pelo bot aos utilizadores que instalaram o bot no canal, como configurar o bot e descrever resumidamente todos os comandos de bot suportados. [Tem de corrigir]

• O bot não deve enviar várias mensagens de boas-vindas quando acionado na instalação da aplicação. [Tem de corrigir]

  

• O nome da aplicação na mensagem de boas-vindas tem de corresponder ao nome da aplicação no manifesto da aplicação. [Tem de corrigir]

  

• A mensagem de boas-vindas não pode apresentar nomes de plataformas de colaboração baseados em chats concorrentes, a menos que a aplicação forneça interoperabilidade específica.

• A mensagem de boas-vindas não deve redirecionar o utilizador para outra aplicação do Teams. Em vez disso, a mensagem de boas-vindas tem de deslocar o utilizador para concluir a sua primeira tarefa e descrever brevemente todos os comandos de bot suportados na aplicação. [Tem de corrigir]

• A mensagem de boas-vindas não pode conter ligações para qualquer marketplace de aplicações, incluindo o AppSource. [Tem de corrigir]

• Se a sua aplicação tiver um fluxo de trabalho de configuração complexo que necessite de instalação liderada por administradores, não tiver um fluxo de inscrição intuitivo e prontamente disponível ou exigir que os utilizadores concluam os passos de configuração fora da experiência do Teams e regressem, o bot tem de enviar uma mensagem de boas-vindas proativa num âmbito de chat de equipa ou de grupo após a instalação. [Tem de corrigir]

• Se o bot enviar uma mensagem de boas-vindas no canal, não deve enviá-la aos utilizadores individualmente (considera-se spaming). A mensagem de boas-vindas também tem de menção a pessoa que adicionou o bot. [Boa solução]

Os bots não podem enviar spam aos utilizadores ao enviar 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. [Tem de corrigir]

  

  

• Mensagens de bot em aplicativos pessoais:

  • Não envie várias mensagens numa sucessão rápida. [Tem de corrigir]

    

  • Envie uma mensagem com informações completas. [Tem de corrigir]

  • Evite conversas de vários turnos para concluir um único fluxo de trabalho repetitivo. [Tem de corrigir]

  • Utilize um formulário (ou caixa de diálogo) para recolher todas as entradas de um utilizador de uma só vez. [Tem de 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. [Tem de corrigir]

  

As notificações de bot devem incluir conteúdo relevante ao escopo definido pelo bot (equipe, bate-papo ou pessoal). [Tem de 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 apresentar mais conteúdos, considere utilizar uma caixa de diálogo ou um separador.

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 da aplicação (nome do bot, logótipo, ligação de privacidade e ligação de termos de serviço) têm de ser consistentes com os metadados do Bot Framework. [Tem de corrigir]

• Certifique-se de que o ID do bot no manifesto da aplicação corresponde ao ID do bot na última versão publicada da aplicação na Loja Teams. A alteração dos IDs de bot numa atualização de aplicação leva à perda permanente de todo o histórico de interação do utilizador com o bot para os utilizadores existentes da sua aplicação e inicia uma nova cadeia de conversação com o novo ID do Bot. [Tem de corrigir]

• Qualquer alteração ao nome da aplicação, metadados, mensagem de boas-vindas do bot ou respostas do bot tem de ser atualizada com um novo nome. [Tem de corrigir]

• O nome da aplicação na mensagem de boas-vindas do bot ou as respostas do bot têm de corresponder ao nome da aplicação no manifesto da aplicação. [Tem de corrigir]

• A instalação do bot num âmbito de chat de canal ou grupo para obter a lista de equipas para enviar notificações proativas para os utilizadores, uma vez que não são permitidas conversas de 1:1 para acionadores específicos da equipa. Por exemplo, uma aplicação que emparelha pessoas para uma reunião. [Tem de corrigir]

• O bot num canal ou chat de grupo utilizado apenas para obter as mensagens ou mensagens para enviar notificações proativas para os utilizadores, uma vez que as conversas 1:1 não são permitidas. [Tem de corrigir]

• Os bots instalados no âmbito de colaboração têm de fornecer um valor de utilizador no âmbito de colaboração. [Tem de corrigir]

• Se a sua aplicação do Teams utilizar a capacidade de extensão de mensagens, a sua aplicação tem de seguir as diretrizes de conceção da 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 apresente apenas os componentes necessários para concluir a ação de forma eficaz. O site completo não pode ser enquadrado na extensão de mensagens. [Tem de corrigir]

• As imagens de pré-visualização em Cartões Ajustáveis em extensões de mensagens têm de ser carregadas corretamente. [Tem de corrigir]

  

  

• A resposta da extensão de mensagens card tem de incluir o ícone da aplicação para evitar confusões do utilizador final. [Tem de corrigir]

• A sua aplicação não pode ter nenhuma funcionalidade quebrada. A aplicação não pode ser concluída sem saída nem impedir o utilizador de concluir um fluxo de trabalho numa extensão de mensagens. [Tem de corrigir]

• As extensões de mensagens têm de responder ou funcionar conforme pretendido no chat de grupo e nos âmbitos do canal. [Tem de corrigir]

• Tem de incluir uma forma de o utilizador iniciar sessão ou terminar sessão a partir da extensão de mensagens. [Tem de corrigir]

• As extensões de mensagens que utilizam URLs OpenAPI não podem fornecer redirecionamento em nenhuma chamada à API. As chamadas reais à API têm de ser servidas a partir do mesmo domínio ou subdomínio do domínio de 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. [Tem de 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, utilize Iniciar um Reunião do Skype para Iniciar Reunião, Carregar ficheiro para DocuSign para Carregar ficheiro. [Boa solução]

  

  

• Invocar uma ação de mensagem tem de permitir que o utilizador conclua o fluxo de trabalho. Os 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. [Tem de corrigir]

  

• Os comandos de ação duplicados não podem estar presentes. [Tem de corrigir]

• As ações de mensagens têm de permitir que o utilizador conclua o fluxo de trabalho conforme pretendido sem uma resposta inválida. [Tem de corrigir]

• As aplicações com apenas a extensão de mensagens baseadas em ações têm de ter o seguinte estado final:

  • Publique uma ação relevante como uma notificação no contexto em que a extensão de mensagem é invocada ou no chat de bot 1:1 com base no cenário do utilizador. [Tem de corrigir]

  • Permitir que os utilizadores partilhem cartões com outros utilizadores com base na ação tomada. Isto serve para garantir que as aplicações não efetuam ações silenciosas. Por exemplo, um pedido de suporte é criado com base numa mensagem num canal, mas a aplicação não envia uma notificação ou não fornece uma forma de pedir ao utilizador para partilhar os detalhes da permissão após a criação do pedido. [Tem de corrigir]

[Tem de corrigir]

• Se a aplicação tiver declarado a supportsAnonymizedPayloads propriedade no manifesto da aplicação e o utilizador não tiver instalado a aplicação, a ligação da aplicação terá de ser desfraldada e mostrar a caixa de diálogo adicionar aplicação após a card estar selecionada. [Tem de 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. [Tem de corrigir]

• As aplicações só têm de declarar que estão sob a propriedade direta do publicador da aplicação na messageHandler secção de desfraldamento da ligação do manifesto da aplicação. Não pode conter *.botframework.com. [Tem de corrigir]

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

  

  

• @mention os executáveis têm de ser claros, fáceis de compreender e legíveis.

  

Uma caixa de diálogo (referida como módulo de tarefas no TeamsJS v1.x) tem de incluir um ícone e o nome abreviado da aplicação à qual está associada. As caixas de diálogo não devem incorporar uma aplicação inteira e apresentar apenas os componentes necessários para concluir uma ação específica.

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

• As suas aplicações do Teams têm de seguir as diretrizes de conceção da extensão reunião.

• Com a experiência da aplicação na reunião, pode envolver os participantes durante a reunião através dos separadores, da caixa de diálogo e da funcionalidade de partilha na reunião para encenar. Se a sua aplicação suportar a extensão de reunião do Teams, tem de proporcionar uma experiência de reunião reativa alinhada com a experiência de reunião do Teams. [Tem de corrigir]

• As aplicações de extensibilidade de reuniões têm de oferecer uma experiência de reunião reativa alinhada com a experiência de reunião do Teams. A experiência em reuniões é obrigatória para uma aplicação do Teams que suporte a extensibilidade de reuniões, mas as experiências pré e pós-reunião não são obrigatórias. [Tem de corrigir]

  • Com a experiência de aplicativo de pré-reunião, os usuários podem encontrar e adicionar aplicativos de reunião. Os utilizadores também podem realizar tarefas de pré-reunião, como desenvolver um inquérito para consultar 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 da aplicação pós-reunião, os utilizadores podem ver os resultados da reunião, como os resultados do inquérito ou o feedback e outros conteúdos da aplicação. 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 podem ser levados para fora da reunião do Teams para concluir os fluxos de trabalho de utilizador principais da sua aplicação.

  

• A sua aplicação tem de oferecer valor para além de fornecer apenas cenas personalizadas do Modo Juntos no Teams. [Tem de corrigir]

• Tem de declarar groupChat como um âmbito configurableTabs em e meetingDetailsTab, meetingChatTabe meetingSidePanel como uma propriedade de contexto no manifesto da aplicação para ativar a sua aplicação para reuniões no Teams mobile. [Tem de corrigir]

• As telas de reuniões não podem ser apresentadas sem êxito a um participante da reunião. As telas de reunião têm de mostrar uma mensagem de falha correta para as limitações da aplicação, como dependência específica da região. [Tem de corrigir]

• O cabeçalho da tela da reunião tem de apresentar o nome da aplicação correto para evitar confundir o participante da reunião. [Tem de corrigir]

• Tem de incluir uma opção para o utilizador terminar sessão ou terminar sessão na extensão da reunião. [Tem de corrigir]

• Os separadores de reuniões em plataformas móveis têm de incluir fluxos de trabalho relevantes. As páginas em branco não podem estar presentes num separador de reunião. [Tem de corrigir]

• A fase de reunião é uma tela de participação focada, intuitiva e colaborativa. A fase de reunião não deve incorporar a experiência completa do site. [Tem de corrigir]

• A aplicação não pode mostrar o ecrã de carregamento contínuo, o erro ou a funcionalidade quebrada que impede o utilizador ou bloqueia a conclusão de um fluxo de trabalho num cenário de reunião. [Tem de corrigir]

  

• A aplicação não tem de abrir uma nova instância do Teams para iniciar uma reunião. As telas de reuniões são uma extensão das capacidades do Teams que promovem a colaboração em tempo real e as novas reuniões têm de ser sempre abertas na instância ativa do Teams. [Tem de corrigir]

• As aplicações de reunião têm de concluir fluxos de trabalho na plataforma do Microsoft Teams sem redirecionar para plataformas baseadas em chat concorrentes. [Tem de corrigir]

  

• Se a sua aplicação suportar vistas baseadas em funções e determinados fluxos de trabalho não estiverem disponíveis para todos os participantes, recomendamos que implemente as mensagens adequadas para os participantes no separador e no painel lateral, indicando que a aplicação se destina à vista do organizador e forneça detalhes sobre como os participantes recebem as notas da reunião, os itens de ação e as agendas de atualização. [Tem de 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. [Tem de 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. [Tem de 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. [Tem de corrigir]

  

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

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

  

• As extensões de mensagens devem funcionar da mesma forma durante as reuniões, assim como fora delas. [Tem de corrigir]

• Deve responder. [Tem de corrigir]

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

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

  

  

• Não deve incluir mais de um botão fechar. Pode confundir os utilizadores, uma vez que já existe um botão de cabeçalho incorporado para dispensar o separador. [Tem de corrigir]

• Não pode ter deslocamento horizontal. [Tem de corrigir]

  

  

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

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

  

  

• Não é possível utilizar caixas de diálogo. [Tem de corrigir]

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

  

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

• Modo Juntos: certifique-se de que considera as seguintes melhores práticas para uma experiência de criação de cenários: [Tem de corrigir]

  • Todas as imagens estão no formato .png.
  • O pacote final com todas as imagens juntas não pode 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.

Para utilizar a API shareAppContentToStage , tem de declarar as permissões RSC corretas. No manifesto da aplicação, tem de configurar a authorization propriedade . Atualize a name propriedade como MeetingStage.Write.Chat e type como Delegated no resourceSpecific campo. [Tem de 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. [Tem de corrigir]

• As suas aplicações do Teams têm de seguir as diretrizes de conceção das notificações do feed de atividades.

• O fluxo de trabalho irrelevante, incorrido, sem resposta ou danificado não deve estar presente depois de o utilizador selecionar uma notificação no feed de atividades do Teams. Os utilizadores não podem ser impedidos de concluir um fluxo de trabalho depois de selecionarem uma notificação do feed de atividades. [Tem de corrigir]

• Inclua o nome da sua aplicação na notificação do feed de atividades para que os utilizadores finais compreendam a origem ou o acionador da notificação sem confusões. [Tem de corrigir]

• A aplicação tem de acionar notificações para todos os cenários de notificação mencionados na descrição longa da aplicação, experiência de primeira execução da aplicação e em cenários declarados activityTypes no manifesto da aplicação. [Tem de corrigir]

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

• Tem de chamar a atenção para as limitações de notificação (se existirem) na descrição longa da sua aplicação ou na experiência de primeira execução da aplicação. [Tem de corrigir]

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

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

• As aplicações não podem enviar mais de 10 notificações por minuto a um utilizador. [Tem de corrigir]
• Os bots e o feed de atividades não devem acionar notificações duplicadas. [Tem de corrigir]
• As notificações devem fornecer valor aos usuários e não devem ser usadas em eventos triviais ou irrelevantes. [Tem de corrigir]

• As notificações devem aderir ao layout e à experiência do feed de atividades do Teams. [Tem de corrigir]
• Ao selecionar uma notificação, o usuário deve ser direcionado ao conteúdo relevante no Teams. [Tem de 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 a publicar uma aplicação na Loja Teams, tem de concluir os seguintes escalões 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, é apresentado um distintivo azul verificado na caixa de diálogo de consentimento do Microsoft Entra e noutros ecrãs. Para obter mais informações, consulte Marcar seu aplicativo como verificado pelo editor. [Tem de 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. [Boa solução]

Para uma aplicação que não está listada anteriormente, não pode concluir o Atestado do Publisher até que a aplicação esteja disponível na Loja Teams. Se estiver a atualizar uma aplicação já listada, conclua o Atestado do Publisher antes de submeter a versão mais recente da aplicação.