Compartilhar via


Diretrizes de validação da Teams Store

Seguir estas diretrizes aumenta as hipóteses de a sua aplicação passar no processo de submissão da Microsoft Teams Store. As diretrizes específicas do Teams complementam as políticas de certificação do marketplace comercial da Microsoft e são atualizadas com frequência para refletir novos recursos, comentários do usuário e alterações nas regras de negócios.

Observação

  • É possível que algumas diretrizes não sejam pertinentes ao seu aplicativo. Por exemplo, se seu aplicativo não incluir um bot, você poderá ignorar as diretrizes relacionadas ao bot.
  • Cruzamos essas diretrizes com as políticas de certificação comercial da Microsoft e adicionamos o que fazer e o que não fazer com exemplos de cenários de aprovação ou reprovação encontrados em nosso processo de validação.
  • Determinadas diretrizes estão marcadas como Tem de corrigir. Se o envio do aplicativo não atender a essas diretrizes obrigatórias, você receberá um relatório de falha conosco com etapas para atenuar. A submissão da aplicação passa na validação da Loja Teams apenas depois de ter corrigido os problemas.
  • Outras diretrizes estão marcadas como Boa solução. Para uma experiência de utilizador ideal, recomendamos que corrija os problemas. No entanto, a submissão da sua aplicação não será impedida de publicar na Loja Teams se optar por não corrigir os problemas.

Proposta de valor

Esta secção está em conformidade com o número 1140.1 da política de certificação comercial da Microsoft e fornece mais orientações aos programadores de aplicações do Microsoft Teams sobre a proposta de valor da oferta.

As aplicações têm de fornecer valor aos utilizadores ao permitir que completem fluxos de trabalho funcionais que incentivem a utilização repetida. Expanda as secções seguintes para saber mais sobre a proposta de valor:

Separadores

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

O gráfico mostra um exemplo de uma aplicação com um fluxo de trabalho valioso para canalizar membros dentro de uma equipa.

O gráfico mostra um exemplo de uma aplicação com todo o site num fotograma I sem qualquer opção anterior.


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

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.

Captura de ecrã a mostrar um exemplo de uma notificação apenas bit com informações inadequadas na pré-visualização.


Extensões de mensagens

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

    validation-search-base-messaging-ext-adequete-info

    validation-search-base-messaging-ext-inadequete-info


Desfraldamento da ligação

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.


Voltar ao início

Nome do aplicativo

[Tem de corrigir]

Esta secção está em conformidade com o número 1140.1.1 da política de certificação comercial da Microsoft e fornece mais orientações aos programadores sobre a atribuição de nomes às respetivas aplicações.

Expandir para saber mais

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]

Dica

A imagem corporativa da sua aplicação na Loja Teams e no AppSource, incluindo o nome da aplicação, o nome do programador, o ícone da aplicação, as capturas de ecrã do AppSource, o vídeo, a breve descrição e o site em separado ou juntos não devem representar uma oferta oficial da Microsoft, a menos que a sua aplicação seja uma oferta oficial do Microsoft 1P.

Duplicar Aplicação

  • As aplicações do mesmo programador que oferecem a mesma funcionalidade têm de partilhar uma listagem de aplicações, a menos que os requisitos de conformidade de privacidade exijam listagens de aplicações separadas ou listagem de aplicações separada para suportar a cloud governamental. Tem de criar na sua lógica de negócio e publicar apenas uma listagem. [Tem de corrigir]

    • Para cumprir o requisito de suporte de várias regiões, tem de criar na sua lógica de negócio e publicar apenas uma listagem.

    Captura de ecrã a mostrar o cenário aprovado do requisito de região feito com lógica.

    • Para cumprir vários requisitos de ponto final para a implementação no local e na cloud, tem de criar na sua lógica de negócio e publicar apenas uma listagem.

Adequado para o consumo no local de trabalho

[Tem de corrigir]

Esta secção está em conformidade com o número da política de certificação comercial da Microsoft 1140.1.2, 100.8 e 100.10 e fornece orientações adicionais aos programadores sobre a criação de aplicações adequadas para o local de trabalho.

Expandir para saber mais

O conteúdo do aplicativo deve ser adequado para consumo geral no local de trabalho e seguir todas as restrições listadas nas políticas de certificação do mercado comercial. É proibido o conteúdo relacionado à religião, política, jogos de azar e entretenimento prolongado. [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]

Captura de ecrã a mostrar o cenário transmitido da aplicação agregadora de conteúdos para comunicar problemas.

Plataformas e serviços semelhantes

[Tem de corrigir]

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

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

Nomes de recursos

Os nomes das funcionalidades da aplicação em botões e outro texto de IU não devem utilizar terminologia reservada para o Teams e outros produtos Microsoft. Por exemplo, Iniciar reunião, Fazer chamada ou Iniciar conversa são nomes de funcionalidades utilizados pela Microsoft no Microsoft Teams. Se necessário, inclua o nome da sua aplicação para tornar a distinção clara, como Iniciar reunião da Contoso.

Autenticação

[Tem de corrigir]

Esta secção está em conformidade com o número 1140.1.4 da política de certificação comercial da Microsoft e fornece orientações aos programadores sobre a autenticação das suas aplicações com serviços externos.

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

Expandir para saber mais

Autenticação com serviços externos

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

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

    • Os aplicativos que dependem de contas ou serviços externos devem fornecer uma experiência de entrada, saída e inscrição clara e simples. [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.

Áudio

  • Se a principal intenção da aplicação for ouvir música, tem de suportar, pelo menos, um âmbito de colaboração com um fluxo de trabalho ponto a ponto específico da aplicação. Por exemplo, partilhar a lista de reprodução, configurar ou afixar a lista de reprodução e ouvir música de forma síncrona. [Tem de corrigir]

  • As aplicações publicadas com a principal intenção de permitir que os utilizadores ouçam música no Teams são recomendadas para incluir uma experiência colaborativa de escuta conjunta. [Boa solução]

Segurança

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

Voltar ao início

Informações financeiras

[Tem de corrigir]

Esta secção está em conformidade com o número 1140.3.1 da política de certificação comercial da Microsoft e fornece orientações sobre a transmissão de informações financeiras na interface do Teams e notifica os programadores de cenários de pagamento restritos na versão móvel (Android e iOS) da respetiva aplicação Teams.

Expandir para saber mais

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]

