RPA com Power Automate Desktop: quando e como usar

Tem um sistema legado sem API travando a automação, e alguém digitando à mão todo dia#

Quase toda empresa tem aquele processo preso a uma tela antiga. Um ERP dos anos 2000 sem API pública, um portal de terceiro que só aceita entrada manual, uma planilha que alguém copia e cola de um sistema para outro toda manhã. É exatamente esse ponto que a RPA com Power Automate Desktop resolve: em vez de integrar por trás, pelo banco ou por uma API, o robô usa a interface do sistema como uma pessoa usaria, clicando, digitando e lendo valores na tela. Quando não existe porta de entrada oficial, a tela vira a porta.

Este artigo é um guia prático de quando e como usar RPA com Power Automate Desktop. Vamos ver o que é RPA de fato, como um fluxo de desktop automatiza tarefas em telas e sistemas legados, a diferença entre o modo assistido e o não assistido, como um fluxo de nuvem dispara o robô, e a decisão que mais importa: quando RPA é a resposta certa e quando ela é só um remendo que vai quebrar. Se você quer o panorama da plataforma inteira antes de entrar nesse detalhe, vale ler nosso guia completo de Power Apps e Power Automate.

O que é RPA, e por que o Power Automate Desktop faz isso automatizando a interface#

RPA é a sigla de Robotic Process Automation, automação robótica de processos. A ideia é usar software para reproduzir as ações que uma pessoa faz numa interface: abrir um programa, clicar em botões, preencher campos, copiar um valor de uma tela e colar em outra, extrair dados de um relatório. O robô não entende o processo, ele repete a sequência de interações que você definiu.

O Power Automate Desktop é o componente de RPA da Microsoft Power Platform. Ele grava ou constrói, num designer visual, uma sequência de passos que interagem com aplicativos de desktop, navegadores, planilhas, e-mail, terminais e pastas de arquivo. Na prática, ele automatiza a interface do sistema alvo. Essa é a característica que define o RPA e também a que explica sua fragilidade, um ponto ao qual voltamos mais adiante.

Vale separar dois mundos que vivem juntos no Power Automate e que as pessoas confundem o tempo todo:

• Fluxos de nuvem integram sistemas que oferecem API ou conector. Eles conversam com o sistema por baixo da interface, de forma estruturada e estável.
• Fluxos de desktop são a RPA. Eles operam por cima da interface, simulando clique e digitação, e existem justamente para os casos em que não há API disponível.

Escolher entre os dois não é preferência técnica, é uma questão do que o sistema alvo permite. Se existe API, quase sempre ela é o caminho. Se não existe, a RPA entra.

Como um fluxo de desktop automatiza uma tarefa em tela, passo a passo#

Na prática, montar um fluxo de desktop segue um roteiro parecido em quase todo projeto:

1. Mapear a tarefa manual em passos exatos. Antes de gravar qualquer coisa, escreva o que a pessoa faz, na ordem, incluindo as decisões: "se o campo status estiver vazio, pular o registro". RPA não improvisa, então o que não estiver mapeado, o robô não faz.
2. Construir o fluxo no Power Automate Desktop. Você arrasta ações do designer ou usa o gravador, que captura seus cliques e digitação e transforma em passos editáveis. Cada elemento de tela, um botão, um campo, é capturado como um seletor que o robô vai procurar na hora de executar.
3. Parametrizar as entradas e saídas. Em vez de valores fixos, o fluxo recebe variáveis, o número do pedido, o caminho do arquivo, e devolve resultados, como uma confirmação ou os dados extraídos. É isso que permite rodar o mesmo robô para milhares de itens.
4. Tratar erro e exceção. Tela que demora a carregar, pop-up inesperado, registro que não existe. Um robô sem tratamento de erro trava no primeiro caso fora do script. Blocos de repetição, esperas condicionais e captura de exceção são o que separam um piloto de uma automação de produção.
5. Testar com dados reais e variados. O robô precisa ver os casos de borda antes da produção, não depois. Rode com registros bons, ruins e incompletos.
6. Publicar e agendar. O fluxo fica disponível para rodar com um humano presente ou de forma agendada, disparado por um fluxo de nuvem, o que nos leva às duas modalidades de execução.

Attended e unattended são dois modos com custos e riscos diferentes#

O Power Automate Desktop roda em duas modalidades, e a escolha muda infraestrutura, licenciamento e o tipo de processo que faz sentido automatizar.

