O fluxo de aprovação de compras encaminha uma solicitação aos responsáveis definidos pela empresa e registra a decisão antes de autorizar o pedido. Para automatizá-lo, defina alçadas, substitutos, prazos e tratamento de recusas; vincule a autorização à versão e ao valor analisados. A retomada de uma automação não comprova aprovação, e o registro no sistema de gestão exige uma conferência final.
Sua empresa precisa saber quem pode decidir sobre cada compra, inclusive quando o responsável está ausente. O ponto de partida não é escolher um canal de notificação: é definir qual decisão permite avançar e em quais condições ela perde a validade. O modelo abaixo orienta esse desenho, sem executar pagamentos nem pressupor integração pronta com qualquer sistema.
O que definir no fluxo de aprovação de compras
Comece pela política de decisão. Neste guia, alçada significa o limite e as condições de autoridade que a empresa atribui a um responsável. Os valores e as exceções devem vir dessa política, não de uma tabela genérica encontrada na internet.
Solicitação e documentação mínima
Como proposta de desenho, organize a entrada com os seguintes campos:
- Identificador e versão da solicitação.
- Solicitante, justificativa e descrição dos itens com quantidades.
- Valor total, moeda e centro de custo.
- Anexos pertinentes à análise.
- Prazo para decisão e responsável pelo acompanhamento.
Defina quais documentos são necessários para cada situação. Se faltar informação essencial, mantenha o pedido pendente de dados, em vez de encaminhá-lo como se estivesse completo.
Quem solicita, quem decide e quem acompanha
Separe esses papéis no modelo. Receber uma cópia da mensagem não deve conceder autoridade para aprovar. Registre também quem pode substituir o responsável e sob quais condições.
Para organizar a participação das áreas, vale consultar o guia para definir papéis e responsabilidades. Essa distribuição ajuda a esclarecer o trabalho, mas não substitui a política de autoridade financeira.
Como montar a matriz de alçadas e substitutos
O valor não precisa ser o único critério de encaminhamento. A documentação de cadastro de fluxo da Consistem descreve centros de custo, famílias de produtos e perfis de aprovador para autorizar solicitações ou pedidos. É um exemplo de critérios possíveis, não uma comprovação de integração externa disponível.
Use a matriz abaixo como modelo conceitual. Preencha limites, pessoas e prazos com a política aprovada da sua empresa.
| Condição de valor e centro de custo | Papel aprovador | Regra de decisão | Substituto autorizado | Prazo e vencimento |
|---|---|---|---|---|
| Dentro da alçada do gestor do centro de custo | Gestor responsável | Decisão do responsável habilitado | Pessoa formalmente designada | Prazo definido; bloquear ao vencer |
| Acima da alçada do gestor | Gestor e instância adicional prevista | Aprovações exigidas pela política | Substitutos de cada papel | Prazo por etapa; encaminhar exceção |
| Responsável ausente | Substituto com autoridade aplicável | Mesma regra exigida para a solicitação | Designação registrada | Reatribuição conforme política |
| Sem regra aplicável | Responsável pela definição da exceção | Não liberar automaticamente | Não presumir substituto | Bloquear e encaminhar para análise manual |
Sequência, paralelismo e primeira resposta
No desenho do processo, separe a ordem de acionamento da condição de conclusão. Você pode propor etapas em sequência, quando uma depende da anterior, ou em paralelo, quando as análises podem começar juntas. Isso não define se todos precisam concordar.
No Power Automate, a documentação dos tipos de aprovação esclarece a diferença: “Everyone must approve” aguarda todos aprovarem ou uma recusa; “First to respond” encerra a solicitação na primeira decisão, positiva ou negativa.
Título
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Como regra de projeto, aceite a primeira resposta apenas se os integrantes tiverem autoridade equivalente para aquela decisão. Se a política exigir concordância de áreas distintas, não use esse atalho. Depois de encerrar a espera, confira o resultado antes de permitir qualquer registro.
Como tratar recusa, expiração e reenvio
Proponha estados explícitos: recebida, pendente de dados, em aprovação, recusada, expirada, cancelada, aprovada e registrada no destino. Eles são um modelo a implementar, não estados que toda ferramenta oferece automaticamente.
Na recusa, registre o motivo e impeça o avanço para o registro do pedido. Se houver correção e reenvio, preserve o histórico e abra uma rodada identificável. Não apague a decisão anterior para fazer a nova solicitação parecer inédita.
Prazo vencido não é autorização
Defina um prazo de negócio e o que acontece ao vencê-lo: alertar o responsável, encaminhar uma exceção ou acionar um substituto autorizado. Neste modelo, o silêncio não libera a compra.
Bloqueie também respostas tardias dirigidas a uma rodada encerrada. O prazo definido pela empresa precisa ser compatível com os limites técnicos da configuração escolhida; não trate os dois como se fossem a mesma coisa.
A Microsoft documenta aprovações que permanecem na central mesmo sem um fluxo aguardando resposta. Por isso, a proposta é conferir o estado efetivo do processo, não apenas a presença de uma solicitação na interface.
Mudança de valor exige reavaliar a autorização
Considere um exemplo hipotético: o gestor aprova uma solicitação, mas o valor total é alterado antes do envio ao sistema de gestão. A decisão original se refere ao conteúdo que ele analisou, não ao novo valor.
Como política de controle proposta, crie uma nova versão, invalide a autorização anterior para envio e recalcule as alçadas. Faça nova avaliação também quando mudar outro campo relevante para a decisão. Esse comportamento precisa ser implementado e validado; não é uma capacidade universal dos produtos citados.
Power Automate e n8n: o que cada recurso comprova
A escolha técnica deve considerar os controles necessários, além do envio de avisos. As documentações comprovam capacidades diferentes, não equivalência de governança.
Capacidade oficial de aprovações
No Power Automate, a ação “Start and wait for an approval” permite informar detalhes, indicar aprovadores e aguardar a resposta. A introdução oficial às aprovações também informa os pré-requisitos: banco do Microsoft Dataverse e licença válida para criar fluxos, com condições de provisionamento e permissões conforme o ambiente.
Isso oferece uma base documentada de decisão humana. Ainda assim, configure as condições que separam aprovação, recusa e outras saídas. Ter e-mail corporativo não comprova, sozinho, que todos os requisitos estão atendidos.
Wait é espera e retomada
No n8n, o nó Wait pausa a execução e pode retomá-la por tempo, chamada HTTP ou envio de formulário. No modo webhook, a URL de retomada é gerada por execução; há opções de autenticação Basic, Header e JWT, além da opção sem autenticação.
A mesma documentação informa que o limite de espera pode retomar a execução automaticamente. Portanto, continuar o fluxo não significa que alguém aprovou a compra. O ramo seguinte precisa conferir decisão, identidade, estado e validade.
Não trate a posse da URL como prova de autoridade. Matriz de alçadas, delegação, regra de concordância e histórico de negócio exigem desenho e validação próprios; o Wait sozinho não comprova esses controles. Para entender o contexto mais amplo dos fluxos, veja o guia de automação de processos com n8n.
O que conferir antes de registrar o pedido
O fluxo conceitual proposto segue esta ordem: receber a solicitação, validar os dados, calcular as alçadas, coletar a decisão, conferir a autorização, registrar no destino e confirmar o resultado. Recusa, expiração e cancelamento ficam fora do caminho de escrita.
Antes de autorizar o registro, confira:
- Identidade e autoridade de quem decidiu, inclusive eventual delegação.
- Resultado positivo conforme todos os aprovadores exigidos.
- Prazo válido e estado ainda apto a avançar.
- Correspondência da versão e do valor atuais com o que foi aprovado.
- Referência única da solicitação e possibilidade de consultar o resultado no destino.
Registre quem decidiu, quando, qual foi a decisão e a justificativa, além da versão e do valor autorizados. Na integração, confirme operações disponíveis, permissões e campos obrigatórios do sistema de gestão.
Se ocorrer erro no envio, mantenha a falha visível sem transformar a decisão humana em recusa. Antes de repetir uma criação, consulte se o pedido já foi registrado usando a referência da solicitação, quando a API permitir. A prevenção de duplicidade depende desse controle e da implementação, não apenas da existência de um conector.
Principais conclusões
- Defina alçadas, responsáveis, substitutos e documentação antes de automatizar o encaminhamento.
- Escolha a regra de concordância separadamente da ordem de acionamento dos aprovadores.
- Bloqueie solicitações vencidas e reavalie alterações de valor em uma nova versão.
- Confira a autorização efetiva antes do registro e consulte o destino antes de repetir uma criação.
Perguntas frequentes
Quem pode aprovar compras na empresa?
No modelo proposto, quem tiver autoridade definida pela política interna para o valor, o centro de custo e as demais condições da solicitação. Receber uma notificação ou acompanhar o processo não deve tornar a pessoa aprovadora.
O que fazer quando o aprovador está ausente?
Acione um substituto formalmente autorizado, mantendo as condições de alçada e de concordância exigidas. Registre a substituição; se não houver regra aplicável, bloqueie o avanço e encaminhe a exceção para análise.
Uma resposta vencida pode liberar o pedido?
Neste desenho, não. A automação deve conferir o prazo e o estado da rodada, mesmo que ainda exista uma mensagem ou tela permitindo responder. Uma resposta tardia não deve reabrir automaticamente uma autorização encerrada.
Uma aprovação continua válida se o valor mudar?
A política recomendada aqui exige nova versão e reavaliação das alçadas antes do envio. Não presuma que a autorização do valor anterior cobre o atual nem que a ferramenta fará essa invalidação sem configuração.
Avalie o destino antes de automatizar o registro
Use a matriz e os estados propostos para alinhar a política de compras com quem vai implementar o fluxo. A autorização precisa chegar ao destino vinculada à solicitação correta, com confirmação do registro e tratamento separado de falhas. O escopo termina no pedido registrado, sem pagamento automático.
Para avaliar o que o sistema de destino precisa oferecer antes de receber um pedido aprovado, veja o guia de integração de sistemas.
