SharePoint Forms em bibliotecas: fim do metadado ausente

O problema que toda biblioteca do SharePoint enfrenta

Qualquer administrador de SharePoint conhece a cena: alguém arrasta um arquivo para a biblioteca, ignora as colunas de metadados e segue em frente. O documento fica sem categoria, sem responsável, sem data de vencimento, sem nada que permita encontrá-lo depois por uma visualização filtrada ou por busca. Multiplique isso por centenas de uploads ao longo de meses e o resultado é uma biblioteca tecnicamente organizada, mas praticamente inutilizável.

A partir de novembro de 2025, a Microsoft começou a distribuir um recurso que ataca esse problema na raiz: o botão Forms, agora disponível diretamente nas bibliotecas de documentos, não apenas nas listas. A diferença central em relação a qualquer outro método de upload é que ele torna o preenchimento de metadados uma condição para o envio do arquivo, não uma sugestão que o usuário pode ignorar.

O que o botão Forms faz de diferente

O recurso já existia para listas do SharePoint há alguns meses. A novidade é a extensão para bibliotecas, com uma capacidade que listas não têm: o formulário aceita o upload de um arquivo como parte do envio. Isso significa que o usuário não escolhe entre preencher metadados ou não. Ele só consegue subir o documento depois de completar os campos marcados como obrigatórios, identificados por um asterisco vermelho no formulário.

Na prática, isso elimina a necessidade de rotinas de cobrança de metadados via Power Automate, de visualizações que destacam itens incompletos ou de e-mails manuais pedindo para o usuário voltar e corrigir o item. O controle passa a acontecer no momento do upload, não depois dele.

Como criar seu primeiro formulário

A partir do nível da biblioteca

Quando você cria um formulário direto na raiz da biblioteca, o SharePoint exige que ele esteja associado a uma pasta. Todo formulário de biblioteca vive dentro de uma pasta, não existe formulário solto na raiz sem pasta vinculada. O fluxo é:

1. Clique no botão Forms no topo da biblioteca.
2. Selecione Create new form.
3. Defina a pasta de destino, escolhendo cor e nome (algo como “Notas Fiscais para Aprovação” ou “Políticas de RH”).
4. Personalize os campos exibidos, ocultando os que não fazem sentido para esse fluxo específico.
5. Opcionalmente, adicione um logotipo para dar identidade visual ao formulário.
6. Marque quais campos são obrigatórios.

A partir de uma pasta já existente

Se a estrutura de pastas já está montada, não é preciso recriar nada. Navegue até a pasta, clique nos três pontos (ou botão direito), selecione Forms e depois Create new form. É possível ter múltiplos formulários apontando para a mesma pasta, cada um com sua própria configuração de campos e restrições. Isso é útil quando departamentos diferentes compartilham a mesma pasta de destino, mas precisam capturar metadados distintos.

A pegadinha do upload único

Cada envio de formulário aceita apenas um arquivo. Se o usuário precisa subir cinco documentos, precisa preencher o formulário cinco vezes. Isso não é uma limitação acidental, é uma decisão de design: garante que cada arquivo receba seus próprios metadados, em vez de aplicar o mesmo conjunto de valores a um lote inteiro de arquivos diferentes. Se sua operação depende de upload em lote com metadados únicos por arquivo, essa restrição precisa entrar no desenho do processo desde o início, não ser descoberta depois que o usuário reclamar.

Restrição de tipo e tamanho de arquivo

Este é um recurso que a biblioteca padrão do SharePoint simplesmente não oferece fora do formulário. Dentro da configuração do formulário, você pode:

• Restringir o upload a extensões específicas (por exemplo, apenas .docx e .pdf).
• Definir um tamanho máximo de arquivo.
• Aplicar essas regras no nível do formulário, não da biblioteca inteira.

Quando o usuário tenta enviar um tipo de arquivo não permitido, recebe uma mensagem clara, do tipo “Formato de arquivo não suportado. Envie apenas arquivos Word e PDF.” Isso resolve um problema recorrente em bibliotecas usadas por múltiplos públicos: imagens em pastas de contratos, planilhas em pastas de políticas, PDFs escaneados de baixa qualidade em pastas que exigem documentos editáveis.

Lógica condicional no formulário

