7 erros que derrubam fluxos do Power Automate em produção (e como tratar erro de verdade)

Em uma distribuidora com 900 funcionários, o fluxo que levava pedidos aprovados de uma lista do SharePoint para o ERP parou em uma sexta-feira. Ninguém percebeu até a terça seguinte, quando o comercial ligou perguntando por 140 pedidos. A causa: a conexão do SharePoint estava no nome de um analista desligado em dezembro, e a TI desativou a conta. O fluxo não tinha dono, não avisava ninguém quando falhava e não estava em solução. Levou um dia para achar e dez minutos para corrigir.

Eu já atendi esse telefonema em empresas de serviços e de indústria, e a história muda pouco. Os sete erros abaixo respondem por quase todos os incidentes que a gente encontra em fluxos de produção. Para cada um: sintoma, causa e correção.

Os sete erros

1. Conexão no nome de uma pessoa

Sintoma: o fluxo roda por meses e para quando alguém sai da empresa, troca de senha ou perde a licença. Causa: toda ação usa uma conexão, e a conexão é autenticada com a conta de quem a criou. Quando essa conta é desativada, as conexões quebram e o fluxo é desligado. Correção: uma conta de serviço (algo como automacao@suaempresa.com.br) com licença própria, MFA por acesso condicional, conexões criadas por ela e dois coproprietários humanos no fluxo. Em fluxos instantâneos que outras pessoas disparam, use "usuários somente execução" com a conexão fornecida pelo fluxo.

2. Sem tratamento de erro

Sintoma: uma ação falha, a execução fica vermelha no histórico e ninguém olha o histórico. O e-mail de falha vai para o proprietário, que criou uma regra para arquivá-lo. Causa: o fluxo foi construído em linha reta, sem caminho para a falha. Correção: Try, Catch e Finally com escopos (seção abaixo), aviso em canal do Teams com o link da execução e um status de erro gravado no item de origem, para que quem pediu também veja que algo travou.

3. Loop sem limite e simultaneidade sem decisão

Sintoma: fluxo que leva três horas, contagem errada no fim, item processado duas vezes. Causa: o Apply to each roda até 20 iterações em paralelo por padrão, e Set variable dentro dele devolve número errado. O Do until sem condição de saída confiável roda até o limite padrão (60 voltas ou 1 hora) e falha. Um gatilho sem controle de simultaneidade abre duas execuções para o mesmo item quando ele é salvo duas vezes seguidas. Correção: filtre na fonte com a consulta de filtro (OData) em vez de uma condição dentro do loop; use Selecionar e Unir no lugar de variável acumuladora; ligue o controle de simultaneidade do gatilho em 1 quando a ordem importa; dê ao Do until um contador e um limite explícito.

4. Gatilho que dispara a si mesmo

Sintoma: centenas de execuções para o mesmo item, consumo de requisições fora da curva e o item com "Modificado por" igual à conta do fluxo. Causa: o gatilho "Quando um item é criado ou modificado" e a ação "Atualizar item" no mesmo fluxo, sobre a mesma lista. Correção: uma condição de gatilho (em Configurações do gatilho, Condições de gatilho) que ignora alterações feitas pela própria conta, como @not(equals(triggerOutputs()?['body/Editor/Email'], 'automacao@suaempresa.com.br')), ou uma coluna de controle (Processado, do tipo Sim/Não) que o fluxo marca no fim e verifica no início. Para saber qual coluna mudou, a ação "Obter alterações de um item ou arquivo (somente propriedades)" compara versões.

5. Throttling (429) sem repetição

Sintoma: erro 429 Too Many Requests ou "Rate limit is exceeded. Try again in N seconds" em dias de pico, e fluxos lentos sem motivo aparente. Causa: dois limites diferentes. O da Power Platform conta requisições por licença em 24 horas: 6.000 com a licença do Microsoft 365, 40.000 por usuário com Premium e 250.000 com Process, em novembro de 2026, com o limite aplicado por fluxo durante o período de transição. O do conector vale por conexão: o do SharePoint, por exemplo, é de 600 chamadas por minuto. Um loop com três ações sobre 2.000 itens faz 6.000 chamadas. Correção: ajuste a política de repetição da ação (a padrão tenta 4 vezes em intervalo crescente; para sistemas que limitam com frequência, use intervalo exponencial com mais tentativas); reduza chamadas filtrando na fonte, paginando e usando Selecionar em vez de loop; baixe a simultaneidade do loop; mova o fluxo pesado para uma conta com Premium ou atribua uma licença Process.

