Power Automate no GitHub Copilot CLI: guia de instalação

Por Luiz Antonio Sgargeta
Power Automate no GitHub Copilot CLI: guia de instalação

Power Automate no GitHub Copilot CLI: o que muda para quem já vive no terminal

A Microsoft publicou no Power Platform skills marketplace um plugin que traz o Power Automate para dentro do GitHub Copilot CLI e do Claude Code. Na prática, isso significa criar, editar, rodar e depurar fluxos cloud descrevendo o que você quer em linguagem natural, sem abrir o portal maker, sem navegar por galerias de conectores e sem clicar em cada ação do designer.

Para um analista de negócio isso pode parecer redundante, o Copilot dentro do próprio Power Automate já faz algo parecido. A diferença aqui é o público. Este plugin foi desenhado para quem já trabalha em terminal, pipeline de CI/CD e repositório Git, não para quem constrói fluxos pontuais no navegador. Em plantas industriais isso costuma ser o time de ITOps que mantém a integração entre MES, SAP e Dataverse, ou o desenvolvedor que já versiona soluções de Power Platform como parte da esteira de deploy.

Este tutorial mostra a instalação do plugin, os pré-requisitos reais, três prompts de uso corrente em ambiente industrial e a armadilha que qualquer time de ITOps precisa internalizar antes de deixar o plugin tocar em um fluxo produtivo.

Este plugin não é para citizen developer

Vale deixar isso explícito antes do passo a passo, porque muda a forma de ler o restante do tutorial. O plugin do Power Automate no GitHub Copilot CLI pressupõe conforto com terminal, autenticação via linha de comando, leitura de JSON de definição de fluxo e, idealmente, algum processo de revisão de código já estabelecido. Ele não substitui o Copilot integrado ao portal maker, que continua sendo o caminho certo para quem cria automações pontuais sem sair da interface web.

Quem deveria usar este plugin:

  • Desenvolvedores de Power Platform que já mantêm soluções em repositório Git e usam pac CLI no dia a dia.
  • Times de ITOps responsáveis por integrações entre Dataverse, SAP, MES e sistemas de chão de fábrica, que hoje escrevem scripts de automação em outras linguagens e querem trazer parte dessa lógica para o Power Automate sem trocar de ferramenta de terminal.
  • Engenheiros que já usam GitHub Copilot CLI ou Claude Code para outras tarefas de infraestrutura e querem estender o mesmo fluxo de trabalho para automação de processos.

Quem não deveria começar por aqui: analistas de operação, supervisores de linha ou qualquer perfil que hoje resolve suas automações direto no portal do Power Automate. Para esse público, o Copilot nativo do maker portal é a via correta, com menos superfície de erro e nenhuma exigência de terminal.

Pré-requisitos antes de instalar

Confira cada item antes de começar. A maior parte dos erros de instalação vem de um pré-requisito pulado, não de falha do plugin em si.

  • Assinatura do GitHub Copilot: plano Pro, Pro+, Business ou Enterprise. O GitHub Copilot CLI não roda no acesso gratuito limitado.
  • Node.js 18 ou superior instalado na máquina que vai rodar o CLI, requisito do próprio GitHub Copilot CLI.
  • Claude Code instalado, se optar por essa via em vez do Copilot CLI. Os dois consomem o mesmo plugin do Power Platform skills marketplace.
  • Power Platform CLI (pac) instalado e atualizado, usado para autenticar o plugin no tenant correto.
  • Papel de Environment Maker no ambiente Dataverse onde os fluxos serão criados ou editados. Para alterar conexões, é preciso ser dono da conexão ou ter papel de administrador do ambiente.
  • Licença de Power Automate compatível com os conectores que o fluxo vai usar. Fluxos que tocam SAP, SQL Server on-premises ou conectores premium exigem plano per-user ou per-flow, o plano seeded do Microsoft 365 não cobre esses cenários.
  • Consentimento prévio de administrador para os conectores usados em produção, especialmente SAP e bancos de dados internos, se a política de DLP do tenant exigir aprovação explícita.
Sequência de seis passos para instalar e usar o plugin do Power Automate no GitHub Copilot CLI
O passo de revisar a definição gerada antes de publicar é o único que não pode ser pulado em conexões de produção.

Passo a passo: instalando o plugin do Power Automate

Passo 1: instale o GitHub Copilot CLI ou o Claude Code

Se ainda não tem o CLI na máquina, instale via npm. O caminho é o mesmo independente do sistema operacional, desde que o Node.js esteja na versão exigida.

# Instala o GitHub Copilot CLI
npm install -g @github/copilot

# Ou, se preferir o Claude Code
npm install -g @anthropic-ai/claude-code

O racional aqui é simples: o plugin do Power Automate não é um produto independente, ele é uma skill que roda dentro de um desses dois CLIs de IA. Sem o CLI base instalado e autenticado no GitHub ou na Anthropic, o plugin não tem onde rodar.

