Como configurar campos condicionais no formulário de licenciamento por tipo de solicitação

Configurar campos condicionais no formulário de licenciamento significa fazer o próprio formulário mudar de estrutura conforme o tipo de solicitação escolhido pelo requerente — pedindo documento e informação diferentes para uma nova construção, uma legalização ou uma transformação de uso, em vez de apresentar o mesmo conjunto fixo de campos para qualquer situação. O objetivo não é enxugar o formulário por enxugar: é impedir que o requerente preencha informação que não se aplica ao seu caso e impedir que a prefeitura aceite um protocolo sem o dado que só aquele tipo específico de solicitação exige.

Este guia cobre o que é um formulário condicional, por que ele evita tanto o formulário genérico demais quanto o formulário fragmentado em dezenas de serviços quase idênticos, o passo a passo para configurar essa lógica, o que a legislação exige e os indicadores que mostram se a configuração está funcionando.

O que é formulário condicional em processo de licenciamento

É a técnica de parametrização em que uma única solicitação de serviço — por exemplo, “licenciamento de edificação” — abriga vários tipos de pedido (nova construção, legalização, transformação de uso, modificação e/ou acréscimo, legalização de modificação), e o formulário exibe, oculta ou torna obrigatório um campo específico de acordo com o tipo selecionado no início do preenchimento. Uma transformação de uso, por exemplo, pressupõe que já existe um processo anterior de aceite da edificação — então o formulário precisa perguntar se esse aceite já foi emitido pelo próprio sistema e, em caso positivo, exigir o vínculo com o número desse processo antes de liberar o restante do preenchimento. Uma nova construção não tem esse histórico para vincular, então esse bloco de campos simplesmente não aparece para quem seleciona essa opção.

Isso é diferente de simplesmente dividir o serviço em vários formulários separados — nova construção, legalização e transformação de uso como três protocolos distintos na carta de serviços. A divisão em serviços separados multiplica manutenção (qualquer mudança de regra precisa ser replicada em cada um) e obriga o requerente a já saber, antes de começar, em qual categoria seu caso se encaixa. O formulário condicional resolve isso com uma única porta de entrada, que se adapta depois que o tipo é informado.

Por que formulário condicional importa

Um formulário fixo, pensado para o caso mais comum, tem dois efeitos colaterais opostos e igualmente caros. Para o requerente cujo caso é mais simples do que a média, o formulário pede documento e informação que não fazem sentido — campo de vínculo com processo anterior para quem está construindo do zero, por exemplo —, o que aumenta a taxa de abandono e a chance de preenchimento incorreto só para conseguir avançar. Para o requerente cujo caso exige uma informação específica — como o número do processo de aceite anterior, no caso de uma transformação de uso —, um formulário genérico simplesmente não pergunta isso, e o protocolo chega incompleto à análise técnica, gerando exigência documental e reabrindo o ciclo que deveria ter sido resolvido na entrada.

O efeito se acumula no volume: quanto mais tipos de solicitação um mesmo serviço abriga, maior a chance de um formulário estático deixar passar informação crítica para uma parte dos casos enquanto sobrecarrega a outra parte com campo irrelevante. É esse descompasso — não a complexidade do rito em si — que mais gera retrabalho entre requerente e secretaria de obras ou planejamento urbano.

Passo a passo para configurar campos condicionais

1. Mapeie os tipos de solicitação e o que muda entre eles

Liste cada variação do serviço (nova construção, legalização, transformação de uso, modificação e/ou acréscimo) e, para cada uma, o que é exclusivo dela: documento obrigatório, campo de preenchimento, e se depende de um processo anterior já protocolado.

2. Separe os campos e documentos exclusivos de cada tipo

Nem todo campo precisa de lógica condicional — dados do requerente e do imóvel, por exemplo, costumam ser comuns a todos os tipos. Isole apenas o que de fato varia, para não transformar o formulário inteiro numa árvore de exceções difícil de manter.

3. Estruture o formulário em seções que abrem condicionalmente

Organize o preenchimento em blocos (cards) sequenciais, onde a seleção do tipo de solicitação no primeiro bloco determina quais dos blocos seguintes aparecem, ficam ocultos ou passam a exigir preenchimento obrigatório.

4. Trate o tipo que depende de processo anterior como vínculo, não como campo livre

Quando o tipo de solicitação pressupõe um protocolo anterior — como a transformação de uso que depende de um aceite já emitido —, o campo correto não é uma caixa de texto livre para o requerente descrever o processo antigo: é um vínculo direto com o número daquele processo, validado pelo próprio sistema antes de liberar o restante do formulário.

5. Bloqueie o avanço enquanto o campo condicional obrigatório não for preenchido

Um campo que só aparece condicionalmente ainda precisa impedir a finalização do protocolo se ficar em branco — a lógica condicional decide o que perguntar, não dispensa a obrigatoriedade de quem precisa responder.

6. Teste isoladamente cada tipo de solicitação antes de publicar