validation-financial-info

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]

    validation-financial-info-in-app-purchase

    validation-online-store

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

Bots

[Tem de corrigir]

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

Expandir para saber mais

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

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

validation-bot-confirmation

Domínios externos

[Tem de corrigir]

Esta secção está em linha com o número 1140.3.3 da política do marketplace comercial da Microsoft e fornece orientações para programadores sobre a utilização de domínios restritos na propriedade do manifesto da aplicação validDomains .

Expandir para saber mais

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.

Conteúdo confidencial

[Tem de corrigir]

A sua aplicação não pode publicar dados confidenciais, como card de crédito, detalhes de pagamento financeiro, estado de funcionamento, rastreio de contactos ou outras informações pessoais (PII) a uma audiência que não se destina a ver o conteúdo.

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

Funcionalidade e desempenho gerais

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

  • A orientação de encaminhar é obrigatória para os utilizadores administradores e existentes. Pode adicionar orientações rápidas como hiperligações para se inscrever, começar, contactar-nos, ligações de ajuda ou e-mail.
  • Não é necessário chamar a dependência da conta ou as limitações na funcionalidade da aplicação, mas é obrigatório adicioná-la na descrição longa do manifesto da aplicação e na listagem de aplicações do AppSource.
  • Tem de chamar a atenção para qualquer dependência dos administradores de inquilinos para os novos utilizadores. Se não existir nenhuma dependência, é obrigatório fornecer uma inscrição, contactar-nos, ligação de introdução ou e-mail.

Voltar ao início

Iniciar a funcionalidade externa

[Tem de corrigir]

As aplicações não podem retirar os utilizadores do Teams para cenários de utilizador principais. Os conteúdos e interações da aplicação têm de ocorrer nas capacidades do Teams, como bots, Cartões Ajustáveis, separadores e caixas de diálogo (referidos como módulos de tarefas no TeamsJS v1.x).

Observação

Para redirecionar os utilizadores da sua aplicação Teams para a sua experiência nativa através de uma ligação avançada com um protocolo como , ou , inicie a ligação avançada numa nova janela ao chamar o window.open método ou utilizar uma etiqueta de âncora com target="_blank".webex:mailto:tel:

Expandir para saber mais
  • Vincule usuários dentro do aplicativo Teams e não a um site ou aplicativo externo. Para cenários que exigem funcionalidade externa, seu aplicativo deve ter permissão explícita do usuário para iniciar a funcionalidade. [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.

Compatibilidade

[Tem de corrigir]

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

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

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

Tempo de resposta

[Tem de corrigir]

As aplicações do Teams têm de responder dentro de um período de tempo razoável ou mostrar um indicador de carregamento ou escrita, mensagem ou aviso.

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

Aplicações com tecnologia Inteligência Artificial

Explore os recursos concebidos para o ajudar com práticas responsáveis de Inteligência Artificial (IA) em todas as fases da inovação, como o Microsoft RAI Toolkit e o HaX Toolkit Project.

Esta secção está em conformidade com a política do marketplace comercial da Microsoft para Aplicações com conteúdo gerado pela IA e a política do marketplace comercial da Microsoft para Aplicações através de capacidades de reconhecimento facial.

Aplicações com conteúdo gerado por IA

  • A aplicação não pode gerar, conter ou fornecer acesso a conteúdo gerado por IA inadequado, prejudicial ou ofensivo, consistente com as políticas do marketplace comercial existentes descritas na versão 100.10. [Tem de corrigir]

    • Considere utilizar qualquer um dos seguintes procedimentos:
      • Utilize a biblioteca de IA do Teams, a interface centrada no Teams para modelos de linguagem comuns baseados em GPT e motores de intenção do utilizador. [Boa solução]
      • Utilização de hooks de moderação, que podem ser utilizados para regular as respostas do bot através da API de moderação. [Boa solução]
      • Adicione a capacidade de varrimento de conversações, que o ajuda a monitorizar conversações e a intervir quando as conversações se desviam. [Boa solução]
  • A aplicação tem de fornecer mecanismos para que os utilizadores da aplicação comuniquem conteúdos inadequados, prejudiciais ou ofensivos ao programador através de qualquer um dos seguintes mecanismos: [Tem de corrigir]

    • Descrição da aplicação, incluindo o ID de correio ou a ligação para o portal para registar o problema.
    • No mecanismo da aplicação para registar o problema, juntamente com uma referência específica ao conteúdo inadequado.
  • Tem de tomar medidas oportunas relativamente às preocupações comunicadas. [Tem de corrigir]

  • A aplicação tem de descrever claramente a funcionalidade de IA antes de o cliente adquirir a oferta consistente com a política 100.1.3 e pedir ao utilizador para rever as informações como parte da funcionalidade na aplicação. [Tem de corrigir].

    Captura de ecrã a mostrar a descrição da funcionalidade ia.

Aplicações que utilizam capacidades de reconhecimento facial

Observação

As aplicações nesta categoria podem ser submetidas a uma revisão adicional da adesão aos princípios de IA Responsável da Microsoft.

  • A aplicação não pode permitir a utilização de capacidades de reconhecimento facial para identificar um indivíduo a ser utilizado por ou para um departamento de polícia no Estados Unidos. [Tem de corrigir]
  • Para aplicações que utilizam reconhecimento facial ou tecnologias de inferência emocional, tem de fornecer uma etiqueta ou indicação proeminente de cada uma destas capacidades na descrição da aplicação. [Tem de corrigir]
    • Aplicações que usam expressões faciais ou movimentos faciais para inferir estados emocionais, como raiva, nojo, felicidade, tristeza, surpresa, medo ou outros termos comumente usados para descrever o estado emocional de uma pessoa podem ser restringidos com base na revisão.
    • É permitida a utilização de expressões faciais e movimentos para detetar e classificar apenas elementos faciais individuais, como sorrisos ou sobrancelhas levantadas. A principal distinção é entre a deteção de expressões faciais ou movimentos como sinais visuais versus a inferência de um estado emocional.

Pacote de aplicações e listagem da Loja Teams

[Tem de corrigir]

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

Dica

  • Tem de garantir que as contas de teste fornecidas ou o ambiente de teste são válidos para sempre, ou seja, até que a aplicação esteja ativa no marketplace comercial.

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

    • Etapas para configurar as contas de teste do aplicativo caso o aplicativo dependa de contas externas para autenticação.
    • Resumo de comportamento esperado do aplicativo para os fluxos de trabalho principais no Teams.
    • Descreva claramente limitações, condições ou exceções à funcionalidade, funcionalidades e materiais a entregar na descrição longa da aplicação e materiais relacionados.
    • Ênfase em quaisquer considerações para testadores ao validar o envio do aplicativo.
    • Pré-povoar as contas de teste com dados fictícios para ajudar nos testes.
    • Se estiver a fornecer as suas contas de teste, certifique-se de que ativa a integração de terceiros.

Voltar ao início

Manifesto do aplicativo

[Tem de corrigir]

O manifesto da aplicação define a configuração da sua aplicação.

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

Utilizações do esquema de manifesto da aplicação mais recente

  • Se a sua aplicação utilizar o Início de sessão único (SSO), tem de declarar Microsoft Entra ID no manifesto da aplicação para autenticação de utilizador. [Tem de corrigir]

  • Tem de utilizar um esquema de manifesto de aplicação lançado publicamente. Pode atualizar o pacote de aplicação para utilizar uma versão pública do esquema de manifesto de aplicação 1.10 ou posterior. [Tem de corrigir]

  • Quando submete uma atualização de aplicação, só aumenta o número da versão da aplicação. O ID da aplicação atualizada tem de corresponder ao ID da Aplicação publicada. [Tem de corrigir]

  • A presença de ficheiros adicionais no pacote de aplicações não é aceitável. [Tem de corrigir]

  • O número da versão tem de ser o mesmo no esquema do ficheiro de manifesto da aplicação e no esquema de manifesto da aplicação de idiomas adicionais. [Tem de corrigir]

  • Tem de utilizar a versão 1.5 ou posterior do esquema de manifesto de aplicação para localizar a sua aplicação. Para utilizar o esquema da aplicação versão 1.5 ou posterior no ficheiro manifest.json, atualize o $schema atributo para 1.5 ou posterior. Atualize a manifestVersion propriedade para a $schema versão (1.5 neste caso). [Tem de corrigir]

  • Quando adiciona, atualiza ou remove uma capacidade existente, adiciona ou remove o manifesto da aplicação ou metadados do Centro de Parceiros, tem de aumentar o número da versão da aplicação e submeter o novo manifesto de aplicação na sua conta do Centro de Parceiros para validação. [Tem de corrigir]

  • A cadeia de versão tem de seguir a especificação semântica de controlo de versões (SemVer) padrão (MAJOR). MENOR. PATCH). [Tem de corrigir]

  • Se a sua aplicação exigir que os administradores revejam as permissões e concedam consentimento no centro de administração do Teams, tem de declarar webapplicationinfo no manifesto da aplicação. Se webapplicationinfo não for declarado no manifesto da aplicação, a página Permissões da sua aplicação no centro de administração do Teams é apresentada como ... [Tem de corrigir]

  • Como parte da certificação de aplicações do Teams, tem de submeter uma versão de produção do manifesto da aplicação. [Tem de corrigir]

  • Recomendamos que declare o ID do Programa de Parceiros da Microsoft Cloud (ID do CCP), anteriormente conhecido como Microsoft Partner Network (ID do MPN) no manifesto da aplicação. O ID do CCP ajuda a identificar a organização parceira que cria a aplicação. [Boa solução]

  • Os âmbitos e/ou o contexto declarados no manifesto da aplicação têm de estar visíveis na aplicação. [Tem de corrigir]

Ícones do aplicativo

[Tem de corrigir]

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

Expandir para saber mais

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]

    Captura de ecrã a mostrar que o ícone de cor e o ícone de destaque são iguais.

    Captura de ecrã a mostrar que o ícone de cor e o ícone de destaque não são iguais.

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

Descrições do aplicativo

Tem de ter uma descrição curta e longa para a sua aplicação. A descrição da aplicação ajuda a melhorar a deteção de aplicações na Loja Teams. As descrições na configuração da aplicação e no Centro de Parceiros têm de ser as mesmas.

O gráfico mostra um exemplo de uma descrição adequada da aplicação na aplicação Teams.

O gráfico mostra um cenário com falhas para uma descrição inadequada da aplicação.



Expandir para saber mais

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]

    O gráfico mostra um exemplo de informações de marketing comparativa na descrição da aplicação.

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

    O gráfico mostra um exemplo de detalhes de contacto hiperligados nas descrições da aplicação.

    O gráfico mostra um exemplo de detalhes de contacto não hiperligados nas descrições da aplicaçã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

    O gráfico mostra um exemplo de limitações destacadas na descrição da aplicação.

    O gráfico mostra um exemplo de limitações não destacadas nas descrições da aplicação.

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

    O gráfico mostra um exemplo de referência correta ao Teams na descrição da aplicação.

    O gráfico mostra um exemplo de referência incorreta ao Teams na descrição da aplicação.

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.

    Gráfico mostra um exemplo de abreviatura da Microsoft como MS ou MSFT pela primeira vez na descrição da aplicação.

    O gráfico mostra um exemplo de não abreviar a Microsoft como MS ou MSFT pela primeira vez na descrição da aplicação.

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

    O gráfico mostra um exemplo de como não indicar a oferta da Microsoft na descrição da aplicação.

    Gráfico que mostra um exemplo de como escrever a descrição da aplicação sem utilizar slogans e taglines 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.

    O gráfico mostra um exemplo de descrição longa da aplicação sem erros.

    O gráfico mostra um exemplo de descrição longa da aplicação com erros de digitação e erros.

  • Incluir links ao AppSource.

    O gráfico mostra um exemplo de um cenário de falha com ligações para o AppSource na descrição longa da aplicação.

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