Assim como nos formulários de lista, é possível configurar branching logic (lógica condicional): a resposta de um campo de escolha determina quais perguntas adicionais aparecem em seguida. Um formulário de submissão de notas fiscais, por exemplo, pode exibir um campo de “número de contrato” apenas quando o usuário marca a opção “despesa vinculada a contrato”, e ocultar esse campo em qualquer outro cenário. Isso reduz a fricção para quem preenche e evita formulários genéricos com quinze campos, a maioria irrelevante para o caso de uso da pessoa.

Formulários em subpastas e a hierarquia de visualização

A relação entre formulários e a estrutura de pastas segue uma lógica hierárquica que vale entender antes de montar uma biblioteca inteira em cima disso:

• Ao clicar em Forms no nível raiz da biblioteca, você vê todos os formulários de todas as pastas.
• Ao navegar para dentro de uma pasta específica e clicar em Forms, você vê apenas os formulários associados àquela pasta e suas subpastas.
• É possível ter múltiplos formulários apontando para a mesma pasta, cada um com configuração de campos e restrições de arquivo diferentes.

O recurso que realmente muda o jogo: controle de permissão sem acesso à biblioteca

Aqui está o ponto que separa este recurso de um simples upgrade de UX: o link do formulário pode ser compartilhado com usuários internos que não têm nenhum acesso à biblioteca de documentos.

Pense no que isso resolve. O usuário recebe um link limpo, preenche o formulário, envia o arquivo com os metadados corretos, e o documento cai exatamente na pasta de destino configurada pelo administrador. Em nenhum momento esse usuário vê a estrutura da biblioteca, não navega por outras pastas, não tem a opção de arrastar arquivos para qualquer lugar. Ele nunca sabe que existe uma biblioteca por trás do formulário.

Para organizações que precisam de controle rígido sobre onde documentos são armazenados, mas ainda querem facilitar o envio para quem não deveria ter acesso amplo ao repositório, isso elimina uma dor recorrente: dar acesso de contribuidor a uma biblioteca inteira só para que alguém consiga subir um único tipo de arquivo em uma única pasta.

Como organizar a distribuição dos links

Cada formulário gera um link único. Uma forma eficiente de organizar isso, especialmente quando há vários formulários apontando para pastas diferentes, é:

1. Criar uma página no SharePoint dedicada, por exemplo “Envio de Documentos”.
2. Adicionar a web part Quick Links.
3. Para cada formulário, adicionar o link usando a opção “A partir de um link”.
4. Dar a cada link um nome descritivo, como “Enviar Arquivos de Marketing” ou “Submeter Documentos de RH”.
5. Publicar a página e incluí-la na navegação do site.

O usuário clica no link, preenche o formulário, sobe o arquivo e conclui. Não precisa entender a estrutura de pastas nem navegar pela biblioteca em nenhum momento do processo.

Forms no Microsoft Teams

Como cada canal de equipe no Teams cria uma pasta correspondente na biblioteca de documentos do SharePoint por trás do site, é possível criar formulários para essas pastas de canal. O botão Forms fica disponível diretamente na interface do Teams, e qualquer arquivo enviado através do formulário cai na pasta daquele canal específico. Isso cria um fluxo direto para equipes que recebem documentos de colaboradores ou de outras áreas e precisam garantir que cada arquivo chegue com metadados completos, sem depender de disciplina manual de quem está enviando.

O que ainda não funciona

Document Sets não são compatíveis

Formulários não funcionam com Document Sets. Faz sentido: Document Sets aplicam metadados automaticamente a um conjunto de arquivos, enquanto formulários pedem que o usuário preencha metadados individualmente para cada arquivo enviado. As duas lógicas são incompatíveis por design.

Não renomeie nem mova a pasta depois de criar o formulário

Este é o ponto que mais gera dor de cabeça em produção: o formulário é vinculado diretamente ao nome da pasta. Renomear a pasta depois de criar o formulário quebra o link, que passa a retornar erro 404. Mover a pasta para outra biblioteca também não move o formulário junto, o link antigo continua existindo, mas aponta para um local que não existe mais.

Um detalhe curioso de comportamento: se você recriar uma pasta com exatamente o mesmo nome da pasta original, o formulário volta a funcionar. Isso sugere que o vínculo é resolvido por nome no momento do acesso, não por um identificador interno fixo da pasta. É uma informação útil para cenários de recuperação, mas não é algo em que se deva confiar como prática de governança. A regra prática é simples: defina o nome da pasta antes de criar o formulário e trate esse nome como definitivo.

Campos obrigatórios são globais na biblioteca