Passo 2: autentique o CLI no seu tenant Microsoft

Com o Power Platform CLI instalado, autentique no ambiente onde os fluxos vão viver. Isso é o que permite ao plugin enxergar suas soluções, conexões e ambientes disponíveis.

pac auth create --url https://suaorg.crm.dynamics.com

Sem essa autenticação, o plugin até inicia dentro do Copilot CLI, mas qualquer prompt que peça para criar ou listar fluxos retorna erro de contexto, porque não há ambiente associado à sessão.

Passo 3: instale o plugin do Power Automate a partir do Power Platform skills marketplace

Dentro da sessão do GitHub Copilot CLI ou do Claude Code, adicione a skill do Power Automate. O comando de instalação de skills varia conforme a versão do CLI, então confira a sintaxe atual na documentação do próprio CLI antes de rodar em produção.

copilot
> /skills add power-automate

Esse passo é o que diferencia este plugin de um simples prompt genérico de IA. Ele registra no CLI o conjunto de operações específicas do Power Automate, como criar definição de fluxo, listar conectores disponíveis no ambiente, consultar histórico de execução e propor correções em ações que falharam.

Passo 4: selecione o ambiente de trabalho

Peça ao plugin para listar os ambientes disponíveis e escolha explicitamente onde os fluxos serão criados. Em plantas com múltiplos ambientes, um de desenvolvimento e outro produtivo ligado ao SAP real, este é o passo mais fácil de pular e o mais caro de errar.

liste os ambientes disponíveis para minha conta e mostre quais têm a conexão SAP ativa

O plugin responde com o nome de cada ambiente, o papel que você tem nele e as conexões já autorizadas. Confirme o ambiente de desenvolvimento antes de pedir qualquer criação de fluxo.

Três prompts reais para o dia a dia de ITOps na indústria

A seguir, três situações comuns em operações industriais que dependem de integração entre Dataverse, MES, SAP e Teams. Os prompts são escritos como você digitaria de fato no terminal, sem embelezamento.

Prompt 1: criar um fluxo do zero, a partir de uma descrição de processo

crie um fluxo cloud que dispare quando uma nova linha for criada na tabela
Ordens de Produção do Dataverse. Verifique se a Linha de Produção informada
existe na tabela Linhas. Se não existir, poste uma mensagem no canal do Teams
"Manutenção - Chão de Fábrica" com o número da ordem e crie uma aprovação
para o supervisor de turno. Use a conexão Dataverse já configurada no ambiente
de desenvolvimento, não publique o fluxo ao final, deixe desligado para revisão.

Repare no fechamento do prompt: pedir explicitamente para não publicar. O plugin cria a definição, mas o estado inicial do fluxo, ligado ou desligado, é algo que você controla no próprio texto do pedido. Fluxos criados sem essa instrução costumam nascer desligados por padrão, mas não conte com esse comportamento sem verificar antes de publicar em ambiente compartilhado.

Prompt 2: atualizar um fluxo existente sem reescrevê-lo do zero

no fluxo "Notificação de Parada de Máquina", adicione uma condição que escale
para o gerente de manutenção quando o tempo de parada ultrapassar 4 horas.
Adicione também uma política de nova tentativa com backoff exponencial na
chamada HTTP que envia dados para o MES, limite de 4 tentativas. Não altere
o gatilho nem a conexão com o Teams. Mostre o diff antes de salvar.

A instrução “mostre o diff antes de salvar” é o comportamento que você quer reforçar em todo prompt de edição. O plugin altera a definição JSON do fluxo existente, e sem pedir explicitamente o diff, é fácil perder de vista o que mudou em uma ação com múltiplas ramificações condicionais.

Prompt 3: investigar um fluxo com execuções falhando

o fluxo "Sincroniza Ordem de Compra com SAP" falhou nas últimas 12 execuções,
sempre por volta das 6h. Investigue o run mais recente, mostre qual ação
falhou, o código de erro retornado pela conexão SAP e sugira uma correção.
Não aplique nenhuma mudança ainda, só me traga o diagnóstico.

Esse é o uso mais valioso do plugin para ITOps: transformar a investigação de um run falho, que normalmente exige abrir o histórico de execuções no portal, expandir cada ação e ler o payload de erro manualmente, em uma pergunta direta que retorna causa provável e sugestão de correção em segundos. Pedir explicitamente para não aplicar mudança nenhuma mantém a investigação separada da remediação, o que ajuda a documentar o incidente antes de qualquer alteração no fluxo.

Como validar que o fluxo gerado está correto

