Botão SharePoint Workflows: o que muda na automação

Um botão que muda quem cria automação na sua organização

Se você abriu uma lista ou biblioteca do SharePoint nas últimas semanas, deve ter notado um botão novo na barra de comandos, ao lado de Novo e Compartilhar. Chama-se Workflows, e ele não é só mais um atalho para o Power Automate. É uma reescrita da experiência de criação de automação para quem nunca abriu o designer completo e provavelmente nunca vai abrir.

O impacto prático é direto. Antes, montar uma automação simples, como avisar o time no Teams quando um item é criado, exigia entender conectores, gatilhos, ações e conteúdo dinâmico. Agora essa mesma tarefa cabe em um formulário de preencher lacunas, dentro do próprio SharePoint. Isso democratiza a automação, mas também abre uma porta que times de TI e governança precisam monitorar. Vamos aos detalhes, incluindo uma nuance sobre aprovações que pode custar caro se passar despercebida.

Onde o botão aparece e o que saiu do lugar

O botão Workflows está aparecendo tanto em listas quanto em bibliotecas de documentos. O rollout é gradual, então a ausência dele no seu tenant hoje não significa que algo está errado, só que ainda não chegou a vez do seu ambiente.

Uma mudança que passa fácil desapercebida: o antigo menu Automate desapareceu. No lugar, a Microsoft consolidou tudo dentro de um menu chamado Integrate, que agora reúne fluxos, Quick Steps, aprovações, regras e Power Apps num único ponto de entrada. Para quem administra sites e treina usuários, isso significa atualizar qualquer material de referência que ainda mostre o caminho antigo, porque a rota de navegação mudou, mesmo que a funcionalidade por trás continue essencialmente a mesma.

O que tem dentro do painel Workflows

Ao clicar no botão, abre um painel dividido em quatro áreas:

• Busca: uma caixa para procurar templates ou simplesmente descrever em texto livre o que você quer automatizar.
• Start from a template: uma galeria rolável com os automações mais comuns já prontas, tipo notificação de aprovação, alerta de vencimento, cópia entre bibliotecas.
• Build from scratch: para quem precisa de algo que nenhum template cobre.
• Your workflows: a lista de tudo que você já criou, com botão para ligar e desligar cada automação.

Gerenciar fluxos sem saltar para o Power Automate

A aba Your workflows resolve um atrito antigo. Antes, para pausar um fluxo, ver histórico de execução ou adicionar um coproprietário, era preciso abrir o Power Automate, achar o fluxo certo entre dezenas de outros do tenant e navegar pelas configurações. Agora isso acontece dentro do próprio SharePoint, no contexto da lista ou biblioteca onde o fluxo vive. Para quem administra vários sites, isso reduz o número de saltos entre ferramentas, mas não elimina a necessidade de visibilidade centralizada: um fluxo criado por um usuário final continua sendo um objeto do Power Automate, sujeito às mesmas regras de licenciamento, ambiente e política de prevenção de perda de dados (DLP) que qualquer outro fluxo do tenant.

Build from scratch: a interface Mad Libs e seus limites reais

A experiência de construção do zero é o que realmente abre essa ferramenta para quem não é técnico. Em vez do designer completo, com sua lista de conectores e painel de conteúdo dinâmico, o usuário vê uma frase em português simples que vai se completando conforme ele escolhe opções em menus suspensos. Escolhe o gatilho, por exemplo “quando um item é criado”, escolhe a ação, por exemplo “enviar mensagem em um canal do Teams”, e o painel conduz campo por campo.

Aqui está o limite que precisa ficar claro antes de vender esse recurso para o negócio: essa interface permite apenas um gatilho e uma ação. Não tem condição, não tem loop, não tem múltiplos passos encadeados. Para cenários de notificação e alerta, que são a maioria das solicitações informais que chegam à TI, isso já resolve. Para qualquer coisa com ramificação de lógica, aprovação em múltiplos níveis ou integração com sistemas externos, o Mad Libs não serve.

A boa notícia é que a escalada é natural. Um fluxo criado por esse painel pode ser aberto depois com a opção Edit in Power Automate, e a partir daí o usuário, ou mais realisticamente alguém do time de TI, ganha acesso ao designer completo, com condições, loops e ações adicionais. Isso cria um padrão interessante de adoção progressiva: o usuário de negócio resolve o caso simples sozinho, e quando a necessidade cresce, o fluxo já existe como ponto de partida para quem tem mais experiência em Power Automate assumir a complexidade.

AI Workflows com Copilot: outra camada, outra licença

Quem tem licença do Microsoft 365 Copilot vê um painel um pouco diferente. Aparece uma aba adicional, AI Workflows, ao lado da aba Workflows padrão, com templates como “recapitular comunicações sobre um tema” ou “me ajudar a preparar o meu dia”. Esses fluxos usam prompts e ações de IA em vez de conectores tradicionais, o que significa que conseguem resumir e-mails, gerar relatórios recorrentes a partir de agentes de canal e rodar prompts agendados contra os itens da lista.