É possível ocultar campos diferentes em formulários diferentes da mesma biblioteca. O que não é possível é ter um campo obrigatório em um formulário e opcional em outro dentro da mesma biblioteca. Se você marca um campo como obrigatório em qualquer formulário, ele se torna obrigatório em toda a biblioteca, para qualquer outro formulário que exista ali. Isso limita o desenho de bibliotecas que atendem múltiplos processos com exigências de metadados muito distintas entre si. Nesses casos, pode fazer mais sentido arquitetural separar os processos em bibliotecas diferentes em vez de forçar tudo dentro da mesma estrutura.

Apenas usuários internos, sem suporte a externos

Os formulários de biblioteca só funcionam para usuários dentro do seu locatário do Microsoft 365. Um usuário externo não consegue acessar o formulário, mesmo recebendo o link direto. Isso é diferente do Microsoft Forms tradicional, que oferece mais flexibilidade para acesso externo. Vale notar, porém, que mesmo no Microsoft Forms, quando o formulário aceita upload de arquivo, o usuário externo geralmente precisa estar autenticado de alguma forma, então a diferença prática entre as duas ferramentas nesse ponto específico é menor do que parece à primeira vista.

A vantagem que o Microsoft Forms mantém é a capacidade de aceitar múltiplos anexos em um único envio, algo que o Forms de biblioteca não faz. Em compensação, o Forms de biblioteca entrega integração nativa com metadados da biblioteca e posicionamento direto do arquivo na estrutura correta, sem precisar de um fluxo no Power Automate para mover o arquivo de um lugar genérico para a pasta certa depois do envio.

Onde esse recurso resolve problemas reais

Alguns cenários em que a combinação de metadados obrigatórios, restrição de tipo de arquivo e link sem acesso à biblioteca faz diferença concreta na operação:

• Recebimento de notas fiscais: um formulário que aceita apenas PDF, com limite de tamanho de arquivo, exige nome do fornecedor e data de vencimento, e envia tudo para uma pasta que a equipe financeira processa em lote.
• Coleta de documentos de RH: formulários distintos para cada tipo de documento, cada um com seus próprios campos obrigatórios, sem que o colaborador tenha acesso de navegação à estrutura de arquivos de RH.
• Submissão de material de marketing: um formulário para apresentações, outro para documentos de texto, outro para imagens, cada um restringindo o tipo de arquivo aceito e direcionando para a pasta correspondente com o metadado já preenchido.
• Uploads segmentados por área, em uma biblioteca compartilhada: quando várias áreas usam a mesma biblioteca, formulários separados por área guiam cada grupo para sua pasta designada, com os metadados específicos daquela área já configurados.

Um ajuste que aumenta bastante o ganho prático é combinar esse recurso com a funcionalidade de valores padrão de coluna do SharePoint. Se a biblioteca tem uma pasta por área e também uma coluna “Área” nos metadados, você pode configurar o valor padrão dessa coluna por pasta, de forma que o campo já venha preenchido automaticamente quando o arquivo cai naquela pasta específica, sem precisar perguntar isso no formulário. Isso reduz o número de campos que o usuário precisa preencher manualmente e diminui a chance de erro de digitação em um campo que, na verdade, já é previsível pela própria estrutura da biblioteca.

Vale a pena adotar agora

As limitações existem e precisam entrar no planejamento: um arquivo por envio, sem suporte a usuários externos, cuidado redobrado com renomeação e movimentação de pastas, e a regra de que campo obrigatório vale para a biblioteca inteira, não por formulário isolado. Nenhuma dessas restrições invalida o recurso, mas todas precisam ser conhecidas antes de desenhar um processo de produção em cima dele, não descobertas depois que o processo já está em uso por dezenas de pessoas.

Dito isso, o ganho é real e resolve um problema que praticamente toda organização com bibliotecas do SharePoint enfrenta: metadado incompleto, arquivo no lugar errado, e a necessidade de dar acesso amplo a alguém só para que consiga subir um documento específico. Se sua operação depende de coleta de documentos de terceiros, de outras áreas ou de processos com regras de metadado bem definidas, vale montar uma biblioteca de teste, criar dois ou três formulários e observar como o fluxo se comporta antes de expandir para produção.

Quando o desenho envolve várias bibliotecas, colunas de site compartilhadas entre sites diferentes ou integração com fluxos existentes no Power Automate, o planejamento da arquitetura de metadados costuma ser o que decide se o recurso vira uma solução duradoura ou apenas mais uma camada de complexidade. É nesse ponto de arquitetura que a Trinapse costuma entrar nas conversas com clientes sobre governança de documentos no SharePoint.