O modo atendido (attended) roda na máquina do próprio usuário, com ele presente. Serve para acelerar uma tarefa repetitiva do dia a dia: a pessoa clica para iniciar o robô, ele preenche o cadastro chato, e ela segue com o resto do trabalho. É como ter um assistente que cuida da parte mecânica enquanto a pessoa supervisiona.

O modo não atendido (unattended) roda sozinho, sem ninguém na frente da tela, numa máquina dedicada sempre ligada. Serve para volume e horário: processar mil registros de madrugada, fechar uma rotina toda noite, consolidar relatórios antes do expediente. Esse modo exige licenciamento próprio e uma infraestrutura confiável, porque não há humano para destravar se algo sair do esperado.

Aspecto	Atendido (attended)	Não atendido (unattended)
Onde roda	Na máquina do usuário	Em máquina dedicada, sempre disponível
Presença humana	Necessária, o robô ajuda a pessoa	Nenhuma, o robô roda sozinho
Disparo	Manual, o usuário inicia	Agendado ou por fluxo de nuvem
Melhor para	Tarefas pontuais do dia a dia, baixo volume	Rotinas de alto volume, horários fixos, escala
Licenciamento	Mais simples, ligado ao usuário	Exige licença específica de execução não assistida
Risco em falha	Baixo, a pessoa percebe e corrige	Alto, precisa de monitoramento e alerta ativos

A regra prática: comece atendido para validar o processo com o usuário por perto, e migre para não atendido só quando o fluxo estiver estável e o volume justificar a máquina dedicada e a licença extra. Pular direto para o não atendido é a forma mais rápida de descobrir um erro de madrugada, sem ninguém para tratar.

Um fluxo de nuvem pode acionar o fluxo de desktop, e é assim que a RPA escala#

A RPA sozinha é útil, mas ela ganha força quando entra numa orquestração maior. Um fluxo de nuvem do Power Automate pode acionar um fluxo de desktop como uma de suas ações. Isso conecta os dois mundos: a parte estruturada do processo roda na nuvem, com API e conectores, e o pedaço que só existe na tela roda no robô de desktop.

Um exemplo comum: um fluxo de nuvem monitora uma caixa de e-mail, quando chega uma nota fiscal em anexo, ele salva o arquivo, extrai os dados e então chama o fluxo de desktop para lançar essa nota no sistema legado que não tem API. Terminado o lançamento, o robô devolve o número gerado e o fluxo de nuvem registra tudo e notifica o responsável. O usuário nunca abre o sistema antigo, mas o dado entra lá do mesmo jeito.

Esse padrão, nuvem orquestra e desktop executa a parte de tela, é o que permite usar RPA em escala com governança: o histórico de execução fica centralizado, o disparo é automático e o trecho frágil, a interface, fica isolado num único ponto do processo. Para desenhar automações combinadas assim de forma sustentável, vale conhecer nossos serviços de Power Platform.

Quando usar RPA com Power Automate Desktop, e quando preferir a API#

Esta é a decisão que mais economiza dinheiro e dor de cabeça no longo prazo. RPA de tela e integração por API resolvem o mesmo problema de negócio, mover dados entre sistemas, mas têm perfis de custo e risco muito diferentes.

Critério	RPA (fluxo de desktop)	Integração por API
Quando existe	Sistema sem API, tela antiga, portal de terceiro fechado	Sistema moderno com API ou conector disponível
Como funciona	Simula clique e digitação na interface	Troca dados estruturados por trás da tela
Estabilidade	Frágil: quebra com mudança de layout ou versão	Estável: só quebra se a API mudar o contrato
Velocidade de execução	Limitada ao tempo de carregar telas	Alta, sem depender da interface
Esforço de manutenção	Maior, exige acompanhar mudanças visuais	Menor, contrato de API é mais previsível
Melhor papel	Solução de transição ou último recurso	Arquitetura definitiva quando disponível

A orientação honesta é simples: quando existe API, prefira a API. A RPA deve ser escolhida quando não há alternativa de integração, um sistema desktop legado, um terminal de mainframe, um portal externo sem acesso aberto. Nesses casos ela é a única forma viável, e é aí que ela brilha.

Há também o cenário misto, muito comum: você usa RPA agora para destravar o processo e liberar valor rápido, enquanto planeja a integração por API como evolução. Isso é legítimo, desde que a decisão seja consciente e não vire permanente por inércia. Se o dado precisa alimentar relatórios e análises, pensar na camada de dados desde já evita retrabalho, e nossos serviços de engenharia de dados ajudam a estruturar esse caminho.

RPA é frágil por natureza, e assumir isso desde o começo evita retrabalho#

