Tratamento de erro no Power Automate: avise antes do usuário

Em resumo

• O padrão tem três escopos: Tentar guarda as ações do processo, Capturar roda só depois de falha ou tempo esgotado e avisa o dono, e Finalizar decide o status final da execução.
• O aviso leva o nome da ação que falhou, a mensagem de erro e o link direto da execução, montado dentro do próprio fluxo com a função workflow().
• A variável de controle precisa ser inicializada no nível raiz, antes dos escopos, porque o Power Automate não deixa inicializar variável dentro de escopo.
• Um fluxo que trata o erro e termina com sucesso esconde a falha do histórico, então o Finalizar encerra com a ação Terminar em status Falhou.
• Depois de validado em um fluxo, o Capturar vira um fluxo filho reutilizável, e os demais fluxos que a TI sustenta só chamam esse filho.

Como fazer o tratamento de erro no Power Automate para saber da falha antes do usuário?

Envolva as ações do processo num escopo chamado Tentar, crie um segundo escopo, o Capturar, que só roda quando o primeiro falha ou estoura o tempo, e use o Capturar para avisar o dono do processo com o link da execução, deixando o status final para um terceiro escopo, o Finalizar. Tudo se monta no designer de fluxos de nuvem com ações nativas, serve para qualquer fluxo que a TI herdou de outra área e passa a ser necessário no dia em que a falha só aparece porque alguém ligou.

Pense no fluxo de cadastro de associado de uma cooperativa de crédito: a agência preenche o formulário, o fluxo grava o item numa lista do SharePoint e dispara as etapas seguintes, e tudo funciona até alguém da área de cadastro renomear ou recriar uma coluna da lista. Renomear só o título de exibição costuma preservar o nome interno, mas recriar a coluna muda esse nome, e o fluxo passa a apontar para um campo que não existe mais. A execução falha no meio da tarde, ninguém abre o histórico, e a TI descobre quando o gerente da agência liga perguntando por que o associado novo não aparece no sistema, com a fila de atendimento já formada.

O desenho segue o padrão try, catch, finally das linguagens de programação, que a página de diretrizes de tratamento de erro do Microsoft Learn trata com escopos e a configuração de executar após. O que este texto acrescenta é a versão de quem sustenta fluxo alheio: escopo no lugar da ação única, variável inicializada no lugar certo, status final decidido de propósito e um Capturar que sobe para um fluxo filho. Tudo o que aparece aqui está em disponibilidade geral, sem recurso em preview.

Pré-requisitos

Antes de abrir o designer, confira os itens abaixo, porque o passo 8 (fluxo filho) é o único que muda de exigência em relação ao fluxo simples, e é melhor descobrir isso agora do que no meio da montagem, quando o ambiente já estiver aberto e o fluxo pela metade.

• Fluxo de nuvem existente, no qual você seja proprietário ou coproprietário, para poder editar. O Capturar é montado dentro do fluxo que já roda.
• Licença: escopo, Compor, Filtrar matriz, variáveis e Terminar são ações nativas, e SharePoint e Office 365 Outlook são conectores padrão. Para o fluxo filho, confira o FAQ de licenciamento do Power Platform para o ambiente onde a solução vai viver.
• Solução: fluxo filho só funciona com fluxos dentro de solução, e a página de fluxos filho do Microsoft Learn lista as exigências de gatilho, ação de resposta e conexão.
• Conexão de envio do aviso que não dependa da mesma conta que o fluxo usa para o SharePoint, de preferência uma caixa compartilhada ou conta de serviço da TI, por um motivo que aparece na seção de erros.
• E-mail do dono do processo, que é quem vai receber o aviso. Quem aprova o fluxo na área de negócio costuma ser outra pessoa, e o aviso precisa chegar a quem consegue agir.

Os nomes de menu abaixo seguem a interface em português do designer atual, em que o painel de configuração da ação abre à direita, então quem estiver no designer clássico ou em outro idioma pode encontrar o rótulo um pouco diferente. Mesmo assim, a lógica de cada passo é a mesma, e por isso basta procurar a opção equivalente no seu ambiente.