6. Dado nulo e tipo errado

Sintoma: "InvalidTemplate. Unable to process template language expressions", "The value must be of type integer", data gravada com três horas de diferença ou como texto. Causa: campo opcional vazio, número que chegou como texto do Forms, data em UTC no formato ISO sendo gravada sem conversão. Correção: o operador ? em todo acesso a propriedade, coalesce para valor padrão, int(trim(...)) ou float para números, formatDateTime e convertTimeZone para datas, e Parse JSON com esquema em que os campos que podem vir vazios aceitam null. O post sobre expressões essenciais do Power Automate mostra cada uma delas com exemplo.

7. Fora de solução, sem teste e sem dono

Sintoma: ninguém sabe o que o fluxo faz, alguém editou direto em produção e quebrou, a cópia do fluxo aponta para a lista errada. Causa: o fluxo nasceu em "Meus fluxos", no ambiente padrão, e cresceu ali. Correção: solução com referências de conexão e variáveis de ambiente (URL do site, nome da lista, e-mail do canal), ambientes de desenvolvimento, teste e produção, dono e suplente anotados na descrição do fluxo e um padrão de nome (área, processo, gatilho). A base disso está em governança na Power Platform.

Como tratar erro de verdade: Try, Catch e Finally

O try/catch no Power Automate se monta com duas peças. A primeira é o Escopo (Scope), uma ação que agrupa outras ações. A segunda é a opção Configurar executar após, que define em que situação uma ação roda em relação à anterior: bem-sucedida, falhou, ignorada ou expirou. Por padrão, só "bem-sucedida" está marcada, e por isso um fluxo em linha reta para na primeira falha.

O padrão tem três escopos. O Try contém o trabalho de verdade. O Catch roda após o Try com "falhou" e "expirou" marcados, e é onde você descobre o que quebrou e avisa alguém. O Finally roda após o Catch com os quatro estados marcados, e serve para o que precisa acontecer sempre, como gravar o status final no item.

Gatilho: Quando um item é criado (SharePoint)

Escopo: Try
  Obter linha (Dataverse)
  Enviar e-mail (Office 365 Outlook)
  Atualizar item (SharePoint)

Escopo: Catch
  Configurar executar após Try: falhou, expirou
  Filtrar matriz: result('Try') onde status = Failed
  Compor: nome da ação e mensagem de erro
  Postar mensagem em um chat ou canal (Teams)
  Atualizar item: Status = "Erro"

Escopo: Finally
  Configurar executar após Catch: bem-sucedida, falhou, ignorada, expirou
  Atualizar item: DataProcessamento = utcNow()

A função result('Try') devolve uma matriz com o resultado de cada ação de primeiro nível do escopo: nome, status, horário de início e fim e, quando houve falha, o objeto error com código e mensagem. Filtrar essa matriz por status Failed dá exatamente a ação que quebrou, sem precisar abrir a execução. As expressões abaixo são as que uso no Catch.

// Filtrar matriz: campo De
result('Try')

// Filtrar matriz: condição, no modo avançado
@equals(item()?['status'], 'Failed')

// Compor: ação que falhou e mensagem de erro
concat(
  first(body('Filtrar_matriz'))?['name'], ': ',
  first(body('Filtrar_matriz'))?['error']?['message']
)

// Link direto para a execução, no corpo do aviso
concat('https://make.powerautomate.com/environments/',
  workflow()?['tags']?['environmentName'],
  '/flows/', workflow()?['name'],
  '/runs/', workflow()?['run']?['name'])

// Valor padrão quando o gatilho vem sem e-mail
coalesce(triggerOutputs()?['body/Email'], 'sem e-mail')

Diagnóstico quando o fluxo já caiu

Antes de publicar

O próximo passo prático é listar os cinco fluxos dos quais a empresa mais depende e passar cada um pelo checklist acima. Em geral, dois ou três falham no primeiro item. Se o seu fluxo de aprovação está nessa lista, o post sobre fluxo de aprovação no Power Automate mostra como montá-lo com registro de quem aprovou e prazo. Se preferir que a gente faça essa revisão com o seu time, a consultoria em Power Automate no fim desta página é o caminho.