👤 For pipe admins and people who design experiences in Interfaces
🔐 Field conditionals are available on Business, Enterprise, and Unlimited plans
🎯 For anyone planning which questions each process interaction needs
One person needs to request equipment, another needs to purchase a service, and a manager only joins to review requests. When every participant receives the same set of information, the team has to explain through separate messages what each person should complete or review.
By the end of this article, you will know where to plan conditional questions and when a form is the right way to collect a contribution from someone coming through an Interface. The logic belongs to the pipe form. Choose the experience by separating three tasks: opening a request, reviewing requests, and contributing to an existing card.
📖 What you will understand here:
Identify what needs to change in the experience
Before defining a condition, describe the outcome you need. Consider three needs in a purchasing process.
Varying questions when a request is submitted. Someone requesting equipment needs to provide a technical specification. Someone requesting a service needs to describe the work required. The decision concerns the information needed to understand each request.
Selecting requests for review. A manager needs to find the requests they will assess. The decision concerns which records belong in that view.
Providing context for one request. When opening a request, someone needs to review information or contribute an answer. The decision concerns the context required for that contribution.
💡 Write the need as a concrete sentence: “Ask for a specification when the request is for equipment” or “Bring together the requests I need to review.” These statements help you choose which rule to evaluate.
In Interfaces, filters select records. Record details let you choose fields and control whether they can be edited. A question that appears based on an earlier answer is a field conditional. Make this distinction before applying the same reasoning to every interaction.
🔗 Learn more: review pages, data, and record details in Getting started with interfaces.
Design questions around the process decision
Imagine a sample process that receives requests for equipment and services. Description and business purpose apply to both. A technical specification is relevant to an equipment request.
In this example, “Request type” could be a Dropdown Select field with the options “Equipment” and “Service.” “Technical specification” could be a Long Text field. These labels illustrate the process; adapt them to your team's vocabulary.
Describe both sides of the rule: show the specification when Equipment is selected, and hide that question when the condition is not met. A name such as “[Show] Request type = Equipment” makes the criterion easier to identify.
Before building, ask why each piece of information is necessary. If an answer does not affect the assessment or support a later action, consider collecting it at another point. Keep shared questions available and introduce specific questions where the process needs them.
For more on planning questions by participant profile, read Formulários inteligentes com lógica condicional. This Community article is in Portuguese and connects the respondent, profile variations, and the people who use the information afterward.
🔗 Learn more: use the official guide to show or hide form fields based on answers.
Connect the rule to the intended interaction
Field conditionals are configured in the pipe form. An Interface organizes how people access and view information. First identify which form should receive the answer, then decide how the participant will reach it.
For a new request, plan the Start Form. In the purchasing example, this is where the requester selects Equipment or Service and provides the information needed to start the review. Its conditionals determine which questions are relevant at intake.
For a contribution to an existing request, consider a Phase Form. Imagine a manager who needs to record a decision and explain why a purchase was declined. The conditional belongs to that phase's form. When the Interface directs the person to that form, they respond in the form, using the rules configured there.
This choice is useful when the contribution requires questions that vary with an answer. To decide when and how that participation should happen, read When to use a Phase Form in Pipefy.
⚠ Making an interaction available through an Interface does not establish that every presentation automatically inherits the pipe's conditionals. Distinguish accessing a form from editing fields in record details.
If a manager only opens a card's details to edit information, do not treat that layout as a guarantee that another question will appear dynamically after an answer. When conditional questions are essential to the contribution, keep that collection in the relevant form.
Separate visibility, editing, and access
Review the design by answering three questions: which requests should this person find, what information do they need to review, and what data should they be allowed to change?
In purchasing, a manager may need to review the business purpose and provide a decision. The requester may only need to follow progress. Assess each role according to the work the person needs to do.
In Interface record details, you choose which fields appear in the layout and which can be edited. Changes to editable fields update the original pipe or database. Treat these presentation and editing controls separately from a form’s conditional logic.
💡 Showing a question, allowing an edit, and granting access are separate decisions. Review all three using the actual participant's role.
Hiding a question to simplify a form does not replace an access review. If the process contains sensitive information, check the person's complete experience, including what they can view and change.
Test the experience across different scenarios
Choose a representative request and test it with someone who did not design the experience. Check whether they understand what to do without receiving a separate explanation.
- Present an Equipment scenario and observe what information the person understands they need to provide.
- Repeat with Service and check whether the questions match that request.
- Change the selection after completing a specific answer and observe what happens to the fields and their data.
- Review the resulting card, then assess access and editing separately.
Include required fields and previously completed answers in the test. Record what happens before deciding how to handle exceptions. Do not assume that hiding a field clears its content or changes whether it is required.
Then follow the actual access path through the Interface. If it leads to a form, test the answers in that form. If the contribution happens in record details, review the layout and editing permissions without expecting them to reproduce the form's conditionals automatically.
Choose one request to start with
Pick an intake scenario that often needs extra explanation. Write down who participates, which answer changes the questions, what information applies to everyone, and which decision depends on the data. Then choose the interaction and validate the scenario with a participant.
To explore more page designs and use cases, watch Masterclass: Interfaces de Usuário com o Pipefy on Pipefy Academy. This recording is in Portuguese. Connect the scenarios presented with the request you have just mapped.
Before moving on, confirm that you understand:
☐ The difference between varying questions, filtering records, and presenting details
☐ That conditionals belong to the Start Form or Phase Form
☐ Why visibility, editing, and access require separate decisions
☐ How to test the path from the Interface to the participant's intended interaction
Ready to plan which questions each profile needs to answer? → Formulários inteligentes com lógica condicional, a Community article in Portuguese
