Design de sistema de solicitação de folga simplificado: defina políticas, trate a matemática de acúmulo, roteie aprovações de gestores e mantenha calendários precisos sem fluxos confusos.
As pessoas esperam que uma solicitação de folga seja tão simples quanto agendar uma reunião: escolher datas, ver o saldo, receber um sim ou não claro e ter isso refletido em todos os lugares necessários. Quando não funciona assim, as equipes voltam para o “me manda uma mensagem” e o sistema vira um exercício de arquivamento em vez de uma ferramenta confiável.
As solicitações normalmente travam nas transferências: um e-mail que não chega ao gestor correto, uma planilha que ninguém atualiza ou uma aprovação por chat que é impossível auditar depois. O funcionário pensa que está coberto, o gestor acha que o RH vai resolver, e o RH só descobre na folha que o saldo está errado.
O objetivo real do design de um sistema de solicitação de folga é entediante, mas importante: saldos corretos, aprovações claras e uma única fonte de verdade. Se o saldo estiver certo, mas as aprovações não forem claras, gestores vão continuar perguntando “Já aprovei isso?” Se as aprovações forem perfeitas, mas o calendário estiver errado, as equipes ainda vão se sobrepor.
Quatro grupos dependem do mesmo fluxo, mas por motivos distintos:
Um “fluxo legível” significa que você pode olhar os passos e explicá-los em linguagem simples: o que dispara a solicitação, quem aprova, o que acontece em caso de rejeição e o que é escrito de volta (saldo, status, calendário). Se você não consegue explicar rápido, as pessoas vão contornar o processo.
Ferramentas como AppMaster ajudam mantendo a lógica visual e centralizada, para que mudanças de política não se tornem um labirinto de e-mails e exceções.
Uma boa ferramenta de folga é, na maior parte, um conjunto limpo de registros e algumas relações claras. Se você acertar o básico, o resto do seu design de sistema de solicitação de folga permanece legível, mesmo quando políticas e aprovações crescerem.
Comece com um pequeno conjunto de objetos centrais que você consegue explicar em um minuto:
Para as solicitações, os campos que evitam dor do mundo real não são sofisticados. São específicos. Armazene data/hora de início e fim, se é dia parcial, e o fuso horário do funcionário no momento da solicitação. Adicione um motivo curto e permita anexos se o processo de RH exigir comprovação (por exemplo, atestado médico). Mantenha anexos opcionais para não bloquear o PTO normal.
Os status devem ser poucos e previsíveis: rascunho (salvo, mas não enviado), enviado, aprovado, rejeitado e cancelado. Evite status extras como “pendente RH” a menos que realmente precise.
Não pule a trilha de auditoria. Mesmo um registro mínimo de “quem mudou o quê e quando” te salva em disputas. No mínimo, registre envio, aprovação, rejeição, cancelamento e qualquer edição de data.
Para equipes, locais e departamentos, trate-os como dados de referência separados. Vincule funcionários a esses grupos e vincule políticas aos grupos aos quais se aplicam. Assim, quando alguém muda de escritório, você atualiza um registro de funcionário, não todas as políticas.
Se você construir isso no AppMaster, mantenha cada objeto simples primeiro, depois adicione validações e passos de fluxo depois que os dados estiverem estáveis.
Boas políticas são entediantes de propósito. As pessoas devem prever o resultado antes de clicar em Enviar. No design do sistema de solicitação de folga, a maneira mais rápida de perder confiança é quando a mesma solicitação é aprovada uma semana e rejeitada na outra.
Comece nomeando seus tipos de licença e escrevendo uma frase simples para cada um. Férias ou PTO são tempo planejado fora. Licença médica é tempo não planejado por saúde. Licença sem remuneração é tempo sem pagamento. Licença parental costuma ter datas e documentos especiais. Comp time é ganho por horas extras e gasto como PTO.
As regras de elegibilidade devem ler como uma lista de verificação, não um documento jurídico. Seja explícito: quem pode usar (tempo integral, meio período, contratados), quando começa (após período probatório, após X dias) e se depende de tempo de casa. Se uma regra tiver exceções, escreva a exceção como uma regra própria, não uma nota de rodapé.
Regras de solicitação são onde geralmente começa a confusão. Seja específico sobre prazos de aviso, datas bloqueadas e o menor pedaço de tempo permitido. Por exemplo: “Solicitações de férias devem ser submetidas com 5 dias úteis de antecedência, exceto emergências aprovadas pelo RH” é testável. “Envie com antecedência” não é.
Regras de acúmulo e expiração devem caber em uma frase. Exemplo: “Até 40 horas são transferidas para o próximo ano e expiram em 31 de março.” Se você precisa de uma segunda frase, é um sinal de que a política está fazendo demais.
Aqui está uma forma simples de manter o texto da política e a lógica das regras sincronizados:
Exemplo: um funcionário em período probatório solicita 2 horas de PTO para amanhã. O sistema deve bloqueá-lo por duas razões fáceis de ler: “PTO começa após 60 dias” e “PTO exige 5 dias úteis de aviso.” Se você construir no AppMaster, mantenha essas mensagens próximas aos nós de regra para que as atualizações não se dispersem ao longo do tempo.
Acúmulo é onde o design do sistema de solicitação de folga frequentemente fica complicado, porque pequenas regras se acumulam. O objetivo não é matemática sofisticada. O objetivo é resultados previsíveis que batam com o que RH e funcionários esperam ao checar um saldo.
Uma confusão comum é misturar estilos de acúmulo. Algumas empresas adicionam horas a cada período de pagamento, outras adicionam mensalmente, algumas acumulam por hora trabalhada e outras concedem o montante anual numa data fixa. Os problemas começam quando você armazena apenas “saldo” e esquece “como foi ganho”. Mantenha um registro claro de eventos: concessão, acréscimo (acúmulo), ajuste e uso.
Proratização é outra armadilha. Um novo funcionário que começa no meio do mês, ou alguém que muda de meio período para integral, não deveria precisar de conserto manual em planilha. Decida uma regra e mantenha-a. Por exemplo: prorratear pelos dias do calendário no período ou pelas horas programadas. Seja qual for a escolha, escreva em palavras simples e codifique do mesmo jeito em todo lugar.
Tetos e saldos negativos geram chamados do tipo “parece errado”. Se você permite carryover até um limite, aplique o teto em um momento específico (fim do ano, fim do período de acúmulo ou após cada acréscimo). Se saldos negativos são permitidos, defina o limite e o que acontece na rescisão.
Regras de arredondamento criam desvios silenciosos. Escolha um nível de arredondamento (minutos, quartos de hora ou meio-dia) e aplique consistentemente tanto no acúmulo quanto no uso. Se você acumula em minutos, mas solicita em meio-dia, os funcionários sempre vão achar que o sistema está errado.
Solicitações retroativas e correções precisam de trilha de auditoria. Se alguém submete uma solicitação para a semana passada, o sistema deve recalcular a partir da data efetiva para frente e registrar a alteração.
Um checklist simples que previne a maioria das disputas:
No AppMaster, isso geralmente mapeia limpamente para uma tabela de Transactions mais um pequeno processo de negócio que recomputa saldos quando uma solicitação é aprovada ou corrigida.
Um fluxo de aprovação do gestor deve responder a uma pergunta: quem pode dizer “sim” com confiança? Se você tentar modelar cada detalhe do organograma, seu design de sistema de solicitação de folga fica difícil de ler e ainda mais difícil de consertar.
Comece com uma regra padrão: o gestor direto do funcionário aprova. Depois adicione apenas exceções que alterem risco ou responsabilidade. Mantenha a ordem das regras explícita, para que você possa explicar resultados sem fuçar nas configurações.
A maioria das equipes pode usar uma única etapa de aprovação para PTO padrão. Adicione etapas só quando a solicitação afetar folha, conformidade ou cobertura entre equipes.
Padrões comuns que permanecem legíveis:
As aprovações falham quando o aprovador está ausente. Faça da delegação uma regra de primeira classe, não um contorno manual. Se o gestor estiver marcado como fora, roteie para um delegado; se não houver delegado, roteie para o gestor do gestor (ou RH como fallback). Sempre registre qual regra escolheu o aprovador.
Rejeições e edições são onde os sistemas ficam bagunçados. Mantenha simples: uma rejeição fecha a solicitação com motivo obrigatório. Se o funcionário editar datas ou tipo de licença, trate como um reenvio e rode novamente o roteamento do zero. Isso evita solicitações “meio aprovadas” que não correspondem ao que foi aprovado.
Um exemplo prático: Alex solicita 3 dias de licença médica. O sistema rota para o gestor, mas por ser um tipo controlado por política, o RH recebe um segundo passo somente após a aprovação do gestor. Se o gestor estiver ausente, o delegado aprova e a trilha de auditoria mostra o motivo.
Se você construir no AppMaster, mantenha a lógica de roteamento em um processo visual com um pequeno conjunto de regras em ordem clara, para que qualquer pessoa possa ler e manter depois.
Boa validação mantém o design do sistema legível porque evita que casos especiais vazem para as aprovações. Mire em regras fáceis de explicar e testar.
Comece com regras de agendamento. Verificações de sobreposição devem detectar conflitos com licenças já aprovadas e solicitações pendentes. Seja explícito sobre dias parciais: armazene a data mais uma unidade simples como AM, PM ou horas para que meio-dia não seja convertido acidentalmente em dia inteiro. Também decida o que fazer com fins de semana e feriados: bloqueá-los ou permitir e ignorar na contagem de dias.
Verificações de saldo são mais complicadas do que parecem. Muitas equipes validam saldo no momento do envio (para que as pessoas não façam spam de solicitações) e checam novamente na aprovação (porque acúmulos e outras aprovações podem mudar o saldo). Se fizer os dois, mostre ao usuário qual verificação falhou.
Aqui está um conjunto limpo de validações que cobre a maioria dos casos:
Verificações de cobertura de equipe podem ajudar, mas evite bloqueios rígidos a menos que precise. Um padrão melhor é um aviso que permita a decisão do gestor. Exemplo: “Duas pessoas da sua equipe já estão fora neste dia. Enviar mesmo assim?”
Faça mensagens de erro justas e corrigíveis. Diga aos usuários o que falhou, onde e como corrigir. Por exemplo: “Sua solicitação conflita com um PTO aprovado em 12 de mar (PM). Escolha outro horário ou edite a solicitação existente.”
Se você construir no AppMaster, mantenha as validações próximas ao formulário de solicitação e reutilize as mesmas checagens na etapa de aprovação, para que as regras não se dispersem com o tempo.
Um bom design de sistema de solicitação de folga é entediante do melhor jeito: cada solicitação segue o mesmo caminho e cada decisão tem uma razão clara. A maneira mais fácil de mantê-lo legível é separar dados de política (quais são as regras) da lógica do fluxo (o que acontece quando alguém clica Enviar).
Aqui está uma sequência que permanece simples mesmo ao adicionar mais tipos de licença:
Mantenha o fluxo legível registrando cada decisão em linguagem simples (por exemplo: “Rejeitado: conflita com folga aprovada existente”). Se usar uma ferramenta visual de fluxo como o Business Process Editor do AppMaster, rotule os passos do jeito que um humano os leria.
Antes do lançamento, teste com cenários reais: solicitações retroativas, gestor ausente, mudança de política no meio do ano e uma edição após aprovação. Se o resultado surpreender o RH, a regra ainda não está clara o suficiente.
Um calendário deve responder rapidamente a uma pergunta: quem está ausente e quando. Não tente transformar o evento de calendário no registro completo da solicitação. Coloque apenas o que ajuda no agendamento e mantenha o restante no seu sistema de RH.
Para conteúdo do evento, mantenha consistente. Um bom padrão é um título curto como “Fora do escritório - Alex Kim” mais o tipo de licença se for relevante (“PTO”, “Sick”). Mantenha detalhes mínimos por privacidade. Muitas equipes preferem mostrar o evento como “Ocupado” e armazenar motivos, saldos e notas apenas na solicitação.
Cada solicitação precisa de um ID interno estável, e cada evento de calendário deve armazenar esse ID (por exemplo em um campo personalizado ou na descrição). Assim você pode criar, atualizar e excluir o evento certo quando as solicitações mudam.
Tratar status é onde os sistemas derivam. Decida antecipadamente se solicitações tentativas aparecem. Se aparecerem, deixe a diferença óbvia (por exemplo, prefixo de título “Pendente” e configuração de disponibilidade diferente). Quando uma solicitação for aprovada, atualize o mesmo evento em vez de criar outro. Se uma solicitação for cancelada ou rejeitada depois de estar visível, exclua o evento para que os calendários não mintam.
Fusos horários atacam mais forte com licenças de dia inteiro e parciais. Armazene início e término como timestamps exatos no fuso horário local do funcionário e também guarde esse fuso na solicitação.
Use eventos de dia inteiro apenas para folgas verdadeiramente integrais. Para dias parciais, crie eventos com horários (por exemplo 13:00–17:00) para que colegas em outros fusos vejam a sobreposição correta.
Se a sincronização de calendário falhar, não esconda. Coloque a tarefa em fila, tente novamente com backoff e mostre um status claro “Calendário não atualizado” com uma ação manual de “tentar sincronizar novamente”. Em ferramentas como AppMaster, isso costuma ser um processo em background mais uma tela administrativa listando tentativas de sync falhadas para que o RH possa corrigir sem editar solicitações.
A maioria das falhas no design de sistema de solicitação de folga acontece quando as regras crescem silenciosamente com o tempo. O sistema ainda “funciona”, mas ninguém confia nos saldos e cada caso estranho vira um chamado de suporte.
Se o acúmulo é dividido em muitos casos especiais (novos contratados, carryover, licença sem remuneração, meio período), as pessoas não conseguem prever seu saldo.
Mantenha um modelo de acúmulo claro por tipo de licença e depois adicione exceções como regras nomeadas e testáveis. Escreva alguns funcionários de exemplo e saldos esperados para datas específicas e reavalie sempre que políticas mudarem.
Aprovações com ramificações infinitas tornam testes impossíveis e gestores não entendem por que a solicitação foi para outra pessoa.
Um padrão mais seguro é:
Texto da política é para humanos (o que conta, quem é elegível). Regras matemáticas são para o sistema (taxa, tetos, arredondamento, carryover). Armazene separadamente para poder mudar a redação sem alterar cálculos e testar cálculos sem reescrever o manual.
Se você sobrescrever solicitações, perde o “porquê” por trás de uma mudança de saldo.
Sempre mantenha uma trilha de auditoria: quem mudou o quê, quando e os valores anteriores. No AppMaster, isso é simples de modelar como uma tabela de histórico de solicitações mais transições de status em um Business Process.
Folgas abrangem datas, mas aprovações e entradas de calendário usam timestamps. Normalize para um “fuso horário da política” e armazene também o fuso local do funcionário. Decida cedo se feriados reduzem os dias solicitados e aplique isso consistentemente.
Antes de anunciar a todos, execute um conjunto curto de checagens com um funcionário real, um gestor e alguém do RH. Você quer confirmar que o sistema parece óbvio, não apenas que funciona.
Use este checklist como portão de go/no-go para seu design de sistema de solicitação de folga:
Um teste prático: crie uma solicitação, aprove, edite as datas e depois cancele. Se qualquer passo deixar um saldo errado, um evento de calendário obsoleto ou um status sem explicação, corrija antes do lançamento.
Se estiver construindo no AppMaster, mantenha o fluxo legível nomeando cada passo pela ação do usuário (Submit, Validate, Route to Manager, Update Balance, Create/Update Calendar, Log Event) para que o comportamento permaneça claro conforme as políticas evoluem.
Uma nova contratada, Maya, começa em 10 de março. Seu sistema de solicitação de folga suporta acúmulo mensal, então Maya ganha PTO no primeiro de cada mês. Em 12 de abril, ela solicita um dia parcial: 3 horas na próxima sexta-feira para uma consulta médica.
O que cada pessoa vê é diferente:
Maya envia a solicitação. O gestor está de férias, então o sistema checa a configuração de delegação e roteia para o gestor interino. O gestor interino aprova.
Na aprovação, acontecem duas coisas: a solicitação é trancada para a versão da política usada e um evento de calendário é criado com o título “Maya - PTO (3h)” na data e janela de horário corretas. Maya vê imediatamente “Aprovado” e o status do calendário “Adicionado”.
Em junho, o RH atualiza a política no meio do ano (por exemplo, acúmulo aumenta após 90 dias). Saldos precisam ser recalculados, mas solicitações aprovadas no passado não devem ser alteradas silenciosamente. O sistema recalcula o saldo atual de Maya a partir da data efetiva para frente, mantendo um registro de auditoria dos valores antes/depois.
Uma semana depois, Maya edita a data da solicitação (a consulta mudou). Como a folga já estava aprovada, a mudança vira uma nova “Solicitação de alteração” que volta para o aprovador delegado. Uma vez aprovada de novo, o evento de calendário existente é atualizado (mesmo ID do evento), não duplicado.
Isso é fácil de modelar em uma ferramenta como AppMaster mantendo o fluxo legível: um caminho de aprovação, uma verificação de delegação, um passo de criar/atualizar calendário e uma ação separada de recalcular que o RH pode executar quando políticas mudam.
A forma mais segura de terminar o design do sistema de solicitação de folga é lançar uma versão pequena em que as pessoas confiem e depois expandir. Comece com uma política (por exemplo, PTO) e um caminho de aprovação (funcionário -> gestor). Quando isso estiver estável e “entediante”, adicione o próximo tipo de licença, região ou caso de borda.
Antes de criar mais regras, decida onde está a fonte de verdade. Se seu sistema de RH é o registro mestre, seu app deve principalmente validar, rotear aprovações e sincronizar resultados de volta. Se seu app é o mestre, você precisa de logs de auditoria claros e um plano para o que acontece quando dados de RH mudam (novo gestor, mudança de departamento, data de término).
Um plano prático para o primeiro lançamento:
Escreva de 5 a 10 casos de teste reais e rode-os após cada mudança. Use casos do seu próprio time, não exemplos inventados. Por exemplo: alguém solicita a sexta-feira na quinta, alguém altera a solicitação após aprovação, ou um gestor aprova enquanto o funcionário está em outro fuso horário.
Se construir com no-code, a visibilidade importa tanto quanto os recursos. No AppMaster, você pode manter o modelo de dados (tipos de licença, saldos, aprovações) e o fluxo de aprovação em editores visuais, para que RH e operações possam revisar o que o sistema realmente faz. Você também pode expor APIs para sincronização de calendário e regenerar código-fonte limpo conforme as políticas evoluem, sem empilhar consertos improvisados.
Quando a primeira versão estiver estável, expanda uma dimensão de cada vez: mais políticas, mais regras de roteamento e depois mais integrações.
21 de jan. de 2026
8 min
20 de jan. de 20268 min
20 de jan. de 20268 minExperimente o AppMaster com plano gratuito.
Quando estiver pronto, você poderá escolher a assinatura adequada.
