SharePoint Copilot Apps: da intenção à ação no M365

O problema que o chat nunca resolveu

Copilot sempre foi bom para responder. O ponto fraco aparecia depois: quando a resposta certa exigia uma ação real. Aprovar uma despesa, validar um cadastro, avançar um chamado de incidente, rodar um checklist de onboarding. Essas tarefas não terminam com um texto bem gerado. Elas terminam com uma decisão tomada dentro de um sistema que tem regra, permissão e trilha de auditoria.

Até agora, a saída padrão era o usuário sair do Copilot, abrir o SharePoint, o Teams ou um sistema de linha de negócio, fazer a ação lá, e voltar. Cada troca de contexto é atrito, e atrito é onde a adoção de IA generativa costuma travar dentro de uma operação madura.

A Microsoft anunciou o preview público do SharePoint Copilot Apps, distribuído como parte do SPFx 1.24 preview. A proposta é direta: Copilot cuida do raciocínio sobre a intenção do usuário, e um app real, rodando dentro do próprio canvas do Copilot, cuida da execução. Não é mais um plugin que devolve texto formatado. É uma aplicação interativa completa, com grid de dados, formulário multi-etapa, painel de aprovação, dashboard com KPI, tudo renderizado dentro da conversa.

A divisão de trabalho entre Copilot e o app

O modelo mental que vale a pena guardar é este: Copilot resolve a linguagem natural e o contexto, o SharePoint Copilot App resolve a interface, a permissão, a validação e a operação confiável. Um cuida de entender o que o usuário quer, o outro cuida de garantir que a coisa certa aconteça, com os dados certos, para a pessoa certa.

Isso muda o papel do desenvolvedor de SharePoint dentro dessa história. Você não precisa ensinar o Copilot a validar uma regra de negócio complexa via prompt. Você constrói o componente de UX que já sabe fazer essa validação, com a lógica de permissão que já existe no seu tenant, e o Copilot decide quando trazer esse componente para a superfície certa, no momento certo da conversa.

Na prática, cada solução pode expor múltiplas experiências inline, mais leves, e múltiplas experiências em tela cheia, mais robustas, e o Copilot escolhe qual mostrar de acordo com a intenção detectada. Um pedido rápido de aprovação pode aparecer como card inline. Uma triagem de incidente com múltiplos campos e histórico pode abrir em tela cheia dentro do próprio canvas.

Por que isso importa para quem já tem SPFx investido

Esse é o ponto que separa este anúncio de mais uma novidade cosmética do Copilot: SharePoint Copilot Apps são construídos sobre o SharePoint Framework, o mesmo modelo de empacotamento que sua organização provavelmente já usa para web parts e extensions. JavaScript, TypeScript, React, Angular, Vue ou Svelte, a escolha do stack é sua. O que muda é onde esse componente aparece.

O ecossistema SPFx já atende dezenas de milhões de usuários finais todos os dias em produção. Isso não é uma base experimental. O preview do Copilot Apps estende essa base instalada diretamente para o canvas do Copilot, sem exigir uma reescrita da lógica de interação que você já validou em produção.

Na prática, se sua organização tem um painel de aprovação de despesas em SPFx, um formulário de onboarding, um dashboard operacional, esse componente pode ser adaptado para rodar dentro do Copilot sem reconstruir a interface do zero. É reaproveitamento de investimento, não substituição.

Write once, reach everywhere

Um mesmo componente de UX pode ser exposto em três superfícies diferentes: Copilot, SharePoint e Microsoft Teams, sem duplicar código. Você constrói uma vez, empacota com o modelo SPFx que já conhece, e reutiliza onde as pessoas já trabalham. Isso importa especialmente em organizações onde parte da equipe vive no Teams, parte vive em portais SharePoint, e agora uma fatia crescente vai interagir via Copilot. Manter três interfaces separadas para a mesma tarefa é custo de manutenção que ninguém precisa carregar.

Hospedagem, MCP Apps e o que você não precisa operar

Um detalhe técnico relevante para quem avalia esforço de implantação: não há infraestrutura nova para subir. O Microsoft 365 cuida de hospedagem, roteamento de ferramentas, segurança e governança automaticamente. O componente é empacotado com SPFx e distribuído usando MCP Apps, o padrão que permite ao Copilot descobrir, invocar e renderizar essas experiências de forma governada dentro do tenant.

Isso é diferente de construir um plugin de Copilot Studio conectado a um endpoint externo que você precisa manter no ar, monitorar e escalar. Aqui, o app roda hospedado dentro do próprio Microsoft 365, seguindo o mesmo modelo de confiança e identidade que já rege SharePoint e Teams.

Como o modelo é baseado em padrões abertos de web, e não em um runtime proprietário fechado, ferramentas de codificação assistida por IA como GitHub Copilot, Claude e Codex já conseguem gerar, refatorar e depurar esses componentes dentro do IDE, no mesmo stack JavaScript que a equipe já usa no dia a dia.

Como começar: instalando o SPFx 1.24 preview

O ponto de entrada é técnico e direto. O SPFx 1.24 preview já está disponível via npm, e o fluxo de scaffolding segue o padrão que qualquer desenvolvedor SharePoint já conhece.

# Instala o gerador do SharePoint Framework na versão preview
npm install -g @microsoft/generator-sharepoint@next

# Cria um novo projeto SPFx a partir do gerador instalado
yo @microsoft/sharepoint