Depois que o plugin responde com a definição criada ou alterada, valide nesta ordem antes de considerar o trabalho concluído:

  1. Leia o resumo em linguagem natural que o plugin retorna, comparando ação por ação com o que você pediu no prompt original.
  2. Abra o fluxo no portal maker (Power Automate, seção Meus fluxos) para confirmar visualmente a estrutura, mesmo tendo criado tudo pelo terminal. Isso ainda é o lugar mais confiável para ver o desenho completo de condições e ramificações.
  3. Rode o Flow Checker dentro do designer. Ele aponta ações sem conexão válida, expressões mal formadas ou limites de licença estourados, problemas que o plugin não necessariamente sinaliza no terminal.
  4. Execute um teste manual com um registro de exemplo antes de habilitar o fluxo para uso real. Em fluxos que tocam SAP ou MES, use um ambiente de homologação com dados sintéticos, nunca a instância produtiva.
  5. Confira o histórico de execução do teste (Power Automate > Meus fluxos > nome do fluxo > Histórico de execução) para garantir que cada ação rodou com o resultado esperado, não apenas que o fluxo terminou sem erro aparente.

Se todos esses pontos baterem, o fluxo está pronto para ser ligado (Turn on) e, se aplicável, publicado como parte de uma solução gerenciada.

Erros comuns e o que eles significam

  • Flow was not saved: The caller does not have permission for connector: a política de prevenção contra perda de dados (DLP) do ambiente bloqueia a combinação de conectores usada no fluxo, por exemplo misturar SAP com um conector de e-mail pessoal na mesma sequência. Solução: revisar a política de DLP com o administrador do tenant antes de pedir o fluxo ao plugin.
  • AADSTS65001: The user or administrator has not consented to use the application: a conexão referenciada no prompt exige consentimento de administrador que ainda não foi dado no tenant. Isso é comum em conexões SAP configuradas por outra equipe. Solução: peça ao administrador do ambiente para conceder consentimento à conexão antes de tentar novamente.
  • InvalidTemplate. Unable to process template language expressions: a expressão gerada pelo plugin referencia um campo ou variável que não existe na definição final do fluxo, geralmente por ambiguidade no prompt original (por exemplo, dois campos com nomes parecidos na tabela Dataverse). Solução: peça ao plugin para listar as colunas exatas da tabela antes de descrever a condição.
  • pac auth create requires interactive login: a autenticação de ambiente expirou ou nunca foi concluída de forma interativa, comum quando o comando é rodado dentro de um pipeline CI/CD sem sessão de terminal interativa. Solução: use um perfil de autenticação com identidade de serviço (service principal) registrado previamente, em vez de login interativo, para cenários automatizados.

A armadilha: o plugin altera definições de produção, e isso exige revisão humana

O ponto que mais importa neste tutorial é este: o plugin do Power Automate gera e altera definições de fluxo de forma autônoma, a partir de linguagem natural. Ele não pede confirmação passo a passo dentro de cada ação como faria um humano editando no designer. Isso é exatamente o que o torna rápido, e exatamente o que exige disciplina de revisão antes de qualquer publicação.

Em ambiente industrial, o risco concreto é este: um prompt de edição malformado ou ambíguo pode alterar a condição de escalonamento de um fluxo de parada de máquina, remover sem querer uma tentativa de reenvio que existia para tolerar instabilidade da rede da planta, ou apontar uma ação para a conexão SAP produtiva em vez da conexão de homologação, se o ambiente errado estiver selecionado na sessão.

Revisar o diff da definição e testar em ambiente de homologação antes de habilitar o fluxo não é uma boa prática opcional aqui, é a única forma responsável de usar este plugin em conexões com escopo de produção.

Trate cada resposta do plugin como um pull request, não como um comando executado. Peça o diff, leia a definição JSON gerada quando a mudança for sensível, rode o Flow Checker, teste com dados sintéticos e só então habilite. Times que já têm processo de ALM com pipelines e ambientes segregados vão notar que este plugin se encaixa naturalmente nesse fluxo de trabalho, ele só antecipa a etapa de rascunho para dentro do terminal.

Onde isso se encaixa na operação

Para plantas que já rodam integração entre Dataverse, SAP e sistemas de chão de fábrica, este plugin reduz o tempo entre identificar um problema de automação e ter um diagnóstico ou correção pronta para teste, sem trocar de ferramenta nem sair do terminal onde o time de ITOps já trabalha o dia inteiro. O ganho real não é a criação de fluxos do zero, que continua exigindo o mesmo cuidado de sempre, mas a velocidade de investigação e ajuste em fluxos que já existem e já rodam em produção.

Quando esse tipo de automação começa a se multiplicar entre times diferentes, com conexões de escopo de produção espalhadas por vários ambientes, a conversa deixa de ser sobre qual ferramenta usar e passa a ser sobre governança: quem aprova o quê, qual ambiente é homologação de fato e quais conectores exigem revisão antes de qualquer IA, humana ou não, tocar neles. É nesse ponto que vale sentar com quem já desenhou essa governança em operações industriais parecidas com a sua.

Ver mais artigos

Entre em Contato

Vamos juntos transformar sua dor
em solução!

#moveFast