Fields, layout, and conditional logic

Good forms ask only for information that is needed, use the correct field type, and reveal complexity gradually. This guide explains how to choose fields, arrange them, validate responses, and create conditional branches.

Choose the right field

Labels, placeholders, and help

Every visible input should have a meaningful label. A placeholder is only an example and disappears when the visitor types, so it must not be the only instruction.

Use help text to explain:

• why the information is requested;
• the expected format;
• an important limit;
• how the information will be used.

Mark a field required only when the form cannot be processed without it.

Field names

The field name identifies a value in notifications, conditions, webhooks, and post mappings. Use lowercase descriptive names without spaces, such as:

• first_name
• contact_email
• booking_date
• project_type

Changing a field name after building notifications or automations can break those references. Review every dependent setting when a name must change.

Steps, rows, and columns

• Step groups one stage of a multi-step form.
• Row groups fields horizontally.
• Column defines each field area's width at different screen sizes.
• Field collects or displays content.

Use one column on mobile unless two very short related controls remain comfortable side by side. Keep the visual order the same as the keyboard and mobile reading order.

Validation

POM Forms applies the validation that belongs to each field type and can apply field-specific rules. Write messages that tell the visitor how to correct the problem.

For example:

• “Enter a valid email address” is better than “Invalid value”.
• “Choose at least one service” is better than “Required”.

Always verify validation while signed out. Browser autofill and saved administrator data can hide problems during testing.

Conditional logic

Conditional logic can show or hide a field based on earlier answers. A condition includes:

• an action, such as show or hide;
• the field to evaluate;
• the comparison;
• the value that activates the rule.

Example: show a Company name field only when Customer type equals Business.

Build a clear conditional branch

1. Create the controlling choice field first.
2. Give each option a stable value and readable label.
3. Add the dependent field.
4. Enable conditional logic on the dependent field.
5. Choose show or hide and define the rule.
6. Save the form.
7. Test every controlling option, including returning to a previous choice.

Avoid hidden required-field traps

A hidden field must not prevent submission when its branch is inactive. Test this explicitly:

1. activate the branch and enter a value;
2. change the controlling answer so the field becomes hidden;
3. submit the form;
4. confirm that the hidden value is handled as intended.

POM Forms removes values and uploads belonging to hidden conditional fields before storage, notification delivery, webhooks, and post creation.

Accessibility checklist

• Keep labels visible.
• Group related choices with a clear question.
• Do not communicate required state or errors by color alone.
• Keep help and error text close to the field.
• Ensure keyboard focus follows the visual order.
• Avoid unexpected automatic submission when a choice changes.
• Use headings to divide long forms into understandable sections.

Related guides

• Create your first form
• Multi-step forms and submission behavior
• Forms troubleshooting