Design rows, not coordinates
The parent form uses structured rows. Each field row must contain between one and three fields, giving the runtime enough information to render a consistent desktop and responsive layout.
- Use one column for long narration, terms or HTML content.
- Use two columns for normal paired business fields.
- Use three columns for compact dates, rates, categories or amounts.
- Keep related values together and follow the order users complete the process.
Only available fields can be placed
A parent field must be configured for display in the form before Form Designer can place it. Hidden, server-filled or otherwise unavailable fields do not belong in visual rows.
If a mandatory field is not visible, it must have a valid automatic, default, lookup/autofill or server-authoritative source. Otherwise Create will fail even if the form looks complete.
Child line-item sections
An attached submodule appears as a complete child block. Place that block in the desired sequence between parent rows; do not attempt to place its individual columns in the parent grid.
- Put identification and date fields before the child table.
- Put totals, narration and terms after the child table when that follows the business workflow.
- Keep visual separation around the table so following labels do not touch its border.
- Check mobile/responsive stacking after arranging the desktop form.
Practical layout review
- 01Scan in entry order
The natural tab/reading order should match how a user receives the source document.
- 02Balance each row
Avoid one tiny control beside a very long textarea or description.
- 03Test Create and Edit
Verify labels, lookup restoration, child rows, validation messages and calculated values.
- 04Regenerate Forms
When editing a generated module, use the tab’s regeneration action so the changed layout reaches the runtime forms.