Capturas de tela

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



Expandir para saber mais

Lembre-se do seguinte:

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

O que fazer:

  • Concentre-se nas 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]

    Captura de ecrã a mostrar o cenário transmitido da funcionalidade da aplicação em dispositivos móveis.

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

    Captura de ecrã a mostrar o cenário de falha do conteúdo suplementar utilizado na captura de ecrã.

    Captura de ecrã a mostrar o cenário de falha da captura de ecrã da IU real da aplicação.

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

    Captura de ecrã a mostrar o cenário de falha da funcionalidade ou integração da aplicação.

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

    Captura de ecrã a mostrar o cenário transmitido da funcionalidade da aplicação Teams em clientes MS 365.

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

    Captura de ecrã a mostrar o cenário transmitido de atenção do utilizador para a funcionalidade da aplicação.

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

    Captura de ecrã a mostrar o cenário transmitido da captura de ecrã da capacidade de separador.

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.

    Captura de ecrã a mostrar o cenário de falha de funcionalidades de aplicações não relacionadas no Teams.

Vídeos

Um vídeo na listagem de aplicações é uma das formas mais eficazes de comunicar o motivo pelo qual as pessoas têm de utilizar a sua aplicação. Pode adicionar o URL de vídeo do YouTube ou vimeo que fornece o valor da sua aplicação. Além disso, como melhor prática, recomendamos que adicione um vídeo que forneça instruções de demonstração ou cenário da sua aplicação. [Boa solução]

Se optar por submeter um vídeo como parte da listagem de aplicações na sua conta do Centro de Parceiros, certifique-se de que cumpre os seguintes critérios:

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

  • O vídeo tem de demonstrar como configurar e utilizar a aplicação.

  • O vídeo tem de estar numa forma narrativa.

  • A duração do vídeo tem de ser de 60 a 90 segundos para um vídeo de valor e a duração recomendada para um vídeo de instruções é de 3 a 5 minutos. [Boa solução]

  • Tem de desativar os anúncios das definições da sua conta do YouTube ou vimeo antes de submeter a ligação de vídeo na listagem de aplicações. [Tem de corrigir]

  • O vídeo tem de realçar as funcionalidades e a integração da sua aplicação no Teams. [Tem de corrigir]

  • O vídeo tem de estar disponível como uma ligação funcional. [Tem de corrigir]

  • O vídeo tem de estar no formato https://www.youtube.com/watch?v=:id ou https://youtu.be/:id no YouTube e https://vimeo.com/:id no Vimeo.

    Captura de ecrã a mostrar o cenário de falha do vídeo submetido como parte da listagem de aplicações no centro de parceiros.

  • O vídeo pode ser apresentado na primeira posição do carrossel de capturas de ecrã ou vídeos nos detalhes da aplicação (Loja Teams e centro de Administração) e nas páginas do AppSource. [Boa solução]

  • As instruções do vídeo sobre demonstração ou cenário têm de ter como objetivo educar os utilizadores e não promover a sua aplicação.

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



Política de privacidade

[Tem de corrigir]

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

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

Termos de uso

[Tem de corrigir]

Use as seguintes diretrizes para escrever o Termos de uso:

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

[Tem de corrigir]

Os URLs de suporte da sua aplicação não devem exigir autenticação. Por exemplo, os utilizadores têm de ter permissão para contactá-lo sem iniciar sessão.

Expandir para saber mais

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

validation-support-links-auth

Localização

[Tem de corrigir]

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

  • O conteúdo dos metadados da aplicação tem de ser o mesmo em en-us e noutros idiomas de localização. [Tem de corrigir]

  • Os idiomas suportados têm de ser apresentados na descrição da aplicação AppSource. Por exemplo, esta aplicação está disponível em X (X= idioma localizado). [Tem de corrigir]

  • Se as definições de cliente do utilizador não corresponderem a nenhum dos seus idiomas adicionais, o idioma predefinido é utilizado como a linguagem de contingência final. Atualize a localizationInfo propriedade com o idioma predefinido correto que a sua aplicação suporta. [Tem de corrigir]

  • Atualize a localizationInfo propriedade com o idioma predefinido correto que a sua aplicação suporta ou adicione conteúdo localizado para o manifesto da aplicação e a descrição longa e breve do Centro de Parceiros. [Tem de corrigir]

Aplicativos vinculados à oferta de SaaS

Esta secção está em linha com o número 1140.5 da política do marketplace comercial da Microsoft. Se estiver a criar uma aplicação do Teams ligada a uma oferta de Software como Serviço (SaaS), certifique-se de que cumpre estas diretrizes.

Geral
  • Os ISVs devem dar suporte à capacidade de vários usuários (Assinantes) no mesmo locatário gerenciarem sua própria assinatura e atribuir licenças aos usuários no locatário.
  • A oferta deve atender a todos os requisitos técnicos para aplicativos Teams vinculados a uma oferta SaaS.
  • Os aplicativos Teams vinculados à oferta SaaS devem atender a todos os requisitos definidos em 1000 Software as a Service (SaaS).
  • subscriptionOffer os detalhes mencionados no 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.

Metadados da oferta
  • 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.

Gestão de licenças e home page da oferta SaaS
  • 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.


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

Configurar e testar a aplicação SaaS

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.

Dica

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

Voltar ao início

Guias

Esta secção está em conformidade com o número 1140.4.2 da política do marketplace comercial da Microsoft. Se a sua aplicação incluir um separador, certifique-se de que cumpre estas diretrizes.

