👤 For pipe administrators
🔐 Available on Business, Enterprise, and Unlimited plans
🎯 For those who already have fields created and want to make the form smarter
Long forms with fields that don’t apply to all cases create two practical problems: incomplete filling and inconsistent data. Whoever fills it in ignores what they don’t understand. Whoever analyzes receives blank fields without knowing whether it was oversight or genuinely not applicable.
Conditional logic solves this by showing each field only when it’s relevant to that specific context. The result isn’t just a cleaner form: it’s a process with fewer entry errors, more reliable data, and automations that work because they always find the fields correctly filled in.
The perspective shift: a conditional isn’t a trick to hide fields. It’s filling experience design applied to the process.
📖 What you’ll learn here:
When conditional logic solves a real problem
Not every form needs conditionals. The criterion for using them is simple: is there any field that only makes sense to be filled in depending on the answer to a previous field?
Three situations where conditionals have direct impact on data quality:
Flows with different filler profiles. An onboarding process that handles full-time, contractor, and intern employees has completely distinct documentation for each type. Displaying all fields for all profiles creates confusion and blank fields. With conditionals, each contract type sees only the fields for their flow.
Required fields that don’t apply to everyone. Pipefy allows marking a field as required. If this field appears for everyone but only applies to some, the person who doesn’t have the information gets blocked. The conditional solves it: the required field only appears when the condition that makes it relevant is met.
Progressive information collection. Approval forms with different thresholds work well with conditionals: if the request value exceeds a limit, display the justification field and the senior approver field. Below the limit, the flow continues without these fields.
Example in employee onboarding: the 'Tax ID Number' field only makes sense when the contract type is Contractor. With a simple conditional linked to the 'Contract type' field, the Tax ID only appears when Contractor is selected. The form becomes shorter for CLT (regular employees) and Interns, and the Contractor data always arrives complete.
Trigger field and dependent field: the logic before configuration
Before opening the conditionals editor, it’s worth being clear about two concepts that structure any rule:
Trigger field. The field whose answer determines what happens. Always a field already existing in the form, filled in before the field that will be shown or hidden. Types that work as triggers: single select, multiple select, checkbox, and text fields with a defined value.
Dependent field. The field that appears or disappears based on the trigger’s answer. It can be any field type, including required fields.
The logical structure of any conditional follows the same model: if field X has value Y, then display (or hide) field Z. When this reasoning is clear, configuration is straightforward.
The trigger field must come before the dependent field in the form order. Conditionals work top-down: a field cannot depend on another that appears after it in the flow.
How to name conditionals to facilitate maintenance
Processes with many conditionals become difficult to maintain when the rules don’t have consistent names. Pipefy’s official standard for conditional naming resolves this in two variants:
| Official standard | Action | Example |
| [Hide] Related field = option | Hides the dependent field when the condition is true | [Hide] Tax ID Number = empty |
| [Show] Related field = option | Shows the dependent field when the condition is true | [Show] Contract type = Contractor |
The logic is the same as phase names: the name describes the resulting state, not the creator’s intention. "[Show] Contract type = Contractor" immediately communicates what the rule does to anyone who opens the editor, even without knowing the process.
Additional best practice from the specialists guide: use a "hide all" conditional as the base rule for each phase, then add "show" conditionals for specific fields. This avoids latency conflicts when there are many rules and facilitates maintenance by those who didn’t originally know the process.
Conditionals with generic names like "Rule 1" or "New conditional" become unintelligible within a few months. Name each rule at creation time, before saving.
Conditionals with multiple criteria: AND and OR
When a single condition isn’t enough to determine whether a field should appear, Pipefy allows combining multiple criteria using two logical operators:
| Operator | When to use | Example |
| AND | All conditions must be true at the same time | Contract type = Contractor AND request value > $1,000 → show Tax ID and invoice fields |
| OR | Any one of the conditions is sufficient to trigger the action | Area = Sales OR Area = Marketing → show budget approval field |
The criterion for choosing between AND and OR:
Use AND when showing the field only makes sense if all conditions are true at the same time. AND restricts: the more AND conditions, the fewer cases trigger the rule.
Use OR when any one of the conditions is sufficient to justify showing the field. OR expands: the more OR conditions, the more cases trigger the rule.
Before combining operators, test with a simple conditional. Most real use cases work with a single condition. Complex conditionals with many ANDs and ORs become difficult to maintain as the process evolves.
Conditionals in databases: what changes
Databases have a different structure from pipe forms: they are shared data tables that feed multiple processes. Conditionals in databases follow the same trigger-field and dependent-field logic, but with some relevant practical differences.
- Conditionals in databases affect the display and filling of records in that database, not the forms of the pipes that consume it.
- Changes to the database structure can break conditionals configured in the pipes that reference it. Whenever a database field is renamed or removed, check the dependent conditionals.
- Database permissions are independent of pipe permissions. A pipe administrator doesn’t automatically have permission to edit database conditionals.
Common errors and how to avoid them
Conditional created in reverse order. The dependent field was positioned before the trigger field in the form. The rule doesn’t work. Solution: reorder the fields before configuring the conditional.
Required field hidden by conditional creates a block. If the required field is hidden for a filler profile and the rule doesn’t cover all possible scenarios, the form may become impossible to submit for some cases. Test all form paths before publishing.
Conditional that hides instead of shows when the default should be to show. The "hide" logic as the default action tends to create gaps: if a new option is added to the trigger field in the future, the dependent field will appear by default. Prefer "show" conditionals with a positive condition whenever possible.
Duplicate conditionals for the same field. Two conflicting rules about the same dependent field generate unpredictable behavior. Review existing conditionals before adding a new one about the same field.
Conditionals are not retroactive. Fields hidden by a conditional in already submitted forms don’t affect existing cards. The rule only applies to future submissions. If you need to correct data in already created cards, the adjustment is manual.
Before publishing the form with conditionals, confirm:
☐ All trigger fields come before dependent fields in the form
☐ Required fields hidden by conditionals have been tested in all possible paths
☐ The choice between AND and OR reflects the business criterion, not technical convenience
☐ There are no two conflicting conditionals about the same dependent field
☐ The form has been tested with at least one complete submission in each scenario