Durante o preview, qualquer desenvolvedor, em qualquer tenant Microsoft 365, em qualquer região, pode construir e testar SharePoint Copilot Apps, sem precisar de licença de Microsoft 365 Copilot para o desenvolvimento em si. É uma barreira de entrada propositalmente baixa para acelerar feedback. Vale registrar que o licenciamento final está sujeito a mudança até a disponibilidade geral, então não trate essa condição como definitiva para planejamento de custo de produção.

O Copilot Workbench, ambiente onde você testa a experiência antes de publicar, já está disponível para qualquer desenvolvedor a partir de hoje. É onde faz sentido validar como seu componente se comporta dentro do canvas antes de expor para usuários finais.

O que dá para construir com isso

SharePoint Copilot Apps fazem sentido quando a tarefa do usuário termina em uma decisão ou uma ação, não em uma resposta. Alguns exemplos concretos de aplicação, independente do setor:

• Aprovações estruturadas: painel que mostra os dados relevantes, as opções disponíveis e as consequências de cada escolha antes do usuário decidir, em vez de um botão genérico de “aprovar” sem contexto.
• Triagem de incidentes: formulário que já traz histórico, severidade e responsável sugerido, permitindo classificar e encaminhar sem sair da conversa com o Copilot.
• Checklists de onboarding: experiência guiada, passo a passo, que valida cada etapa antes de liberar a próxima, em vez de depender de um texto solto explicando o processo.
• Dashboards operacionais: gráfico ou grid filtrável com dados ao vivo, trazido para dentro do canvas em vez de forçar o usuário a abrir um relatório separado.
• Solicitações de compra ou tarefas de CRM: painel de tarefa que já valida regra de aprovação e limite de alçada antes de submeter.

A Microsoft demonstrou um cenário chamado My Day, alimentado pelo que chamam de Work IQ, onde o usuário recebe um plano pessoal com contexto relevante já organizado, dentro do próprio canvas do Copilot. É um bom exemplo de como o mesmo padrão, Copilot entendendo intenção e o app estruturando a experiência, se aplica tanto a um fluxo transacional quanto a um resumo de produtividade pessoal.

Governança: o que muda de verdade

Este é o ponto que mais interessa a quem responde por segurança e conformidade dentro da organização. Ações de negócio dentro do Copilot sempre foram um risco em potencial quando dependiam apenas de linguagem natural interpretada por um modelo. SharePoint Copilot Apps deslocam essa responsabilidade de volta para código determinístico.

A validação de regra de negócio, a checagem de permissão, a confirmação antes de uma ação irreversível, tudo isso continua vivendo no app, escrito e testado pela sua equipe, não inferido pelo modelo de linguagem no momento da conversa. O Copilot decide quando chamar o app e com que contexto, mas não decide sozinho como a aprovação é processada ou quem tem permissão para executá-la.

Isso não elimina a necessidade de revisão de segurança sobre o próprio componente. Um SharePoint Copilot App mal escrito, sem validação de permissão adequada no lado do app, ainda é uma superfície de risco, só que agora exposta dentro do Copilot em vez de dentro de uma página SharePoint. A disciplina de revisão de código e de teste de permissão que sua equipe já aplica a web parts SPFx continua sendo o controle real aqui, o Copilot não substitui essa camada.

O que ainda é preview, e o que isso significa na prática

Vale ser direto sobre o estágio da tecnologia antes de colocar em roadmap de produção. Alguns pontos concretos:

• Nome de trabalho: “SharePoint Copilot Apps” é um nome provisório para o preview público e pode mudar antes da disponibilidade geral. APIs e capacidades também podem mudar.
• Rollout em andamento: a disponibilidade para usuário final está sendo liberada gradualmente por região, com previsão de cobertura mundial completa até 20 de julho de 2026. Se a experiência ainda não aparece para os usuários no seu tenant, o ambiente de desenvolvimento já funciona, mas o consumo final pode não estar disponível ainda em todas as regiões.
• Ambiente de desenvolvimento já ativo: o Copilot Workbench e o fluxo completo de desenvolvimento já estão liberados para qualquer desenvolvedor, independente do estágio de rollout regional para usuários finais.

Para uma organização que já opera SPFx em produção, a recomendação prática é começar agora em ambiente de desenvolvimento, testar um componente já existente adaptado para o Copilot Apps, e usar esse período de preview para levantar as questões de governança internas antes que a experiência chegue aos usuários finais. Esperar a disponibilidade geral para começar a entender o modelo é perder a janela de aprendizado sem custo real de produção.

O que isso sinaliza sobre a direção do Microsoft 365

Copilot deixando de ser só um gerador de resposta para se tornar uma superfície de execução de aplicações reais muda o cálculo de investimento em SPFx. Times que hesitaram em modernizar web parts antigas, ou que trataram SPFx como tecnologia de manutenção, ganham um motivo concreto para revisitar esse portfólio: o mesmo componente que hoje vive numa página SharePoint pode, com adaptação, aparecer dentro do fluxo natural de trabalho de quem usa Copilot.

A decisão de arquitetura que fica pendente para cada organização não é se vale a pena testar, o custo de entrada é baixo e não exige licença adicional durante o preview. A decisão real é qual processo interno merece ser o primeiro candidato: normalmente aquele que já tem volume alto de idas e vindas entre chat e sistema, e que já vive dentro de um componente SPFx testado e maduro.

Se sua operação já tem SPFx em produção e quer entender onde esse investimento se encaixa dentro dessa nova camada do Copilot, a conversa certa começa por mapear quais componentes fazem sentido migrar primeiro, sem quebrar o que já funciona hoje.