Dica

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


              
                             Configurar
  • A configuração da 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]

    Gráfico a mostrar um exemplo de Tabulação com um ponto inativo na configuração.

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

    validation-tabs-set-up-profile-name

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

    validation-tabs-setup-configuration-exp

    validation-tabs-set-up-configuration-screen

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

      Captura de ecrã a mostrar um exemplo de configuração de separadores com um caminho a seguir para o utilizador gerar um URL.

      Captura de ecrã a mostrar um exemplo de configuração de separadores sem um caminho a seguir para o utilizador gerar um URL.

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


Modos de exibição
  • A área de ecrã de início de sessão não deve utilizar logótipos grandes. [Tem de corrigir]

    validation-views-app-login

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

    val-views-multiple-tabs

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

    O gráfico mostra um exemplo de um separador sem cabeçalhos e logótipos duplicados.

    O gráfico mostra um exemplo de um separador com cabeçalhos e logótipos duplicados.


Navegaçã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.

    O gráfico mostra um exemplo de navegação num separador que não entra em conflito com a navegação principal do Teams.

    Gráfico a mostrar um exemplo do painel de navegação esquerdo que entra em conflito com a navegação principal do Teams.

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

    validation-nav-spacing-between-toolbar

  • 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

      Captura de ecrã a mostrar um exemplo de caixa de diálogo em reunião com vários níveis de navegação.

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

    validation-nav-view-button-not-linked-static-tab

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

    validation-nav-core-workflow-within-configuration

    validation-nav-core-workflow-redirects-outside

  • 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 gráfico mostra exemplos de todos os cenários em dispositivos móveis onde o deslocamento horizontal é permitido.

    O gráfico mostra um exemplo de deslocamento horizontal na placa Kanban.

    O gráfico mostra um exemplo de vista de lista com muitos componentes.

    O gráfico mostra um exemplo de deslocamento horizontal num quadro branco com tela infinita e quadro fixo.

    O gráfico mostra um exemplo de deslocamento horizontal na vista de lista.

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

     Captura de ecrã a mostrar a opção de botão anterior disponível.

    Captura de ecrã a mostrar o cenário de falha sem opção de botão anterior disponível.

  • 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 gráfico mostra um exemplo de um separador que entra em conflito com a navegação na aplicação móvel nativa do Teams.


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

    validation-usability-content-truncations

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

    O gráfico mostra um exemplo de um separador a responder a um tema no Teams.

    O gráfico mostra um exemplo de um Separador que não responde ao tema no Teams.

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

    Captura de ecrã a mostrar um exemplo de um separador com o tipo de letra calibri em vez do tipo de letra nativo do Teams.

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

    O gráfico mostra um exemplo de separador com elementos que impedem fluxos de trabalho no separador.

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


Seleção de âmbito
  • 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]

    O gráfico mostra um exemplo de conteúdo num separador configurável com âmbito pessoal, como As Minhas tarefas ou A Minha dashboard.

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

    O gráfico mostra um exemplo de conteúdo na página de destino dos separadores configuráveis contextualmente diferentes para todos os membros.

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

    validation-usability-configurble-nested-tab


Voltar ao início

Bots

Esta secção está em conformidade com o número 1140.4.3 da política do marketplace comercial da Microsoft.

Se a sua aplicação incluir um bot, certifique-se de que cumpre estas diretrizes.

Dica

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


Diretrizes de conceção do bot
  • 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]


Comandos do bot

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

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

    Gráfico a mostrar um exemplo de bot a responder a comandos genéricos.

    Gráfico a mostrar um exemplo de bot sem resposta a comandos genéricos.

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

    validation-bot-commands-dead-end

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

    O gráfico mostra um exemplo de resposta do bot a redirecionar o utilizador para fora do Teams.

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

    Gráfico a mostrar um exemplo de uma resposta válida para um comando de bot incorreto.

    Gráfico a mostrar um exemplo de uma resposta inválida para um comando de bot incorreto.

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

    Gráfico a mostrar um exemplo de um cenário com falhas em que os carateres especiais têm o prefixo dos comandos do bot.

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

    O gráfico mostra um exemplo de bot que fornece um caminho a seguir para um comando inválido.

    Gráfico a mostrar um exemplo de um cenário com falhas em que um bot envia a mesma resposta para um comando válido e inválido.

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

    O gráfico mostra um exemplo de bot que não fornece uma resposta válida para um comando em minúsculas ou em maiúsculas.

    O gráfico mostra um exemplo de um bot sem uma resposta válida quando o utilizador não iniciou sessão na aplicação.

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

    Gráfico a mostrar um exemplo de bot a enviar uma resposta válida para o 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]

    O gráfico mostra um exemplo de uma mensagem de bot sem truncar em dispositivos móveis.

    O gráfico mostra um exemplo de uma mensagem de bot truncada em dispositivos móveis.

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

    O gráfico mostra um exemplo do botão de ação de resposta do bot com um redirecionamento.

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

    O gráfico mostra um exemplo de propriedade apenas de notificação definida como true no manifesto da aplicação.

    O gráfico mostra um exemplo de bot apenas de notificação que não responde para a mensagem de um utilizador.

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

Dica

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


Experiência de utilizador da primeira execução do bot
  • 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.

      O gráfico mostra um exemplo de bot a enviar uma mensagem de boas-vindas quando o bot tem um fluxo de trabalho de configuração complexo.

      O gráfico mostra um exemplo de bot que não envia uma mensagem de boas-vindas quando o bot tem um fluxo de trabalho de configuração complexo.

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

    validation-bot-welcome-message-not-trigger

    validation-bot-wel-message-trigger

  • 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 gráfico mostra um exemplo de um cenário com falhas em que o bot não tem forma de avançar para o utilizador numa mensagem de boas-vindas.

    O gráfico mostra um exemplo de mensagem de boas-vindas do bot com um caminho claro para o utilizador concluir a tarefa.

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

    Gráfico a mostrar um exemplo de bot a enviar uma mensagem de boas-vindas proativa a todos os membros da equipa.

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

    O gráfico mostra um exemplo de limitação da aplicação na mensagem de boas-vindas do bot.

    O gráfico mostra um exemplo de um bot sem limitação de aplicações numa mensagem de boas-vindas.

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

    O gráfico mostra um exemplo de bot que não envia uma mensagem de boas-vindas automaticamente no âmbito pessoal.

  • 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 gráfico mostra um exemplo para o bot acionar uma mensagem de boas-vindas para qualquer comando.

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

    Gráfico a mostrar um exemplo de bot a acionar várias mensagens de boas-vindas na instalação da aplicação.

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

    Gráfico a mostrar um exemplo de nome da aplicação numa mensagem de boas-vindas que não corresponde ao nome da aplicação no manifesto da aplicação.

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