Simule o preenchimento completo escolhendo cada tipo, um de cada vez, conferindo se os campos certos aparecem, se os errados ficam ocultos e se o bloqueio de campo obrigatório funciona em todos os caminhos, não só no caminho mais comum.

7. Revise a configuração sempre que o rito ou a legislação mudar

Uma nova exigência documental ou uma mudança na lei de uso do solo pode afetar só um dos tipos de solicitação — revise a árvore condicional inteira, não apenas o campo isolado, para não deixar uma regra desatualizada aplicada a um tipo que já mudou.

O que a legislação exige

A Lei nº 14.129/2021 (Lei do Governo Digital) estabelece, no art. 5º, a simplificação do atendimento e a interoperabilidade de bases de dados como princípios da prestação digital de serviços públicos — o que sustenta diretamente um formulário que se ajusta ao caso do requerente em vez de tratar toda solicitação com o mesmo roteiro fixo. A Lei nº 13.726/2018 (Lei da Desburocratização), no art. 3º, reforça que a administração deve aproveitar dado e documento que já possui em vez de exigir do cidadão informação redundante — princípio que justifica vincular o novo protocolo ao processo anterior de aceite, em vez de pedir ao requerente que descreva de novo algo que a prefeitura já tem registrado.

Como o Aprova resolve isso

• O formulário é dividido em seções (cards) configuráveis, com exibição condicional de campo e de obrigatoriedade definida pela própria secretaria, sem depender de desenvolvimento sob demanda a cada ajuste de regra.
• Um tipo de solicitação que depende de processo anterior pode ser configurado como vínculo direto ao número do protocolo original, com validação automática, em vez de campo de texto livre.
• O sistema não permite finalizar o protocolo enquanto um campo marcado como obrigatório para aquele tipo de solicitação continuar em branco.
• Inteligência artificial valida os documentos anexados conforme a regra configurada para cada tipo, sinalizando inconsistência antes mesmo de o processo chegar à análise técnica — o mesmo racional descrito em como validar documentos com IA antes do protocolo.
• A parametrização do formulário fica com a própria secretaria, que pode ajustar campo, seção e obrigatoriedade conforme a legislação municipal muda, sem depender de novo desenvolvimento a cada alteração de rito.

Indicadores para medir campos condicionais no formulário

• Percentual de protocolos que recebem exigência documental (comunique-se) por tipo de solicitação — queda nesse indicador mostra que a lógica condicional está capturando o documento certo na entrada.
• Tempo médio de preenchimento do formulário, comparado entre os diferentes tipos de solicitação.
• Volume de protocolos devolvidos por vínculo incorreto ou ausente com processo anterior.
• Taxa de abandono do formulário antes da finalização, especialmente no tipo de solicitação mais simples.

FAQ sobre formulário condicional

É preciso criar um serviço separado para cada tipo de solicitação?

Não necessariamente. Quando os tipos compartilham a maior parte dos campos e apenas uma parte específica varia, manter um único serviço com lógica condicional reduz a manutenção comparado a manter vários serviços quase idênticos na carta de serviços.

O que acontece se o requerente escolher o tipo errado no início do formulário?

O formulário segue a lógica do tipo selecionado, então campos exigidos para o tipo correto podem não aparecer. Por isso a análise técnica deve conferir se o tipo declarado é compatível com a documentação e a situação real do imóvel antes de prosseguir, com possibilidade de retificação formal caso haja divergência.

Um campo condicional pode depender de mais de uma resposta anterior?

Sim. É possível encadear condições — o tipo de solicitação define a seção que aparece, e dentro dela uma segunda resposta pode abrir um novo bloco de campos. O cuidado é não deixar essa árvore de dependências tão profunda a ponto de dificultar o teste e a manutenção.

Formulário condicional atrasa o tempo de carregamento para o requerente?

Não, quando a lógica é resolvida no próprio formulário, sem depender de consulta externa a cada campo. A consulta a base de dados externa, quando existe, deve ser limitada aos campos que de fato precisam dela.

Como lidar com um tipo de solicitação usado raramente?

Mantenha a lógica condicional configurada mesmo assim — a baixa frequência de um tipo não reduz o risco de erro quando ele aparece; ao contrário, tende a aumentar, porque tanto o requerente quanto o analista têm menos familiaridade com aquele fluxo específico.

Conclusão

Um formulário de licenciamento que trata todo tipo de solicitação da mesma forma resolve o caso mais comum e cria atrito nos demais — seja pedindo informação de mais para quem não precisa, seja deixando de pedir o dado específico que só aquele tipo exige. Mapear o que de fato varia entre os tipos, isolar esses campos numa lógica condicional e tratar dependência de processo anterior como vínculo formal, não como texto livre, é o que permite manter um único ponto de entrada sem sacrificar a precisão de cada caminho.

Esse tema se conecta diretamente a como estruturar o protocolo digital como porta de entrada única do município e ao funcionamento mais amplo do processo administrativo eletrônico. Para ver como o Aprova estrutura formulário parametrizável por tipo de solicitação dentro do processo eletrônico, agende uma demonstração da Aprova.