Existe uma diferença estrutural importante aqui, e é fácil não notar até bater de frente com ela: os AI Workflows não têm a opção Edit in Power Automate. Diferente dos fluxos padrão, que sempre podem escalar para o designer completo, os fluxos com ações do Copilot só podem ser editados dentro do próprio painel do SharePoint. Isso tem uma consequência prática de governança: esses fluxos não seguem o mesmo ciclo de vida de aplicação (ALM) que um fluxo tradicional exportado, versionado e movido entre ambientes via soluções do Power Platform. Eles ficam presos ao contexto onde foram criados. Antes de construir um processo crítico de negócio sobre um AI Workflow, vale considerar se essa limitação de portabilidade é aceitável para o caso de uso.

A armadilha da aprovação que ninguém avisa

Este é o ponto mais importante deste artigo, porque é o tipo de erro que só aparece quando alguém pergunta “por que esse item não mudou de status depois que foi aprovado?” e a resposta demora para chegar.

Ao montar um fluxo de aprovação pelo novo painel, aparecem duas opções de ação com nomes parecidos, mas comportamento completamente diferente:

A ação padrão de Approvals é genérica, funciona em qualquer contexto do Microsoft 365 e não tem noção nenhuma de que existe um item de lista por trás. Ela dispara a notificação, alguém aprova no Teams, e o fluxo segue seu caminho, mas o item na lista continua exatamente como estava antes, sem histórico visível de que foi aprovado. Para quem depende dessa coluna de status para relatórios, visualizações filtradas ou regras de retenção, isso é um problema silencioso: o processo “funciona” no sentido de que a notificação chega, mas o rastro de auditoria simplesmente não existe.

A ação Create an approval request do SharePoint exige um passo prévio, habilitar a configuração de aprovações na própria lista, mas em troca ela fecha o ciclo: quando alguém aprova ou rejeita, a coluna de status do item é atualizada automaticamente, sem passo adicional no fluxo. Se o objetivo é ter aprovações que realmente aparecem refletidas nos itens do SharePoint, essa é a ação a usar, não a genérica de Approvals.

Vale revisar qualquer fluxo de aprovação já criado por usuários finais nas últimas semanas usando esse botão. Se a ação escolhida foi a genérica, o processo pode estar rodando sem deixar rastro nenhum no repositório, e ninguém vai notar até que um auditoria ou uma reclamação de status desatualizado apareça.

Implicações de governança para quem administra o tenant

O botão Workflows resolve um problema real de adoção, mas desloca a fronteira entre “usuário final experimentando” e “automação de negócio em produção”. Alguns pontos que merecem atenção de quem cuida do ambiente:

• Licenciamento não muda: o botão em si é gratuito e disponível para todos, mas os fluxos criados por ele continuam sujeitos às regras normais do Power Automate. Conectores premium ainda exigem plano por usuário ou por fluxo. A licença do Microsoft 365 Copilot só destrava a aba AI Workflows e os templates de IA, nada além disso.
• Fluxos órfãos: um fluxo criado por um colaborador dentro de uma lista fica associado à conta dele. Se essa pessoa sai da empresa e a conta é desativada sem transferência de propriedade, o fluxo para de rodar. O recurso de adicionar coproprietário direto no painel Your workflows ajuda, mas só se alguém lembrar de usar.
• Visibilidade fragmentada: como a criação agora acontece dentro do contexto de cada lista e biblioteca, fica mais difícil ter uma visão consolidada de quantos fluxos existem no tenant e o que fazem. Ferramentas como o Power Platform admin center e o CoE Starter Kit continuam sendo a forma de manter esse inventário atualizado, e vale reforçar essa rotina justamente porque a barreira de entrada para criar caiu.
• DLP e conectores: políticas de prevenção de perda de dados aplicadas ao ambiente continuam valendo para qualquer fluxo criado pelo botão. Se a política bloqueia a combinação de determinados conectores, o usuário vai encontrar esse bloqueio mesmo dentro da interface simplificada, só que sem o contexto que o Power Automate normalmente oferece para entender o motivo.

Nada disso é motivo para bloquear o botão. É motivo para comunicar aos times de negócio o que ele resolve bem, o que não resolve, e criar um processo leve de revisão periódica das automações criadas fora do radar tradicional de TI.

Quando usar o botão e quando escalar para automação mais robusta

• Use o Mad Libs para notificações simples, alertas de vencimento, avisos de criação ou alteração de item, um gatilho e uma ação, sem lógica condicional.
• Escale para o designer completo quando o processo precisar de múltiplas etapas, condições, loops, integração com sistemas fora do Microsoft 365, ou aprovação em vários níveis.
• Use Create an approval request do SharePoint sempre que a aprovação precisar refletir no status do item. Reserve a ação genérica de Approvals apenas para casos em que a notificação é o único objetivo e não existe necessidade de rastro na lista.
• Avalie os AI Workflows caso a caso, considerando que eles não migram para o Power Automate e ficam limitados à edição dentro do painel do SharePoint.

O botão Workflows tira do usuário final a barreira técnica de abrir o Power Automate do zero, e isso é uma mudança real na forma como a automação se espalha dentro de uma organização. A questão que fica para quem cuida da governança não é se vale a pena usar, mas como manter visibilidade sobre o que está sendo criado, com que consequência para os dados, e onde termina o espaço seguro do usuário final e começa o território que precisa de acompanhamento técnico. Se sua operação está avaliando como estruturar essa fronteira entre automação self-service e automação governada, essa é uma conversa que vale ter com quem já desenhou esse tipo de arquitetura antes.