Dica

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


Spaming de mensagens do bot

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]

    validation-bot-message-spam-one-message

    validation-bot-message-spam-multiple-message

  • Mensagens de bot em aplicativos pessoais:

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

      Gráfico a mostrar um exemplo de um bot a enviar várias mensagens numa sucessão rápida.

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

      validation-bot-message-using-task-module

      O gráfico mostra um bot de exemplo a utilizar mensagens multi-turn para concluir uma única conversação.

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


Notificações do bot

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

validation-bot-notification-relevant

validation-bot-notification-not-not-relevant


Bots e Cartões Ajustáveis

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

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

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


Bots apenas de notificação

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

Dica

Pré-visualizar informações e fornecer ações básicas de utilizador na linha na card publicada para que o utilizador não seja obrigado a navegar fora do Teams para todas as ações (independentemente da complexidade).


Informações de metadados do bot
  • As informações do bot no manifesto 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]


Bot no âmbito de colaboração
  • 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]

Voltar ao início

Extensões de mensagens

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

Se a sua aplicação incluir uma extensão de mensagem, certifique-se de que cumpre estas diretrizes.

Dica

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


Diretrizes de conceção de extensões de mensagens
  • 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.

    O gráfico mostra um exemplo de uma aplicação que não cumpre as diretrizes da extensão.

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

    O gráfico mostra um exemplo de carregamento de imagens de pré-visualização em card adaptáveis.

    O gráfico mostra um exemplo de imagem de pré-visualização que não está a ser carregada em card adaptáveis.

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


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

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.

    validation-messaging-extension-no-intermediate-steps

    validation-messaging-extension-intermediate-steps-available

  • Transferir o contexto da mensagem ao próximo estado de trabalho. [Tem de corrigir]

    validation-messaging-extension-app-passes-messages

    validation-messaging-extension-app-doesnot-pass-messages

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

    Gráfico a mostrar um exemplo do nome da aplicação anfitriã para um comando de ação.

    Gráfico a mostrar um exemplo de verbo genérico para um comando de açã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]

    O gráfico mostra um exemplo de indicador de carregamento contínuo quando um bot invoca um comando de ação.

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


Ligações de pré-visualização (desfraldamento de ligações)

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


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

    O gráfico mostra um exemplo de uma extensão de mensagem com texto de ajuda para os utilizadores procurarem eficazmente.

    O gráfico mostra um exemplo de uma extensão de mensagem sem texto de ajuda para os utilizadores procurarem eficazmente.

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

    validation-search-commands-unclear-executable

Voltar ao início

Diálogos

[Tem de corrigir]

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

Expandir para saber mais

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.

validation-task-module-displays-component

validation-task-module-embed-app

Dica

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

Voltar ao início

Extensões de reunião

Esta secção está em conformidade com o número 1140.4.6 da política do marketplace comercial da Microsoft.

Dica

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


Cumprir as diretrizes de conceção da extensão
  • 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.

    O gráfico mostra um exemplo de uma experiência em reunião a redirecionar o utilizador para fora do Teams para concluir a funcionalidade principal da 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]

    O gráfico mostra um exemplo de ecrã de carregamento contínuo numa aplicação.

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

    Gráfico a mostrar um exemplo de uma aplicação a redirecionar para a plataforma baseada em chat concorrente.

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

    O gráfico mostra um exemplo de uma aplicação sem um caminho a seguir para os participantes numa vista baseada em funções.


Experiência pré e pós-reunião
  • As telas de pré e pós-reunião devem seguir as diretrizes gerais de design de guia. Para obter mais informações, confira diretrizes de design do Teams. [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]

    O gráfico mostra um exemplo de tabulação que não segue as diretrizes de estrutura do separador.


Experiência na reunião
  • Os aplicativos só devem usar um tema escuro durante as reuniões. Para obter mais informações, confira diretrizes de design do Teams. [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]

    validation-in-meeting-exp-display-app-names

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


Separadores em reunião
  • 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]

    O gráfico mostra um exemplo do botão anterior presente.

    O gráfico mostra um exemplo de botão anterior que não está presente.

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

    Gráfico a mostrar um exemplo de separador na reunião com deslocamento vertical.

    Gráfico a mostrar um exemplo de separador na reunião com deslocamento horizontal.


Caixas de diálogo na reunião
  • Deve ser usado com moderação e para cenários que são leves e orientados a tarefas. [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]

    Gráfico a mostrar um exemplo de esquema de coluna única para a caixa de diálogo na reunião.

    O gráfico mostra um exemplo de vários esquemas de coluna para a caixa de diálogo na reunião.

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

    O gráfico mostra um exemplo de caixa de diálogo em reunião que não está alinhada com o centro da fase da reunião.

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

Fase da Reunião Partilhada

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]

Voltar ao início

Conector

  1. O nome do conector tem de ser o mesmo que o nome da aplicação na aplicação e no manifesto da aplicação.

    Captura de ecrã a mostrar o erro de correspondência no nome da aplicação entre a aplicação e o manifesto da aplicação.

  2. O utilizador não pode encontrar nenhum erro ao configurar o conector.

    Captura de ecrã a mostrar um erro ao configurar o conector pelo utilizador.

Notificações

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

Se a sua aplicação utilizar as APIs de feed de atividades fornecidas pelo Microsoft Graph, certifique-se de que cumpre as seguintes diretrizes.

Dica

Se as suas aplicações suportarem cenários de notificação em que as notificações são acionadas após longos intervalos, por exemplo, após um dia ou um mês. Antes de submeter para revisão, certifique-se de que aciona essas notificações em segundo plano para que possamos testar as notificações.