Aqui vai a parte que muito fornecedor não conta. A RPA de tela é estruturalmente frágil, e isso não é um defeito de implementação, é uma consequência de como ela funciona. Como o robô depende da interface visual do sistema alvo, qualquer mudança nessa interface pode quebrá-lo:

• Uma atualização de versão que muda o layout da tela.
• Um botão que trocou de lugar ou de nome.
• Um campo novo que apareceu no meio do formulário.
• Uma janela de pop-up ou aviso que não existia antes.
• Uma mudança de resolução ou de idioma da máquina.

Nenhuma dessas mudanças quebraria uma integração por API, porque a API não depende de onde o botão está na tela. A RPA depende. Por isso, trate RPA como solução de transição, não como arquitetura definitiva de um processo crítico. Se um fluxo de desktop é o único elo entre dois sistemas essenciais e ninguém está monitorando, é questão de tempo até ele falhar silenciosamente.

Isso não invalida a RPA, apenas define como usá-la bem:

• Isole o trecho de tela num único ponto do processo, para que só ele precise de manutenção quando o sistema mudar.
• Monitore ativamente as execuções, com alerta para falha, principalmente no modo não atendido.
• Documente os seletores e a lógica, para que a manutenção não dependa de uma só pessoa.
• Reavalie periodicamente se já surgiu uma API que permita aposentar o robô.
• Use conta de serviço dedicada, com dono documentado, e não a credencial pessoal de um funcionário que pode sair da empresa.

RPA bem governada é uma ponte confiável enquanto ela precisa existir. RPA tratada como solução mágica e esquecida em produção é uma dívida técnica esperando o momento de aparecer.

Perguntas frequentes#

O Power Automate Desktop é gratuito? Existe uma versão do Power Automate Desktop disponível para uso individual no Windows, o que permite construir e rodar fluxos atendidos na própria máquina. O uso corporativo com execução não atendida, orquestração por fluxos de nuvem e governança central envolve licenciamento específico. O correto é dimensionar a licença conforme o modo de execução e o volume, não pela ferramenta em si.

Qual a diferença entre RPA e fluxo de nuvem no Power Automate? Fluxo de nuvem integra sistemas que têm API ou conector, conversando com eles de forma estruturada. RPA, o fluxo de desktop, simula clique e digitação na interface, para sistemas que não oferecem essa porta de entrada. Um mesmo processo pode usar os dois: a nuvem orquestra e o desktop executa a parte que só existe na tela.

Posso disparar um robô de RPA automaticamente, sem ninguém iniciar? Sim. No modo não atendido, um fluxo de nuvem aciona o fluxo de desktop por agendamento ou por um evento, e o robô roda sozinho numa máquina dedicada. Isso exige licença de execução não assistida e infraestrutura sempre disponível, além de monitoramento, já que não há humano na frente da tela para corrigir um imprevisto.

RPA substitui a integração por API? Não deve substituir quando a API existe. A API é mais estável, mais rápida e mais barata de manter. A RPA é a resposta certa quando não há API disponível, em sistemas legados, telas antigas ou portais de terceiros fechados. Use RPA por necessidade, não por atalho.

Por que dizem que RPA quebra fácil? Porque ela depende da interface visual do sistema alvo. Uma atualização de versão, um botão que mudou de lugar ou um pop-up novo podem quebrar o robô, coisas que não afetariam uma integração por API. Isso é inerente ao modelo, e o jeito de conviver com ele é isolar o trecho de tela, monitorar as execuções e planejar a saída para uma API quando ela existir.

Preciso de uma ferramenta como UiPath ou o Power Automate Desktop dá conta? Em muitos cenários corporativos o Power Automate Desktop dá conta, principalmente quando o volume de robôs de tela é moderado e boa parte do processo já pode rodar por API na nuvem. Para automação de tela em larga escala, com orquestração muito complexa de muitos robôs, uma ferramenta dedicada ainda pode ser mais robusta. A escolha depende do volume, da criticidade e do quanto o processo realmente depende de tela.

Em resumo#

RPA com Power Automate Desktop é a ferramenta certa para automatizar tarefas em telas e sistemas legados que não têm API, usando a interface como porta de entrada. Comece no modo atendido para validar, migre para o não atendido quando o volume justificar, e use um fluxo de nuvem para orquestrar e disparar o robô com governança. Acima de tudo, seja honesto sobre a fragilidade: quando existe API, prefira a API, e trate a RPA como uma ponte de transição bem monitorada, não como arquitetura eterna de um processo crítico.

Se sua empresa tem processos presos a sistemas legados e quer descobrir onde a RPA faz sentido e onde a integração por API é o caminho, fale com a gente.