👤 For pipe administrators
🔐 Available on Business, Enterprise, and Unlimited plans
🎯 For those who already master conditionals and want to apply them in a complete form
A form with fifteen fields shown to everyone collects fifteen responses, but generates inconsistent data: blank fields that shouldn’t be blank, generic responses where specificity is needed, and fillers who give up halfway.
The difference between a form that works and one that merely exists is in one question: who fills in this field and in what situation? Answering that before building is what transforms a questionnaire into structured data entry for the process.
📖 What you’ll learn here:
What makes a form smart
Intelligence in a form isn’t the quantity of conditionals. It’s precision: the filler sees exactly what they need to fill in for their case, without noise, without ambiguity.
Three indicators that a form needs revision:
- The team receives cards with required fields blank — someone forced submission without having the information
- Free text fields contain responses that should be in select fields — the data is not filterable or actionable by automation
- Fillers frequently ask for help with the form — the form is more complex than the filler’s context requires
The first two are structure problems. The third is a UX problem. Both have solutions before configuration: at the moment you map the flow.
Mapping the flow before building
Four questions define the structure of any form before opening the editor:
| Design question | What it reveals | Application in onboarding |
| Who fills it in? | Defines the vocabulary and expected level of detail | HR fills it in internally. Technical language is acceptable. |
| Who reads it afterward? | Defines which fields need to be self-explanatory | Manager reads to approve. Status fields need to be clear without context. |
| What varies by profile? | Maps where conditionals are needed | Full-time, Contractor, and Intern employees have distinct documentation. Each profile sees their own set of fields. |
| What feeds automations? | Identifies fields that need to be select, not free text | "Contract type" needs to be single select to trigger automation by type. |
The fourth question is the most ignored and the one that causes the most rework. Free text fields don’t trigger automations safely. If the form will feed a rule like "if contract type = Contractor, send instructions email," the field needs to be single select, not text where someone can type "contractor," "CONTRACTOR," "freelance," or "contract worker" indistinctly.
Decide the field type thinking about who will use the data, not who will fill it in. The filler finds free text easier. The process works better with selection. When in doubt, prioritize the process.
Complete example: employee onboarding
Applying the framework to the onboarding process, the process entry form has three distinct profiles: Full-time, Contractor, and Intern. Each profile generates a different chain of fields.
The branching structure from a single trigger field:
Trigger field: Contract type (single select: Full-time / Contractor / Intern)
If Full-time: show employment record, bank for deposit, benefits fields.
If Contractor: show Company Tax ID, company name, banking details for invoice payment fields.
If Intern: show educational institution, internship supervisor, expected completion date fields.
Fields common to all profiles (no conditional): full name, job title, start date, responsible manager, required equipment.
The result: the form has all the fields needed for the three profiles, but each filler only sees theirs. A full-time employee never sees the Company Tax ID field. A contractor never sees the employment record field.
More importantly: all select fields that feed automations are correct by construction. "Contract type" being single select ensures that the email-by-type automation never encounters an unexpected value.
UX best practices for internal forms
Internal forms have a specific trap: the team assumes everyone knows what to fill in because "everyone knows the process." In practice, turnover, partial context, and rush create the same problem as external forms: incorrect or incomplete filling.
Fields with help text. Use the description field to explain what’s expected, not just what the field is. "Contract type" as a label doesn’t help someone who has questions about the difference between contractor and freelancer in the company’s context.
Order that reflects the reasoning sequence. The trigger field always before the dependents. But beyond that: group fields by theme. Personal data together, contractual data together, equipment together. The logical sequence reduces the cognitive load of filling in the form.
Required fields with criteria. Marking everything as required is the fastest path to abandoned forms or forms filled with invalid data just to pass validation. Required means: the process doesn’t advance without this information. If it does, the field isn’t required.
Test the form with someone who didn’t participate in building it before launching. What seems obvious to whoever built it is rarely obvious to whoever fills it in for the first time. A test round with a team member reveals most UX problems before reaching the real process.
Before publishing the form, confirm:
☐ The four design questions were answered before opening the editor
☐ Fields that feed automations are select, not free text
☐ Required fields are only those that actually block the process
☐ Field order reflects the filler’s reasoning sequence
☐ The form was tested by someone who didn’t participate in building it