Passo a passo

A sequência tem oito passos, e os sete primeiros bastam para o padrão funcionar num fluxo isolado, porque tudo o que ele precisa está dentro do próprio fluxo. O oitavo transforma o Capturar em peça reutilizável, e é ele que faz o padrão valer para todos os fluxos que a TI sustenta, já que o aviso passa a ficar num lugar só.

A variável fica fora dos escopos e o Finalizar roda nos quatro estados do Capturar, senão a execução termina sem decidir o status.

1. Inicialize a variável de controle fora de qualquer escopo

No topo do fluxo, logo abaixo do gatilho, adicione Variável > Inicializar variável, com nome varFalhou, tipo Booliano e valor false. Adicione também duas ações Compor, uma chamada "Nome do processo", com o texto do processo (por exemplo, Cadastro de associado), e outra chamada "Dono do processo", com o e-mail de quem recebe o aviso. Em fluxo dentro de solução, vale trocar esse e-mail por uma variável de ambiente, para mudar o destinatário sem editar o fluxo.

A posição importa porque o Power Automate não permite inicializar variável dentro de um escopo, e a documentação de variáveis trata a inicialização como ação de nível raiz. Muita cópia do padrão que circula por aí inicializa a variável dentro do Capturar, e o resultado é um fluxo que sempre avisa falha, porque a variável é criada já verdadeira. Aqui ela nasce falsa, antes de tudo, e só o Capturar muda o valor.

2. Crie o escopo Tentar e mova as ações do processo para dentro

Clique no + abaixo das ações de preparação, escolha Controle > Escopo e renomeie para Tentar, para que o escopo reúna tudo o que pode falhar no cadastro. Arraste para dentro dele todas as ações do cadastro: criar o item na lista do SharePoint, atualizar o status, notificar a agência, o que houver, e deixe de fora o gatilho e as ações do passo 1, que precisam continuar no nível raiz.

O motivo de usar escopo em vez de olhar ação por ação é que o escopo termina com falha se qualquer ação interna falhar, o que dá ao Capturar um único ponto para observar, como a página de diretrizes do Microsoft Learn descreve. Quando o fluxo cresce e ganha ação nova dentro do Tentar, a proteção cresce junto, sem mexer em configuração nenhuma.

3. Crie o escopo Capturar e configure o executar após

Adicione outro escopo abaixo do Tentar, renomeie para Capturar, selecione-o e abra a aba Configurações no painel da direita. Na seção Executar após, expanda Tentar e deixe marcados apenas falhou e tempo esgotado, desmarcando foi bem-sucedido e foi ignorado, e lembre que a configuração vai no escopo e não nas ações de dentro dele.

Ignore as capturas de tela de tutoriais antigos, porque no designer clássico o caminho era os três pontos da ação e Configurar executar após, e o lugar mudou no designer novo. O tempo esgotado precisa estar marcado porque ação que expira, como uma aprovação sem resposta ou uma chamada HTTP que demora, termina nesse status e não em falha, e sem essa marca o Capturar fica parado enquanto o processo trava. Se sobrar foi bem-sucedido marcado, o aviso sai em toda execução, e o dono do processo aprende a ignorar o e-mail.

4. Dentro do Capturar, monte o endereço da execução

Dentro do Capturar, adicione uma ação Compor chamada "URL da execução", abra a aba Expressão do campo e cole o trecho abaixo, que usa a função workflow(), descrita na referência de funções da linguagem de definição de fluxo. Com ela, o aviso leva quem o recebe direto à execução que falhou, sem que ninguém precise procurar no histórico.

concat(
  'https://make.powerautomate.com/environments/',
  workflow()?['tags']?['environmentName'],
  '/flows/',
  workflow()?['name'],
  '/runs/',
  workflow()?['run']?['name']
)

A função devolve os dados do próprio fluxo em execução, e o texto monta o endereço com três pedaços: o identificador do ambiente, o do fluxo e o da execução. O formato é o mesmo que Devaney usa e que um leitor dele propôs com o prefixo do ambiente, e eu o testei apenas como padrão de campo, então valide no seu tenant antes de replicar. Em fluxo dentro de solução, se o link abrir uma página de fluxo não encontrado, troque workflow()?['name'] por workflow()?['tags']?['xrmWorkflowId'] e teste de novo.

