Skip to main content
Back to Blog
forms layout slots builder

Custom Form Layouts with Slots

Swifty Team Mar 11, 2026 3 min read

A form that lists every field in a single vertical column is functional, but rarely optimal. Certain fields belong next to each other — start date and end date, first name and last name, quantity and unit price. Logical sections help users navigate forms with many fields. Two-column layouts make better use of wide screens.

Form layout slots give you precise control over where each field appears within a form.

Slots Define the Layout Grid

A form layout is built from slots — named positions in a grid. You define the grid: one column, two columns, three columns, or mixed (some rows spanning full width, others split). Each slot can hold one or more fields.

The form renders fields in the positions you specify. Fields not assigned to a slot appear at the bottom in default single-column order — no fields are ever lost due to layout configuration.

Assign Fields to Slots

In the builder's form editor, open the layout view. The current grid is shown with its slots. Drag fields from the field list on the left into the desired slots. A slot can hold multiple fields stacked vertically within its column.

The visual arrangement in the layout editor matches what users will see in the rendered form. What you design is what they get.

Grouped Sections

Related fields can be visually grouped using labeled section headers. A "Billing" section groups billing fields. A "Delivery" section groups delivery fields. Sections can be collapsible — useful for optional or advanced fields that most users can skip.

Sections are layout elements, not data structures. They organize the visual presentation without affecting the underlying data model.

Responsive Behavior

Multi-column form layouts respond to screen size. A three-column layout on desktop becomes a single column on mobile. Field ordering in the collapsed layout follows the reading order of the desktop layout — left-to-right, top-to-bottom.

The responsive behavior is automatic. You design for desktop; the form adapts to mobile without additional configuration.

Consistent with the Object Definition

Form layout slots don't override the field definitions. A field marked required in the object definition remains required regardless of where it's placed in the form. Validation rules, help text, and options all come from the definition and persist across layout changes.

Changing the layout is purely presentational — it never affects data integrity or validation behavior.

Related posts

Composed Data Sources

Chain and relate data sources for rich dashboards — compose complex data views from simpler sources without writing code.

Computed Expressions

Transform data with template expressions and built-in functions — format, combine, and derive values from your data without code.

Cross-Source Data Joins

Combine data from multiple sources in one view — join records from your database with data from external services using a shared key.