👤 For all users
🔐 Available on all plans
🎯 For those who have already defined field types and want to organize the form
When you reach the stage of organizing form fields, the pipe already has structure: defined phases, chosen field types. The next step is thinking about how this information will appear to whoever fills it in. This decision has more impact than it seems.
The order of fields, what is required, and where each piece of information is collected determine the quality of data that will feed your automations and reports. This article helps you make these choices with clarity.
📖 What you’ll understand here:
Why field order matters
Fields collect data. The order in which they appear guides whoever fills them in.
A well-organized form follows the process logic, not the order in which the fields were created. In employee onboarding, it makes sense for 'Full name' to come before 'Department', for 'Department' to come before 'Responsible buddy', and for 'Responsible buddy' to come before 'Onboarding completion deadline'. Each field contextualizes the next one.
When the sequence doesn’t reflect the process, whoever fills it in needs to interpret what’s being asked at each step. The result tends to be important fields left blank or information entered in the wrong place — not by carelessness, but by lack of context.
Organization criterion: group fields by the natural sequence of information, not by field type. Identification data first, classification data next, deadline and responsibility data last.
Required fields: what makes sense to require and when
Making a field required means the card only advances when that data is filled in. It’s a way to ensure that critical information doesn’t go unnoticed, but it’s worth carefully thinking about which fields receive this configuration.
The most useful question isn’t "is this data important?" — since almost every field is important. The question is: does this data need to exist at the moment the card is created?
Practical rule: a required field in the start form makes sense when the process can’t begin without that information. A required field in an intermediate phase makes sense when the card can’t advance without that data.
It’s worth reviewing phase by phase: required fields positioned before the information is available are the most common cause of cards that get stuck without apparent reason. When configuring required fields in processes with more than one phase, it’s worth checking each phase individually, not just the start form.
Help text: one line that prevents rework
Each field accepts help text, displayed below the title as an instruction for whoever fills it in. It’s a simple resource with direct impact on data quality.
Use help text when the field name leaves room for interpretation. "Department" tends to be clear. "Contract type" can create doubt depending on how many variations the company has and whether whoever fills it in knows the internal terminology.
In onboarding, a useful help text for the 'Contract type' field would be: "Select the hiring regime according to the signed document (Full-time, Contractor, or Intern)." This resolves the doubt before it becomes incorrect data.
A caution: help texts that merely repeat the title in different words don’t add much. "Full name: Enter the employee’s full name" doesn’t guide anyone. Help text has more value when it resolves a real ambiguity.
Start form fields versus phase fields
The start form captures what is necessary to open the card. Phases capture what is necessary to advance the process.
This distinction has a practical consequence: phase fields can ask for information that only exists after the process has started. In onboarding, the first month performance evaluation can’t be filled in on the day the card is created. It belongs to the First Month phase, with Due Date configured and required field activated in that specific phase.
Field configuration in phases works the same way as in the start form: you define title, type, required status, and help text. The difference is that the field only appears to the responsible person when the card reaches that phase.
An option worth knowing: if data collected in the start form needs to be updated throughout the process, activate the "Allow field editing in other phases" option in the field settings. Without this option activated, the data is locked for editing after the card is created.
Applied example: onboarding form organized by blocks
See how an onboarding form becomes more navigable when fields are grouped by process logic:
Employee identification (required fields)
Full name, corporate email, Tax ID
Hiring (required fields)
Contract type, work arrangement, department, job title
Start logistics (required fields)
First day (Date field), responsible buddy (Assignee field)
Additional context (optional fields)
Office location, manager observations
This sequence follows the reasoning of whoever fills it in: first identifies who the person is, then defines the contract, then organizes the arrival. Each block has internal coherence, which makes filling it in more fluid and the data more reliable.
Checklist before publishing the form
Before publishing, confirm that you have defined:
☐ Fields follow the logical process sequence, not the creation order
☐ Required fields in the start form are only those necessary to open the card
☐ Required fields in intermediate phases correspond to what is available at that point in the process
☐ Fields with naming that can create doubt have help text
☐ Fields that may need updating throughout the process have "editing in other phases" activated
☐ Deadline fields use the Due Date type, not simple Date