5. Descubra qual ação falhou e por quê

Ainda no Capturar, adicione Operações de dados > Filtrar matriz, chamada "Filtrar falhas", e no campo De use a expressão result('Tentar'), que devolve o resultado de cada ação de primeiro nível do escopo. Depois alterne a condição para o modo avançado e use este filtro:

@or(
  equals(item()?['status'], 'Failed'),
  equals(item()?['status'], 'TimedOut')
)

Em seguida, crie duas ações Compor, "Ação com falha" e "Mensagem de erro", com as expressões abaixo, porque assim o aviso diz o que quebrou e por quê. O coalesce evita que o aviso saia vazio quando a plataforma não devolve mensagem, o que acontece com tempo esgotado.

coalesce(first(body('Filtrar_falhas'))?['name'], 'Não identificada')

coalesce(first(body('Filtrar_falhas'))?['error']?['message'], 'A plataforma não devolveu mensagem de erro para esta ação.')

A pegadinha está nas ações compostas: quando o erro acontece dentro de uma condição ou de um aplicar a cada, o resultado de primeiro nível mostra a condição ou o laço como ação com falha, com a mensagem genérica "An action failed. No dependent actions succeeded.", e não a ação interna que de fato quebrou. O aviso ainda diz em qual bloco olhar, e o link da execução leva direto ao detalhe da iteração, mas se o bloco é grande vale dar nome claro a ele e, nos pontos críticos, deixar o corpo do laço num escopo próprio, para o nome aparecer na leitura do histórico.

6. Marque a falha e envie o aviso ao dono do processo

Dentro do Capturar, adicione Variável > Definir variável, com varFalhou igual à expressão true. Definir variável é permitido dentro de escopo, ao contrário de inicializar. Depois adicione Office 365 Outlook > Enviar um email (V2), com o dono do processo em Para, o assunto com o nome do processo e a palavra falha, e o corpo em HTML, no modo código (botão </>) da caixa de texto.

<p>O fluxo <strong>{Nome do processo}</strong> falhou na ação <strong>{Ação com falha}</strong>.</p>
<p>Mensagem da plataforma: {Mensagem de erro}</p>
<p><a href="{URL da execução}">Abrir a execução que falhou</a></p>

Os trechos entre chaves são as saídas dos quatro Compor, inseridas pelo seletor de conteúdo dinâmico, e não texto digitado. O link vai no corpo, e não só como texto solto, porque quem recebe o aviso na agência ou na área de cadastro precisa de um clique até a execução, sem procurar o fluxo pelo nome numa lista longa.

7. Crie o escopo Finalizar e decida o status final

Adicione um terceiro escopo abaixo do Capturar, renomeie para Finalizar e, na aba Configurações > Executar após, marque os quatro estados do Capturar: foi bem-sucedido, falhou, foi ignorado e tempo esgotado. Dentro dele, coloque uma Condição em que varFalhou seja igual à expressão true, usando a expressão e não o texto, para comparar booliano com booliano. No ramo Sim, adicione Controle > Terminar, com status Falhou, um código como FalhaNoCadastro e a mensagem apontando para a saída "Mensagem de erro". O ramo Não fica vazio.

O quarto estado marcado é o que mantém o Finalizar rodando também quando o Tentar dá certo e o Capturar fica ignorado, que é o caso de quase todas as execuções. A decisão de status merece cuidado porque o fluxo que trata o erro e termina com sucesso esconde a falha no histórico: o Capturar tratou, a execução fica verde, e quem abrir o histórico, ou qualquer painel que leia o status, não vê nada. Terminar como Falhou mantém o aviso e a verdade do histórico, e é a escolha certa quando a TI quer contar falhas, enquanto terminar como Bem-sucedido só faz sentido quando a falha é esperada e tratada de fato.

8. Transforme o Capturar num fluxo filho reutilizável