Diretrizes de conceção de notificações
  • 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]


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

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

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

Navegação e esquema
  • 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]

Voltar ao início

Programa de Conformidade do Aplicativo do Microsoft 365

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

Expandir para saber mais

O Programa de Conformidade dos Aplicativos do Microsoft 365 tem como objetivo ajudar as organizações a avaliarem e gerenciarem riscos através da avaliação de informações de segurança e conformidade do seu aplicativo. Se 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]

    Gráfico a mostrar um exemplo de um distintivo azul verificado na caixa de diálogo de consentimento do Microsoft Entra.

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

Voltar ao início

Publicidade

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

As aplicações não devem apresentar publicidade, incluindo anúncios dinâmicos, anúncios de faixas e anúncios na mensagem. [Tem de corrigir]

O gráfico mostra um exemplo de um cenário de falha de publicidade no Teams.

Voltar ao início

Aplicações baseadas em criptomoedas

Tem de demonstrar a conformidade com todas as leis em que a sua aplicação é distribuída, se a sua aplicação: [Tem de corrigir]

  • Facilita transações ou transmissões de criptomoedas na aplicação.

  • Promove conteúdos relacionados com criptomoedas.

  • Permite que os utilizadores armazenem ou acedam à criptomoeda armazenada.

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

  • Encoraja ou facilita a extração de tokens de criptomoeda.

  • Facilita a participação do utilizador nas Ofertas Iniciais de Moedas.

  • Recompensa ou incentiva os utilizadores com tokens de criptomoeda para concluir uma tarefa.

Após uma revisão interna da Microsoft, se a demonstração de conformidade for satisfatória, a Microsoft poderá proceder a uma certificação adicional da sua aplicação. Se a demonstração de conformidade não for satisfatória, a Microsoft mantém-no informado sobre a decisão de não prosseguir com a certificação da sua aplicação.

Voltar ao início

Funcionalidade da aplicação

  • Os fluxos de trabalho ou o conteúdo na aplicação têm de estar relacionados com o âmbito. [Tem de corrigir]
  • Todas as capacidades da aplicação têm de estar funcionais e têm de funcionar corretamente, conforme descrito na descrição longa do manifesto do AppSource ou da aplicação. [Tem de corrigir]
  • As aplicações têm de notificar sempre o utilizador antes de transferir qualquer ficheiro ou executável no ambiente do utilizador. Qualquer chamada à ação (CTA), baseada em texto ou não, que torna claro ao utilizador que um ficheiro ou executável é transferido na ação do utilizador é permitido na aplicação. [Tem de corrigir]
  • As aplicações com dependência de região têm de notificar os utilizadores com uma mensagem de falha correta em todas as capacidades aplicáveis se tentarem utilizá-la numa região não suportada. [Tem de corrigir]

Voltar ao início

Experiência móvel

  • Os suplementos móveis têm de ser gratuitos. Não devem existir conteúdos ou ligações na aplicação que promovam a venda em alta, lojas online ou outros pedidos de pagamento. As contas necessárias para aplicações não têm de ter qualquer custo de utilização e, se forem limitadas pelo tempo, não devem incluir conteúdos que indiquem a necessidade de pagamento. [Tem de corrigir]

    Gráfico a mostrar um exemplo de um suplemento móvel a pedir pagamento.

  • A utilização da palavra GRATUITA, AVALIAÇÃO GRATUITA ou EXPERIMENTAR GRATUITAMENTE é permitida na experiência de ambiente de trabalho ou aplicação Web sem qualquer limitação ou consideração.

  • A utilização da palavra FREE como texto simples no contexto de uma versão de avaliação ou atualização da aplicação é permitida em dispositivos móveis.

  • A utilização da palavra FREE no contexto de uma atualização de avaliação ou aplicação com uma ligação que conduz a uma página de destino sem informações de pagamento ou preços é permitida em dispositivos móveis. É permitido texto simples para sinalizar que a aplicação é PAGA em dispositivos móveis.

  • A utilização da palavra FREE como texto simples no contexto de uma versão de avaliação ou atualização da aplicação e associada a detalhes de preços não é permitida em dispositivos móveis. [Tem de corrigir]

  • A utilização da palavra FREE no contexto de uma atualização de avaliação ou aplicação e associada a uma ligação que conduz a uma página de destino com informações de preços ou detalhes de pagamento em dispositivos móveis não é permitida. [Tem de corrigir]

  • Os detalhes de preços em dispositivos móveis em qualquer formato, por exemplo, imagem, texto ou ligação não são permitidos. O CTA, como ver planos em dispositivos móveis, não é permitido. Informações sobre planos sem detalhes de preços, mas com uma ligação de contacto ou e-mail em dispositivos móveis não são permitidas. Qualquer texto com detalhes de contacto que ligue ou aloja a uma atualização paga não é permitido em dispositivos móveis. Pagamentos para bens físicos são permitidos em dispositivos móveis. Por exemplo, a sua aplicação pode permitir o pagamento para reservar um táxi. [Tem de corrigir]

    O gráfico mostra um exemplo de detalhes de preços em dispositivos móveis.

  • Pagamentos para bens digitais na aplicação não são permitidas em dispositivos móveis. [Tem de corrigir]

    Gráfico a mostrar um exemplo de pagamentos de bens digitais em dispositivos móveis.

  • As aplicações do Teams têm de oferecer uma experiência móvel entre dispositivos adequada. [Tem de corrigir]

  • As capacidades que não são suportadas em dispositivos móveis não têm de ser inativas para um utilizador e têm de fornecer uma mensagem de falha correta sempre que aplicável. [Tem de corrigir]

Voltar ao início

Aplicações expandidas em todos os clientes do Microsoft 365

