Power Automate: Gerenciando aprovações em vários sistemas
O Power Automate tem um ótimo mecanismo de aprovação acessível no portal do Power Automate, no aplicativo Power Automate Mobile, no Microsoft Teams e no seu cliente de email favorito. Contudo, há momentos em que você pode querer fornecer aprovações em outro sistema enquanto mantém as aprovações do Power Automate atualizadas.
Assim, considere o cenário em que você tem um aplicativo (Power App, lista do SharePoint ou qualquer outro aplicativo para esse assunto) que gera aprovações e você pode querer que os aprovadores entrem nesse aplicativo para fornecer aprovações, além de permitir que eles façam a aprovação como parte da Power Automate. Então, vamos supor o SharePoint usado como armazenamento de dados neste cenário.
Nesse cenário, o fluxo configurado para atualizar a lista do SharePoint com o status de aprovação para que o aprovador possa ver dentro do aplicativo qual foi o resultado. Mas se o usuário aprovar o item na lista do SharePoint, não haverá atualização no fluxo de trabalho. O usuário (ou outro aprovador) ainda pode acionar a aprovação no Outlook, Teams ou Power Automate. Isso resultaria em várias aprovações para o mesmo evento. Nada de bom!
Processo de aprovação
Uma maneira de contornar isso é usar as ações Criar e aprovação e Aguardar uma aprovação. Existem algumas diferenças importantes que são necessárias no processo.
- Criar uma aprovação é usado para iniciar a aprovação
- O ID de aprovação precisa armazenar em algum lugar (por exemplo, lista do SharePoint)
- Um segundo fluxo de trabalho é necessário para aguardar a conclusão da aprovação usando o ID de aprovação capturado na etapa 2
- Outro fluxo de trabalho é necessário para capturar o evento da aprovação acontecendo no aplicativo para cancelar o processo de aprovação
Vejamos a solução com mais detalhes. No cenário abaixo, estou usando uma lista do SharePoint como meu armazenamento para as aprovações. Tudo o que realmente me importa é o ID de aprovação.
Iniciando a aprovação
Conforme mencionado nas etapas 1 e 2, o processo começa invocando uma ação Criar uma aprovação e armazenando a ID de aprovação resultante em uma fonte de dados.
Portanto, nesse caso, a fonte de dados é a lista do SharePoint.
Esperando aprovação
Depois da aprovação iniciada e o ID de aprovação conhecido, ele utiliza para aguardar a aprovação. Para simplificar, vamos usar um fluxo de trabalho acionado pela própria criação do item do SharePoint (etapa 3).
Esse fluxo de trabalho executa por até 30 dias e atualizará o item do SharePoint com o status depois de concluído. Portnato, até agora, a solução não é muito diferente do Iniciar e aguardar uma abordagem de aprovação . O próximo fluxo é onde as coisas ficam mais interessantes.
Cancelar um evento
Conforme mencionado na etapa 4, outro fluxo de trabalho é necessário para capturar a aprovação fora do fluxo de trabalho do Power Automate e cancelar a própria solicitação para evitar a duplicação de aprovações. Internamente, os dados de aprovação são armazenados dentro do Dataverse na tabela Aprovações. Conhecendo o Row ID (Approval ID), o status da aprovação pode ser alterado sem interagir diretamente com a solicitação de aprovação. Portanto, neste fluxo de trabalho, é importante não apenas marcar o status de aprovação na lista do SharePoint, mas também usar a ação Atualizar uma linha do Dataverse para alterar o Estágio, Motivo do Status e Status da solicitação de aprovação.
Então, depois da ação concluída e um aprovador tentar invocar uma aprovação, a mensagem altera para mostrar o estágio com base nessa atualização.
Conclusão
A solução fornecida neste artigo é uma abordagem alternativa para lidar com aprovações do Power Automate que podem precisar ocorrer em vários sistemas. Veja tambem nosso outro artigo sobre como e por onde começar a usar o Microsoft Power Automate.
Luiz Antonio Sgargeta é sócio fundador e CEO da Trinapse, consultoria brasileira de Microsoft 365 com quase duas décadas de operação, acumula mais de 20 anos em desenvolvimento de software e em ambientes corporativos de alta complexidade.
Ver maisVer menos
Trabalha com SharePoint desde o SharePoint Portal Server 2003 e com .NET desde a versão 1.0. Acompanhou a plataforma em todas as suas reinvenções, do portal de documentos on-premises ao SharePoint Online dentro do Microsoft 365, o que dá a ele uma leitura rara sobre o que muda de verdade e o que é apenas nome novo para o mesmo problema.
No início da carreira atuou em uma das maiores operações de e-commerce do país, em sistemas que não toleram degradação de performance nem indisponibilidade, essa origem definiu o critério que ele aplica até hoje: solução boa é a que sustenta volume real, integra com o legado que já existe e não quebra no pico.
Depois disso, passou por praticamente todo tipo de projeto corporativo, de portais e intranets de milhares de usuários a integrações críticas e automação de processos de ponta a ponta, sempre em grandes empresas e em desafios de alta exigência.
A marca do trabalho dele é a tradução entre tecnologia e negócio, levanta a necessidade real por trás do pedido do cliente, questiona o processo antes de automatizá-lo e desenha a solução pelo resultado esperado, não pela ferramenta disponível, é o que permite conversar com a diretoria sobre retorno e com o time técnico sobre arquitetura na mesma reunião.
Hoje lidera a frente comercial e estratégica da Trinapse e conduz a empresa no novo ciclo da inteligência artificial, com foco em agentes de IA e operação de processos assistida por IA para cooperativas de crédito, agronegócio e indústria. Escreve no blog da Trinapse desde 2019, com mais de 450 artigos sobre IA, SharePoint, Power Platform, Modern Workplace e transformação de processos, sempre a partir de projeto entregue e não de teoria.