Com o padrão validado, crie na mesma solução um fluxo chamado, por exemplo, "Aviso de falha de fluxo", com o gatilho manual e cinco entradas de texto: dono, processo, ação com falha, mensagem e URL da execução. Dentro dele, ponha o Enviar um email (V2) do passo 6, usando as entradas, e a conexão de envio da conta de serviço da TI. No fluxo de origem, o Capturar passa a ter só os Compor dos passos 4 e 5, o Definir variável e a ação Executar um Fluxo Filho apontando para esse aviso. As exigências de gatilho, ação de resposta e conexão estão na página de fluxos filho, e a lógica de funções reutilizáveis aparece em detalhe no artigo Como criar funções reutilizáveis no Power Automate, aqui no blog.

A armadilha está na URL: dentro do fluxo filho, workflow() devolve os dados do filho, e não os do fluxo que o chamou, então o endereço da execução precisa ser montado no fluxo de origem e passado como entrada. O ganho aparece na sustentação, porque o texto do e-mail, o destino e a conexão ficam num lugar só, e trocar o aviso de e-mail para uma mensagem no Teams deixa de ser uma edição em dezenas de fluxos.

Como validar que deu certo

No fim do Tentar, adicione temporariamente uma ação Compor com a expressão div(1,0), que sempre falha, e rode o fluxo. No histórico de execuções, a execução deve aparecer com status Falhou, o Tentar com falha, o Capturar bem-sucedido e o Finalizar com o ramo Sim executado e a ação Terminar em vermelho. O dono do processo deve receber o e-mail com o nome da ação, a mensagem e o link, e o clique no link deve abrir exatamente a execução do teste, não a lista de execuções do fluxo.

Remova o Compor de teste e rode de novo: a execução deve terminar com status Bem-sucedido, o Capturar deve aparecer como ignorado e nenhum e-mail deve sair. Faça um último teste com falha real, em cópia do fluxo, recriando uma coluna da lista com o mesmo nome, porque é esse tipo de quebra que a TI quer pegar, e confirme que o aviso chega antes de qualquer ligação da agência.

Erros comuns

Um limite que o padrão não resolve: se o gatilho falha, o fluxo nem começa a rodar, e então nenhum escopo existe para capturar nada. Por isso a falha de gatilho continua dependendo do e-mail padrão da plataforma ou do monitoramento do ambiente.

Quando não usar este padrão

Num fluxo pessoal e trivial, como o que copia um anexo para a pasta de quem o criou, o escopo extra é peso sem retorno, porque o dono já olha o histórico e o custo de uma falha é baixo. O padrão também não é o caminho quando a necessidade é monitorar dezenas de fluxos de uma vez, porque aí você acabaria copiando o mesmo Capturar em cada um para ter um retrato geral que ele não dá. Nesse caso, o ponto de partida é o Centro de Automação, que lê o histórico de execuções do ambiente, e o Capturar fica para os fluxos críticos, em que o aviso tem de chegar a uma pessoa específica na hora.

O que levar para quem aprova

Depois de pronto, a TI passa a saber da falha de cada fluxo crítico no momento em que ela acontece, com o nome da ação e o link da execução, e o histórico continua mostrando a falha como falha, porque o Finalizar termina em status Falhou, o que mantém os relatórios do ambiente honestos.

O padrão usa ações nativas e conectores padrão, então não pede licença nova para o fluxo simples, só que o fluxo filho exige solução, e por isso o gerente de TI deve confirmar a licença para o ambiente. A sustentação, por sua vez, se resume a manter um único fluxo de aviso com uma conta de serviço da TI.

O risco fica sob controle da TI porque o texto, o destino e a conexão do aviso ficam num lugar só, e por isso o fornecedor ou o analista que montou o padrão pode sair sem levar o conhecimento junto, já que quem assumir encontra tudo num único fluxo.

Se ajudar na conversa interna, a Trinapse pode montar com vocês o modelo da solução com o fluxo filho e o checklist para encaixar o padrão nos fluxos que a TI já herdou, de modo que a proposta chegue à reunião com algo concreto na mão.