Geral

  • As aplicações que se destinam a expandir as aplicações do Teams em todos os clientes do Microsoft 365 têm de utilizar a versão de esquema 1.13 ou posterior.

  • O URL de suporte da sua aplicação tem de conter conteúdo relevante para a aplicação Teams extensível em todos os clientes do Microsoft 365 e não deve chamar apenas um único cliente.

  • Tem de fornecer referência relevante à aplicação Teams extensível em todos os clientes do Microsoft 365 na descrição da aplicação.

  • Se a sua aplicação do Teams for extensível em todos os clientes do Microsoft 365, os conteúdos fornecidos na introdução da sua aplicação, iniciar sessão, inscrever-se, terminar sessão, páginas de ajuda ou mensagens de reencaminhamento têm de chamar todos os clientes.

Compatibilidade

As aplicações do Teams extensíveis em todos os clientes do Microsoft 365 têm de ser totalmente reativas e funcionais nas versões mais recentes dos clientes do Microsoft Edge e do Google Chrome. O utilizador tem de ser capaz de invocar e continuar a utilizar separadores pessoais ou extensões de mensagens no seguinte:

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

Experiência móvel

Os utilizadores têm de conseguir iniciar a aplicação a partir do menu de lista de opções de ações no cliente do Microsoft 365 em dispositivos móveis. O nome da aplicação tem de ser apresentado corretamente na barra de ação. [Tem de corrigir]

Lançamento de aplicações a partir da lista de opções de ações

Os utilizadores têm de conseguir iniciar e alternar entre vários separadores estáticos no cliente do Microsoft 365 em dispositivos móveis. Os separadores têm de ser carregados corretamente. Se existirem mais de três separadores estáticos, os restantes separadores têm de estar visíveis na secção Mais . [Tem de corrigir]

Experiência de vários separadores

Se a sua aplicação utilizar o SSO, tem de autenticar o utilizador com êxito. O SSO permite que os utilizadores iniciem sessão com um conjunto de credenciais para vários sistemas de software independentes. Os utilizadores podem aceder a todas as aplicações necessárias sem utilizar credenciais diferentes para autenticar. [Tem de corrigir]

Autenticação de aplicativo

A aplicação tem de terminar a instância da conta de utilizador quando o utilizador tiver mudado ou terminado sessão no cliente do Microsoft 365 no dispositivo móvel. [Tem de corrigir]

Experiência de comutação e fim de sessão da conta

  • Os utilizadores têm de poder voltar ao estado de trabalho anterior. Se o utilizador estiver na página raiz, a navegação anterior tem de terminar a instância da aplicação no cliente do Microsoft 365 em dispositivos móveis. [Tem de corrigir]

  • As aplicações que suportam uma ligação avançada a um fluxo de trabalho têm de conseguir redirecionar o utilizador para a experiência de página de destino adequada. [Tem de corrigir]

Navegação entre separadores

  • O indicador de progresso tem de aparecer quando a aplicação está a ser carregada e dispensada automaticamente depois de a aplicação ser carregada. [Tem de corrigir]

  • Tem de ser apresentado um ecrã de erro quando uma aplicação não carrega nas instâncias, como rede incoerente ou quebrada, tempo limite excedido ou falha de autenticação, etc. [Tem de corrigir]

Voltar ao início

Aplicações do Teams extensíveis como plug-in para Microsoft 365 Copilot

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

As breves descrições de uma aplicação, parâmetro e comando não podem incluir o seguinte:

  1. Expressões instrutivas. Por exemplo, se o utilizador indicar X, ignore, elimine, reponha, novas instruções, responda a negrito ou não imprima nada.
  2. Linguagem verbosa, florida ou de marketing.
  3. Afirmações superlativas como n.º 1, incrível ou melhor.
  4. URLs, emojis ou carateres ocultos, como símbolos hexadecimais, binários ou não convencionais.
  5. Erros de gramática e pontuação.

Deteção do Utilizador

A descrição longa de uma aplicação tem de chamar claramente o seguinte:

  • Compatibilidade da aplicação com Microsoft 365 Copilot. Por exemplo, utilize a Contoso no Microsoft 365 Copilot para procurar e resumir as suas tarefas.

  • Indique, pelo menos, um aviso sobre como os utilizadores podem utilizar um plug-in de extensão de mensagens Microsoft 365 Copilot. Por exemplo, quais são os bilhetes de alta prioridade atribuídos esta semana na Contoso.

    Captura de ecrã a mostrar um cenário de passagem com um exemplo de pedido de exemplo para a utilização da extensão de mensagens como um plug-in no Microsoft 365 Copilot.

    Captura de ecrã a mostrar um cenário de falha sem um exemplo de pedido de exemplo para a utilização da extensão de mensagens como um plug-in no Microsoft 365 Copilot.

Qualidade da Resposta

  • Os campos obrigatórios na resposta Microsoft 365 Copilot Cartão Ajustável têm de incluir o Título da informação e, pelo menos, dois campos úteis adicionais à sua escolha, por exemplo, data de modificação, autor, status e sinalizadores. Tanto a pré-visualização como o conteúdo têm de fazer parte de uma única resposta.

    Captura de ecrã a mostrar um exemplo de uma aplicação de exemplo a mostrar a resposta de Microsoft 365 Copilot que contém Pré-visualização e Conteúdo na mesma resposta.

  • Os Cartões Ajustáveis na resposta Microsoft 365 Copilot têm de ter, pelo menos, um botão de ação.

  • Os botões de ação presentes no Microsoft 365 Copilot resposta Os Cartões Ajustáveis têm de estar funcionais.

    Captura de ecrã a mostrar um exemplo de título de informações, campos de utilizador adicionais e botão de ação numa resposta de Cartão Ajustável.

  • Microsoft 365 Copilot tem de responder com precisão e não apresentar um erro quando um utilizador pedir com um único parâmetro.

  • Microsoft 365 Copilot tem de responder com precisão e não mostrar um erro quando um utilizador pedir com um parâmetro múltiplo.

  • Microsoft 365 Copilot tem de responder com precisão e não mostrar um erro quando um utilizador pedir um seguimento.

  • A extensão de mensagem tem de conter, pelo menos, dois parâmetros para uma experiência de utilizador melhorada no Microsoft 365 Copilot.

Voltar ao início

Próxima etapa

Confira também