👤 Para administradores do pipe
🔐 Disponível nos planos Business, Enterprise e Unlimited
🎯 Para quem já tem campos criados e quer tornar o formulário mais inteligente
Formulários longos com campos que não se aplicam a todos os casos geram dois problemas práticos: preenchimento incompleto e dados inconsistentes. Quem preenche ignora o que não entende. Quem analisa recebe campos em branco sem saber se foi esquecimento ou se realmente não se aplica.
Lógica condicional resolve isso mostrando cada campo apenas quando ele é relevante para aquele contexto específico. O resultado não é só um formulário mais limpo: é um processo com menos erro de entrada, dados mais confiáveis e automações que funcionam porque encontram os campos sempre preenchidos corretamente.
A virada de perspectiva: condicional não é um truque para esconder campos. É design de experiência de preenchimento aplicado ao processo.
📖 O que você vai aprender aqui:
Quando a lógica condicional resolve um problema real
Nem todo formulário precisa de condicionais. O critério para usar é simples: existe algum campo que só faz sentido ser preenchido dependendo da resposta a outro campo anterior?
Três situações onde condicionais têm impacto direto na qualidade dos dados:
- Fluxos com perfis diferentes de preenchedor. Um processo de onboarding que atende CLT, PJ e Estagiário tem documentações completamente distintas para cada tipo. Exibir todos os campos para todos os perfis gera confusão e campos em branco. Com condicionais, cada tipo de contrato vê apenas os campos do seu fluxo.
- Campos obrigatórios que não se aplicam a todos. O Pipefy permite marcar um campo como obrigatório. Se esse campo aparece para todo mundo, mas só se aplica a alguns, o preenchedor que não tem a informação fica bloqueado. A condicional resolve: o campo obrigatório só aparece quando a condição que o torna relevante for satisfeita.
- Coleta de informações progressiva. Formulários de aprovação com alçadas diferentes funcionam bem com condicionais: se o valor do pedido supera um limite, exibir o campo de justificativa e o campo de aprovador sênior. Abaixo do limite, o fluxo segue sem esses campos.
Exemplo no onboarding de colaboradores: o campo "Número do CNPJ" só faz sentido quando o tipo de contrato é PJ. Com uma condicional simples ligada ao campo "Tipo de contrato", o CNPJ só aparece quando PJ é selecionado. O formulário fica mais curto para CLT e Estagiário, e os dados de PJ chegam sempre completos.
Campo-gatilho e campo-dependente: a lógica antes da configuração
Antes de abrir o editor de condicionais, vale ter clareza sobre dois conceitos que estruturam qualquer regra:
- Campo-gatilho. O campo cuja resposta determina o que acontece. Sempre um campo já existente no formulário, preenchido antes do campo que será mostrado ou ocultado. Tipos que funcionam como gatilho: seleção única, seleção múltipla, checkbox e campos de texto com valor definido.
- Campo-dependente. O campo que aparece ou desaparece com base na resposta do gatilho. Pode ser qualquer tipo de campo, incluindo campos obrigatórios.
A estrutura lógica de qualquer condicional segue o mesmo modelo: se o campo X tiver o valor Y, então exibir (ou ocultar) o campo Z. Quando esse raciocínio está claro, a configuração é direta.
O campo-gatilho precisa vir antes do campo-dependente na ordem do formulário. Condicionais funcionam de cima para baixo: um campo não pode depender de outro que aparece depois dele no fluxo.
Como nomear condicionais para facilitar manutenção
Processos com muitas condicionais ficam difíceis de manter quando as regras não têm nomes consistentes. O padrão oficial do Pipefy para nomenclatura de condicionais resolve isso em duas variantes:
| Padrão oficial | Ação | Exemplo |
| [Esconder] Campo relacionado = opção | Oculta o campo-dependente quando a condição é verdadeira | [Esconder] Número CNPJ = vazio |
| [Exibir] Campo relacionado = opção | Exibe o campo-dependente quando a condição é verdadeira | [Exibir] Tipo de contrato = PJ |
A lógica é a mesma do nome de fases: o nome descreve o estado resultante, não a intenção do criador. "[Exibir] Tipo de contrato = PJ" comunica imediatamente o que a regra faz para qualquer pessoa que abrir o editor, mesmo sem conhecer o processo.
Boa prática adicional do guia de especialistas: use uma condicional de "esconder tudo" como regra-base de cada fase, e depois adicione condicionais de "exibir" para os campos específicos. Isso evita conflitos de latência quando há muitas regras e facilita a manutenção por quem não conhecia o processo originalmente.
Condicionais com nomes genéricos como "Regra 1" ou "Nova condicional" se tornam ininteligíveis em poucos meses. Nomeie cada regra no momento da criação, antes de salvar.
Condicionais com múltiplos critérios: AND e OR
Quando uma condição única não é suficiente para determinar se um campo deve aparecer, o Pipefy permite combinar múltiplos critérios usando dois operadores lógicos:
| Operador | Quando usar | Exemplo |
| E (AND) | Todas as condições precisam ser verdadeiras ao mesmo tempo | Tipo de contrato = PJ E valor do pedido > R$1.000 → exibir campo de CNPJ e nota fiscal |
| OU (OR) | Qualquer uma das condições é suficiente para disparar a ação | Área = Comercial OU Área = Marketing → exibir campo de aprovação de verba |
O critério para escolher entre AND e OR:
- Use AND quando a exibição do campo só faz sentido se todas as condições forem verdadeiras ao mesmo tempo. AND restringe: quanto mais condições AND, menos casos disparam a regra.
- Use OR quando qualquer uma das condições é suficiente para justificar a exibição do campo. OR amplia: quanto mais condições OR, mais casos disparam a regra.
Antes de combinar operadores, teste com uma condicional simples. A maioria dos casos de uso reais funciona com uma única condição. Condicionais complexas com muitos ANDs e ORs ficam difíceis de manter quando o processo evolui.
Erros comuns e como evitá-los
Condicional criada em ordem invertida. O campo-dependente foi posicionado antes do campo-gatilho no formulário. A regra não funciona. Solução: reordenar os campos antes de configurar a condicional.
Campo obrigatório oculto por condicional gera bloqueio. Se o campo obrigatório estiver oculto para um perfil de preenchedor e a regra não cobrir todos os cenários possíveis, o formulário pode ficar impossível de enviar para alguns casos. Teste todos os caminhos do formulário antes de publicar.
Condicional que oculta em vez de exibir quando o padrão deveria ser exibir. A lógica de "ocultar" como ação padrão tende a criar brechas: se uma nova opção for adicionada ao campo-gatilho no futuro, o campo-dependente aparecerá por padrão. Prefira condicionais de "exibir" com condição positiva sempre que possível.
Condicionais duplicadas para o mesmo campo. Duas regras conflitantes sobre o mesmo campo-dependente geram comportamento imprevisível. Revise as condicionais existentes antes de adicionar uma nova sobre o mesmo campo.
Condicionais não são retroativas. Campos ocultados por condicional em formulários já submetidos não afetam os cards existentes. A regra só vale para preenchimentos futuros. Se você precisar corrigir dados de cards já criados, o ajuste é manual.
Antes de publicar o formulário com condicionais, confirme:
☐ Todos os campos-gatilho vêm antes dos campos-dependentes no formulário
☐ Cada condicional segue o padrão de nomenclatura [Esconder/Exibir] Campo = opção
☐ Campos obrigatórios ocultos por condicional foram testados em todos os caminhos possíveis
☐ A escolha entre AND e OR reflete o critério de negócio, não conveniência técnica
☐ Não há duas condicionais conflitantes sobre o mesmo campo-dependente
☐ O formulário foi testado com pelo menos um preenchimento completo em cada cenário
