Upload de app personalizado no Teams: repositório de checagem antes de liberar

Você recebeu um pacote .zip de um desenvolvedor. Pode ser um app feito sob medida para o seu negócio, uma prova de conceito que alguém da equipe montou com o Teams Toolkit, ou uma integração que veio de um parceiro. Antes de subir isso no catálogo da sua organização, tem uma sequência de verificações que vale a pena percorrer. Não para burocracia, mas para evitar surpresa depois que o app estiver disponível para centenas ou milhares de pessoas.

A documentação oficial da Microsoft deixa claro que apps personalizados (custom apps) não passam pela validação de mais de 400 testes que a loja do Teams aplica em apps públicos (fonte ((abre em nova aba))). Isso significa que o filtro é seu. Montei este roteiro com base no que o Microsoft Learn documenta sobre políticas, permissões e boas práticas de publicação.

1. Confirme que o manifesto do app está na versão certaLink para esta seção

O manifesto é o coração do pacote. É um arquivo JSON que diz ao Teams quem é o app, o que ele faz e de que permissões precisa. A Microsoft exige que o manifesto siga um esquema (schema) publicado, não uma versão de preview (fonte ((abre em nova aba))). Se o desenvolvedor usou uma versão de manifesto anterior a 1.10, peça que atualize. Versões antigas podem não suportar recursos como SSO (login único) e criam inconsistência com o Bot Framework quando o app inclui bot ou extensão de mensagem.

No seu tenant, confirme que o manifesto declara corretamente o Microsoft Entra Application (client) ID se o app usa autenticação. Esse dado é obrigatório e vai no campo webApplicationInfo do manifesto (fonte ((abre em nova aba))).

2. Teste o upload em um ambiente controlado primeiroLink para esta seção

Antes de disponibilizar o app para a organização inteira, faça o upload para testar. A Microsoft recomenda que você tenha um tenant de desenvolvimento separado para isso (fonte ((abre em nova aba))). Se não tiver um, crie uma política de setup policy específica para um grupo pequeno de testes, com a opção "Upload custom apps" ligada, e atribua essa política apenas a quem vai validar (fonte ((abre em nova aba))).

Lembre-se de que a ativação do upload de apps personalizados pode levar até 24 horas depois que você altera a configuração (fonte ((abre em nova aba))). Planeje esse tempo.

3. Entenda quem pode subir o app e por qual caminhoLink para esta seção

Existem quatro formas de um app personalizado chegar ao catálogo da sua organização (fonte ((abre em nova aba))):

• Upload por administrador via Teams admin center: o app fica disponível para toda a organização sem aprovação adicional. É o caminho mais comum quando o app vem de um parceiro ou fornecedor.
• Upload por usuário diretamente no cliente do Teams: o desenvolvedor testa o app no contexto pessoal ou com poucas pessoas em uma equipe. Não requer aprovação do admin, mas você controla quem pode fazer isso via app setup policy.
• Submissão por usuário para aprovação do admin: qualquer pessoa pode submeter um app para revisão. O admin aprova ou recusa. A opção de submeter não pode ser desligada (fonte ((abre em nova aba))).
• Submissão por API (Graph API): mesma lógica da submissão pelo cliente, mas via código.

Para cada cenário, o controle que você tem como admin é diferente. Se a preocupação é governança, o caminho mais seguro é receber o pacote, revisar e fazer o upload você mesmo pelo admin center.

4. Verifique as três camadas de política que controlam o appLink para esta seção

A Microsoft documenta três níveis de configuração que atuam juntos para determinar quem pode usar um app personalizado (fonte ((abre em nova aba))):

1. Org-wide app settings: a chave "Let users interact with custom apps in preview" precisa estar ligada para que qualquer app personalizado funcione no seu tenant. Se estiver desligada, nenhuma outra configuração adianta.
2. App setup policy: controla quais usuários têm permissão de fazer upload de apps personalizados. O padrão é "Off". Você pode criar políticas personalizadas para grupos específicos.
3. Configuração por equipe: o proprietário de cada time pode permitir ou bloquear que membros façam upload de apps personalizados naquela equipe específica.

A tabela de efeito combinado na documentação (fonte ((abre em nova aba))) mostra, por exemplo, que com a configuração organizacional ligada e a política de equipe desligada, apenas proprietários do time conseguem fazer upload. Com tudo ligado, qualquer membro consegue.

5. Restrinja o acesso ao app depois de publicadoLink para esta seção

Depois que o app sobe para o catálogo, você pode usar app permission policy para controlar quais usuários ou grupos têm acesso a ele (fonte ((abre em nova aba))). Isso é útil quando o app atende a um departamento específico e não deve aparecer para todo mundo.

Se precisar remover o app, a documentação mostra que o admin pode excluí-lo da página de detalhes do app no admin center, selecionando "More commands" > "Actions" > "Delete" (fonte ((abre em nova aba))). A exclusão tira o app do catálogo e impede que usuários existentes continuem usando.

6. Atualizações seguem a mesma política da versão anteriorLink para esta seção

Quando o desenvolvedor entrega uma nova versão do pacote, você faz o upload pelo admin center na página de detalhes do app. A Microsoft documenta que as políticas existentes que se aplicavam à versão anterior continuam valendo para a nova (fonte ((abre em nova aba))). Isso significa que, se você restringiu o acesso ao app por permission policy, a restrição se mantém depois da atualização.

7. O que a Microsoft não valida em apps personalizadosLink para esta seção

Essa é a parte mais importante. A Microsoft executa mais de 400 testes em apps que entram na loja do Teams, incluindo verificação de permissões do Graph, presença de links funcionais, ausência de anúncios e conteúdo ofensivo, e verificação da identidade do desenvolvedor no Partner Center (fonte ((abre em nova aba))). Nada disso acontece com apps personalizados. A nota na documentação é explícita: "validação e verificações pela Microsoft estão disponíveis apenas para apps na loja e não estão disponíveis para apps personalizados" (fonte ((abre em nova aba))).

Portanto, cabe a você e a sua equipe fazer essas verificações. Olhe as permissões que o manifesto declara. Confira se o app não tenta baixar executáveis (algo que a Microsoft bloqueia na loja, mas que um app personalizado poderia tentar). Teste o fluxo completo antes de liberar.

Resumo do roteiroLink para esta seção

1. Valide o manifesto contra o schema publicado e confira o Microsoft Entra ID.
2. Teste o upload em um grupo controlado antes de liberar para todo mundo.
3. Escolha o método de publicação que dá mais controle para o seu cenário.
4. Ajuste as três camadas de política (org-wide, setup policy, equipe) para o efeito desejado.
5. Use app permission policy para restringir o acesso ao app depois de publicado.
6. Atualizações herdam as políticas da versão anterior, mas merecem nova rodada de testes.
7. Lembre-se de que a validação da Microsoft não cobre apps personalizados. O filtro é seu.