O design de caminhos de exceção ajuda equipes a lidar com solicitações rejeitadas, documentos faltantes e aprovações parciais antes que retrabalho atrase o processo.
A maioria das equipes começa pela versão limpa de um fluxo. Uma solicitação chega, alguém a analisa e ela é aprovada. Parece eficiente, mas esconde onde o trabalho real acontece.
O caminho feliz costuma ser o mais curto. O formulário está completo, os anexos existem e o revisor sabe exatamente o que fazer. Na operação real, raramente é essa a parte que causa atrasos.
Os atrasos começam quando algo está faltando, confuso, atrasado ou apenas parcialmente aceitável. Um gerente pode aprovar o orçamento, mas rejeitar um item. O financeiro pode precisar de um documento fiscal que nunca foi enviado. Um líder de suporte pode devolver a solicitação porque o campo de motivo está vago. Cada um desses momentos cria passos extra, mensagens adicionais e mais espera.
Se essas situações não forem planejadas cedo, as pessoas decidirão na hora. Um revisor envia um e‑mail. Outro deixa um comentário na ferramenta. Um terceiro rejeita a solicitação sem explicar. O solicitante fica sem saber: deve corrigir o problema, começar de novo ou pedir ajuda?
Essa confusão tem um custo. Atrasa quem enviou a solicitação, quem a revisa e qualquer pessoa chamada para explicar o que aconteceu. Um fluxo que parecia simples no quadro branco vira conversas de acompanhamento, envios duplicados e repasses manuais.
Um fluxo básico de aprovação é fácil de desenhar:
A versão real é mais difícil. E se um documento estiver faltando? E se apenas parte da solicitação for aprovada? E se o revisor rejeitar, mas o usuário puder corrigir? Esses não são casos incomuns. Para muitas equipes, são os casos normais.
Por isso o design de caminhos de exceção merece atenção antes que as telas sejam desenhadas e os status nomeados. O caminho de exceção define o que acontece quando a realidade interrompe o plano — e a realidade faz isso com frequência.
Se você está construindo um app interno de aprovações, inclusive em uma plataforma no‑code como AppMaster, os casos rejeitados e incompletos precisam de tanto cuidado quanto o caso aprovado. Eles moldam as mensagens que as pessoas veem, as ações disponíveis e se o fluxo ajuda a recuperar ou deixa todo mundo preso.
O caminho feliz mostra intenção. Os caminhos de exceção mostram se o processo sobrevive ao uso real.
Um caminho de exceção é o que acontece quando uma solicitação não pode seguir adiante do modo normal. Não é um caso raro. É a parte do processo que trata da bagunça do mundo real: uma solicitação é negada, um formulário está incompleto, uma parte é aprovada e outra não, ou o trabalho simplesmente empaca.
Um caminho de exceção claro usa linguagem simples. Em vez de um status vago como "Failed", diga o que aconteceu: "Rejeitada porque o orçamento ultrapassa o limite" ou "Aguardando documento de identificação". As pessoas devem saber o que está errado, quem precisa agir e o que acontece em seguida.
A maioria dos workflows quebra de algumas maneiras previsíveis:
Informação faltante é um dos problemas mais comuns. Imagine um formulário de cadastro de fornecedor que precisa de documento fiscal e número de conta bancária. Se faltar qualquer um, o sistema não deve apenas parar. Deve marcar a solicitação como incompleta, mostrar exatamente o que falta e devolvê‑la à pessoa certa.
Aprovações parciais são igualmente importantes. Pense num pedido de viagem com passagem, hotel e verba de alimentação. O gerente aprova passagem e hotel, mas corta a verba de alimentação. O processo agora precisa de regras. O empregado aceita a mudança, atualiza a solicitação ou cancela a viagem?
Paradas também importam. Uma solicitação pode ficar sem atenção porque o revisor saiu da empresa, a equipe não definiu um aprovador reserva, ou o processo chega a um passo sem próximo responsável. Nada está tecnicamente quebrado, mas a solicitação não anda.
Se você não desenhar esses caminhos cedo, as pessoas lidarão por e‑mail, chat ou planilhas. Logo ninguém sabe qual versão é a final.
Considere um pedido de viagem para um gerente de vendas que quer ir a uma conferência de dois dias. No papel, o fluxo parece fácil: o empregado informa datas, custo estimado e motivo da viagem. O gerente aprova, o financeiro confirma o orçamento e a viagem vai para a reserva.
Esse fluxo é limpo, mas também incompleto.
Agora quebre a mesma solicitação. O empregado envia a estimativa de passagem e o ingresso da conferência, mas esquece a cotação do hotel. Se o sistema conhece apenas "enviado" e "aprovado", as pessoas travam rápido. O financeiro vê uma solicitação incompleta, o gerente pode achar que está pronta e o empregado não sabe o que falta.
Um fluxo melhor dá à solicitação um estado próprio, como "Aguardando documento" ou "Precisa de atualização". O empregado deve ver uma mensagem clara: "Adicione a cotação do hotel antes que esta solicitação avance para o financeiro." O gerente não precisa rejeitar toda a viagem só para pedir um arquivo.
Agora acrescente um segundo problema. O gerente concorda que a viagem deve acontecer, mas não pelo valor total. Aprova a passagem e uma diária de hotel, mas rejeita a taxa do workshop e a segunda diária.
É aí que muitas equipes descobrem que não têm realmente um processo de aprovação parcial.
Se o workflow não consegue aprovar apenas parte da solicitação, as pessoas começam a improvisar. Podem rejeitar tudo e pedir um novo envio. Ou o financeiro aprova o valor total por engano porque o sistema armazena apenas uma decisão sim/não.
Um modelo claro rastreia cada item de custo, ou pelo menos o total aprovado. Uma solicitação pode mostrar:
Esse exemplo único mostra por que erros em workflows de aprovação muitas vezes vêm de regras faltantes, não de pessoas descuidadas. Se você definir essas regras antes de desenhar as telas, o resto do fluxo fica muito mais confiável.
Uma boa forma de melhorar um fluxo é assumir que a solicitação não passará limpo. Essa mudança de perspectiva melhora rapidamente a qualidade do design.
Comece pelos casos bagunçados: o formulário está incompleto, a política é ambígua, o aprovador está ausente ou apenas parte da solicitação deve avançar. A maioria das equipes consegue agrupar isso em três padrões principais:
Isso mantém o trabalho administrável. Em vez de inventar uma resposta para cada caso extremo, você define um conjunto pequeno de padrões e os aplica a cada tipo de solicitação.
Trabalhe nesta ordem.
Primeiro, liste cada ponto em que a solicitação pode parar. Pense em documentos faltantes, valores inválidos, violações de política, prazos expirados, envios duplicados e revisão manual. Se a solicitação pode esperar, falhar ou voltar ao remetente, escreva.
Em seguida, decida o que acontece em cada caso. Para cada exceção, responda quatro perguntas simples:
Por exemplo, imagine um empregado que envia um reembolso de viagem de $600. Falta o recibo do hotel e uma refeição está acima da política. Se você só projetar o caminho feliz, a solicitação ou trava ou é rejeitada como um bloco só. Se projetar exceções primeiro, o sistema pode pausar o reembolso por falta do recibo, notificar o empregado com uma mensagem clara e ainda marcar os itens permitidos como aprovados condicionalmente.
É aí que regras de aprovação parcial importam. Você precisa decidir se o valor aprovado pode seguir agora, se o resto fica em espera e se o solicitante pode editar apenas a parte em disputa ou precisa reenviar o pedido inteiro.
Se estiver construindo o processo em AppMaster, esse é o momento de mapear esses ramos na lógica de negócio antes de polir a UI. É muito mais fácil confiar em um fluxo quando rejeitar, devolver para edição e aprovar com condições são caminhos separados em vez de escondidos num status vago.
Finalmente, teste um cenário real do começo ao fim. Use números concretos, uma lacuna real em documento e uma exceção de política. Se uma pessoa lendo o fluxo não conseguir dizer o que acontece em seguida em menos de um minuto, o design ainda está vago.
Telas parecem concretas, então as equipes costumam começar por elas. Rascunham botões, formulários e dashboards antes de concordar sobre as regras. Isso costuma criar problemas depois, porque a interface acaba escondendo decisões que ninguém tomou.
Uma ordem melhor é simples: defina os estados, repasses, prazos e provas necessárias para seguir em frente. Depois construa as telas em torno disso.
O design de caminhos de exceção fica muito mais fácil quando o conjunto de regras é pequeno e claro. Se uma solicitação pode ser aprovada, rejeitada, enviada de volta para correção ou aprovada parcialmente, esses estados precisam de nomes simples que signifiquem apenas uma coisa. Evite quase‑duplicatas como "Returned", "Reopened" e "Needs changes" a menos que realmente se comportem de forma diferente.
Pegue um pedido de compra. Um gerente abre e percebe que falta a cotação. Se a equipe não decidiu o que acontece a seguir, as pessoas improvisam. Um gerente rejeita. Outro deixa pendente. Um terceiro envia uma mensagem por chat e não altera nada no sistema. Logo ninguém confia no status.
Escreva a regra primeiro. Quando falta uma cotação, a solicitação vai para "Needs documents". O solicitante é o responsável pelo próximo passo. A solicitação fica lá por cinco dias úteis. Se nada chegar, vira "Expired" e é necessário um novo envio.
Essa única regra molda o produto melhor que um mockup. Agora você sabe o que o usuário deve ver, qual lembrete enviar e qual histórico guardar.
Um conjunto prático de regras deve responder quatro perguntas:
Aprovações parciais precisam do mesmo cuidado. Se a viagem é aprovada, mas o custo do hotel não, o solicitante edita o mesmo registro ou cria outro? O financeiro revê apenas a parte alterada, ou tudo de novo? Se isso não for decidido cedo, a tela pode ficar bonita enquanto o processo por trás continua bagunçado.
Quando as equipes definem as regras primeiro, a interface fica mais simples. E, mais importante, os usuários sabem exatamente o que fazer a seguir, mesmo quando a resposta é "ainda não aprovado".
Uma mensagem de exceção ruim atrasa tudo. As pessoas não precisam apenas saber que algo falhou. Precisam saber o que aconteceu, o que afeta e o que fazer a seguir.
É aí que o design vira algo real para os usuários. Suas regras internas podem ser claras, mas se a tela só mostra "Error" ou "Pending review", as pessoas vão chutar, reenviar arquivos errados ou pedir ajuda ao suporte.
Pense num exemplo de aprovação de fornecedor. Um usuário envia um formulário com documento fiscal, dados bancários e prova de seguro. Os dados bancários estão ok, o documento fiscal está desatualizado e a prova de seguro falta. Se o sistema só mostrar "Request not approved", o usuário não tem um próximo passo claro.
Uma mensagem melhor soa assim: "Seus dados bancários foram aprovados. Ainda precisamos de um documento fiscal atualizado e da prova de seguro antes da aprovação final." Essa frase economiza tempo porque separa o que já está feito do que ainda falta.
Boas mensagens geralmente respondem quatro perguntas pequenas:
Essa última parte importa. As pessoas são mais propensas a concluir a tarefa quando o próximo passo é óbvio. "Envie o arquivo faltante e reenviar para revisão" é muito melhor que "Ação necessária."
Rótulos vagos também geram ansiedade. "Pending review" pode significar aguardando uma pessoa, falta de dados ou uma checagem interna. Se você sabe o motivo, diga claramente. "Aguardando aprovação do gerente" e "Aguardando comprovante de endereço" não são a mesma coisa e não devem parecer iguais.
Se um processo permite aprovação parcial, mostre isso no próprio status. Uma pequena discriminação costuma funcionar melhor que um único rótulo:
Agora o usuário corrige apenas o que importa. Não precisa recomeçar.
Também facilite o reenvio: coloque a ação seguinte próxima da mensagem, não em outra tela. Se estiver construindo o fluxo em AppMaster, ajude a casar o texto visível com os estados reais do processo para que o app diga exatamente o que a lógica de negócio está fazendo.
Boas mensagens reduzem tickets de suporte, aceleram aprovações e fazem o processo parecer justo. As pessoas aceitam uma rejeição quando entendem o motivo.
A maior parte do retrabalho começa com uma suposição errada: o caminho normal é a principal coisa a projetar. As equipes mapeiam solicitação enviada, aprovada, concluída e param por aí. Então a vida real aparece: falta um arquivo, um gerente quer mudanças ou apenas parte pode seguir.
Esse gap cria trabalho extra rápido. As pessoas inventam soluções manuais, mandam mensagens paralelas e renomeiam status por conta própria. Algumas semanas depois, ninguém confia no workflow porque toda exceção virou um caso especial.
Um erro comum é tratar o caminho ideal como o produto e tudo o resto como limpeza. Imagine um pedido de reembolso que precisa de recibo, aprovação do departamento e revisão do financeiro. Se faltar o recibo, a solicitação pausa, volta ao empregado ou é rejeitada? Se isso não estiver claro desde o início, a equipe costuma corrigir com e‑mails e comentários depois.
Nomes de status confusos causam outra rodada de retrabalho. Rótulos como "In review 2" ou "Pending action" parecem inofensivos, mas obrigam as pessoas a adivinhar o próximo passo. Nomes claros reduzem erros porque indicam o problema, o responsável, o resultado ou a próxima ação.
Responsabilidade é outro ponto onde os workflows quebram. Uma solicitação nunca deve ficar em um status que não pertence a ninguém. Se um caso está aguardando, alguém precisa ser responsável por avançar, pedir mais informação ou encerrar. Caso contrário, atrasos silenciosos se acumulam e os usuários acham que o sistema perdeu a solicitação.
Aprovação parcial também costuma ser tratada de forma inadequada. Equipes a tratam como uma rejeição total porque parece mais simples. Mas os resultados são diferentes. Se um pedido de viagem solicita passagem, hotel e alimentação, o financeiro pode aprovar passagem e hotel, negar alimentação. Esse caso precisa de caminho próprio, mensagem própria e geralmente uma ação de acompanhamento.
Quando a aprovação parcial é misturada com rejeição, as pessoas reenviam o pedido inteiro, duplicam documentos e reiniciam revisões já feitas. Isso é retrabalho puro.
Um teste simples ajuda: leia cada status não feliz e pergunte, "Quem é dono disso, o que o usuário vê e o que acontece a seguir?" Se a resposta for vaga, o processo provavelmente quebrará no mesmo ponto mais tarde.
Antes de construir telas ou automatizar, faça uma última revisão dos casos bagunçados. Um bom design de caminhos de exceção muitas vezes é apenas algumas decisões claras tomadas cedo, antes que a confusão vire retrabalho.
Se uma solicitação é rejeitada, pausada ou apenas parcialmente aprovada, alguém deve sempre saber o que acontece a seguir, quem faz e quais informações faltam.
Use esta verificação rápida para cada exceção do seu processo:
Depois faça um teste simples. Entregue o processo a alguém que não participou do design. Dê a essa pessoa uma solicitação rejeitada e outra com um documento faltante. Se ela não souber o que fazer em menos de um minuto, o processo ainda está vago.
Um pequeno exemplo ilustra: imagine um gerente aprova a solicitação de software, mas rejeita a parte de hardware. Se o status só diz "Partially approved", o empregado pode supor que tudo pode avançar. Um status melhor diz exatamente o que foi aprovado, o que foi negado e se o empregado pode reenviar a parte faltante.
Se quiser transformar essas regras em um app interno funcional, mapeie os estados de exceção primeiro e construa o caminho feliz depois. Em AppMaster, isso pode significar definir status, regras de negócio e campos obrigatórios antes de polir as telas. É uma forma prática de criar aplicações no‑code que lidam com trabalho real, não apenas com a versão ideal.
O próximo passo é simples: liste suas cinco principais exceções, atribua um responsável para cada e escreva a mensagem que o usuário deve ver. Se essas três partes estiverem claras, a construção costuma ficar bem mais fácil.
Why isn't the happy path enough for an approval workflow?Porque os atrasos reais normalmente ocorrem quando algo está faltando, confuso, atrasado ou apenas parcialmente aprovado. Se você projetar apenas o fluxo limpo, as pessoas acabarão resolvendo problemas por chat, e-mail e soluções manuais.
Which exception paths should I design first?Comece pelos casos que acontecem com mais frequência: rejeição, informação faltante e aprovação parcial. Depois inclua paralisações, como uma solicitação sem responsável ou sem próximo passo definido.
What statuses should an approval app have?Use um pequeno conjunto de estados claros que signifiquem apenas uma coisa cada. Um padrão prático é: aprovado, rejeitado, precisa de documentos, precisa de mudanças, parcialmente aprovado e expirado (se houver prazos).
How should the process handle missing documents?O usuário deve ver exatamente o que falta e o que fazer em seguida. Um padrão útil é mover a solicitação para um estado como "Needs documents", nomear claramente os itens faltantes e devolvê‑la à pessoa certa em vez de rejeitar tudo.
How do I handle partial approvals without creating rework?Trate a aprovação parcial como um caminho próprio, não como uma rejeição total. Mostre o que foi aprovado, o que foi negado, o novo total aprovado se relevante, e se o solicitante pode aceitar a alteração, editar a solicitação ou reenviar apenas a parte em disputa.
What should happen when a request gets stuck with no action?Dê a cada estado de espera um responsável e uma regra de tempo. Se um revisor estiver ausente ou um pedido ficar parado por muito tempo, o workflow deve escalar, reatribuir ou expirar em vez de ficar travado.
What makes an exception message actually useful?Seja direto e específico. Diga ao usuário qual parte foi rejeitada ou está faltando, o que já foi aceito, o que ele precisa enviar, alterar ou confirmar a seguir e o que acontece depois que ele reenviar.
Should I design the screens first or the workflow rules first?Defina as regras primeiro. Entrem em acordo sobre estados, responsáveis, prazos, arquivos obrigatórios e próximas ações antes de rabiscar botões ou painéis, porque a interface deve refletir decisões já tomadas.
How can I test whether my exception path is clear enough?Teste um cenário real do início ao fim com números reais e um ou dois problemas — por exemplo, um arquivo faltando ou uma violação de política. Se alguém novo não souber o que fazer em menos de um minuto, o fluxo ainda está vago.
How would I build this kind of workflow in AppMaster?Mapeie os estados de exceção na lógica de negócio antes de polir a UI. Em AppMaster, isso significa definir status, campos obrigatórios, propriedade e ramificações como rejeitar, devolver para edição e aprovar com condições primeiro.
10 de mar. de 2026
9 min
08 de mar. de 20268 min
07 de mar. de 20266 minExperimente o AppMaster com plano gratuito.
Quando estiver pronto, você poderá escolher a assinatura adequada.
