Choose a Field's Control

Goal

Choose which input control a field uses on a form — a text area, a checkbox, a toggle, a date picker, a lookup, or a dropdown — and configure that control's properties, such as a date's display format or a toggle's Yes/No labels.

Prerequisites

• You are signed in as a maker with permission to edit the form's solution.
• The field already exists on the entity (see Add a Field to an Entity) and is placed on the form (see Create a Form).

Steps

1. Open the entity in Tables and go to the Forms tab.
2. Select the form to open the Form Designer.
3. Select the placed field on the form canvas. The Properties panel shows that field's settings.
4. Open the Control dropdown and choose a control:
   • Default for field type — the platform picks the usual input for the field's data type. This is the starting point for every field.
   • Text — a single-line text box.
   • Text Area — a multi-line text box.
   • Check — a checkbox.
   • Toggle — a switch.
   • Date, Date and Time, Time — a date and/or time picker.
   • Lookup — a picker for a record in another table.
   • Dropdown — a selection from a fixed list of options.
5. Set the control's properties, which appear under the Control dropdown and depend on the control chosen:
   • Text Area — Rows, how tall the box is.
   • Date, Date and Time, Time (and their Persian twins) — Date format, how the value is displayed. Use yyyy or yy for the year, MMMM for the month's name, MM for its number, dd for the day, HH for the hour, mm for minutes, and ss for seconds; any other characters are shown as typed. For example, dd/MM/yyyy shows 4 March 2026 as 04/03/2026. A Time control takes a format too — HH:mm or HH:mm:ss — and the box's placeholder shows the shape that suits the control. Leave it empty to use the app-level format (Settings → Calendar → Date formats).
   • Check, Toggle — Yes label and No label, the words shown beside the control for each state.
   • Lookup — Lookup table, the table whose records the field points at, chosen from a list of the environment's tables; Lookup view, which decides the columns shown in the picker (leave it on Default (resolved automatically) unless this one field should show different columns from the table's usual picker); Rows to show, how many records the picker offers at once (leave it empty for the default of 10; raise it — 50, 100, up to 500 — for a table where a user needs to scroll a long list rather than keep typing); and, once the target table's fields have loaded, Name field, Second line field, and Picture field — which field is each candidate's name, the smaller line beneath it, and its picture. Each is left on Default (table's own) unless this one lookup should read differently from the table's usual choice. The picture picker offers only file and picture fields.
   • Dropdown — Options, a comma-separated list of the choices to offer (for example, Draft, Sent, Paid).
6. Select Save.

File and picture fields choose themselves

A file or picture field always renders the platform's file control, whatever the Control dropdown says. There is nothing to choose between: the column holds a reference to a stored file rather than text a user could type, so a text box over one would only invite a value the platform rejects.

What the user sees is covered by Add a file or picture to a record. Two things are worth knowing when you design the form: a file is stored when the form is saved, like every other change on it — including on a record that already exists — and a picture field accepts only images and caps them smaller than a file field, because a picture on a form is meant to be shown rather than archived.

A picture field has one property worth setting: Picture size — Small (the default, an avatar-sized thumbnail), Medium, or Large. Choose Large for a photo you want shown prominently — a person's portrait, a product shot — and leave it Small for an icon-sized image such as a flag or a logo. The size changes only how the picture is displayed; it does not change the stored image.

How the Lookup control behaves

A lookup field stores the id of a record in the related table — an identifier no one could reasonably remember. So the control never shows one. A user selects the field, types part of the record's name, and picks from the matches; the field then shows that record's name. Selecting the field without typing offers the first records, so there is always something to pick from.

The name shown is the related table's primary field by default — or, when this control sets a Name field, whichever field you chose there. If that field is empty on a record, its id is shown instead — not to be typed, but so two otherwise blank rows can be told apart.

Overriding the name, second line, and picture per control. A lookup normally shows what the table decided — its primary field as the name, its nominated field as the second line, its record image as the picture — so every lookup of that table reads the same. Set Name field, Second line field, or Picture field on this control when one lookup should differ: an "Approver" lookup that reads by email while everywhere else reads by name, say. These change only this control; the table's own choices, and every other lookup, are untouched. An override that names a field that no longer exists quietly falls back to the table's choice rather than blanking the line.

The table searched is the control's Lookup table property when set, and otherwise the table the field's relationship already points at. A lookup field with neither says so on the form rather than falling back to a box that would invite typing an id.

The magnifier at the end of the box is always there, whether or not a record is selected — it marks the field as a lookup rather than a text box, and it opens Advanced Lookup.

Advanced Lookup

Typing in the box opens the quick picker beneath it — a few records at a time, two lines each. The magnifier opens Advanced Lookup instead: the same records as a full table, with every column the lookup view chose in a column of its own, and Back/Next through the whole table rather than just the first matches. Use the box when you know roughly what the record is called, and the magnifier when you need to look around.

Searching inside the dialog starts again from the first page, and selecting a row picks that record and closes the dialog.

Each record in the picker is shown on two lines: its name, and — when the related table has a lookup view — that view's other columns beneath it, so two records with the same name can be told apart. Which columns typing searches is set separately, by a quick find view; with neither authored, the picker shows and searches the primary field alone. See Create a Lookup View and Choose Which Columns a Search Matches.

What happens behind the scenes

The chosen control and its properties are saved as part of the form, so they travel with the form when the solution is exported and imported into another environment. When a user opens the form, the control chosen here is the one they see and use.

A property that does not apply to the current control is hidden rather than deleted. If a date field is switched to Text and later back to Date, the date format configured earlier is still there.

A Custom Control bound to the same field takes precedence over the control chosen here (see Bind a Custom Control to a Field).

How a date field reads

The Date format property decides how the value is written wherever it is shown — in the picker's own box, and on a field the user cannot edit. That includes the platform's own Created On and Modified On stamps: place one on a form, give it a date control and a format, and it reads the same way every other date on the form does.

Set it once for the whole app instead. Settings → Calendar → Date formats holds two sets of three patterns — date, date-and-time and time — one set for the Gregorian calendar and one for the Persian calendar. Every control that names no format of its own uses the matching one. Formatting each placement by hand means one you forget reads differently from the rest, which is exactly what this avoids. A format set on a placement still wins, so it stays the way to make one field an exception. Leave a box empty and dates read in that calendar's own default (yyyy/MM/dd HH:mm in Gregorian, a long date such as ۱۲ اردیبهشت ۱۴۰۵ in Persian).

Which set applies follows the calendar the date is actually shown in, not the app's default. So on a form mixing both — a Persian-pinned field beside a Gregorian one — each reads with its own set. The two are independent on purpose: the Persian boxes do not fall back to the Gregorian ones, so changing how Gregorian dates read never quietly changes how Persian ones do. That independence is the reason there are two sets rather than one.

The same settings apply in views, not only on forms: a date column whose designer set no format of its own reads with the tenant's pattern, exactly as the same field does on a form.

The calendar a date is written in is a separate choice, and naming a control settles it. Leave the control on Default and the field follows the app's calendar setting (Settings → Calendar), so one switch changes every date in the app. Name one and that choice wins, in both directions: Persian Date and Persian Date and Time pin the field to the Persian calendar whatever the setting says, and plain Date or Date and Time pin it to Gregorian even in an app set to Persian — for the field that must always be read one particular way. Either way the stored value is the same instant; only how it is written changes. In the Persian calendar a format of d MMMM yyyy reads ۱۲ اردیبهشت ۱۴۰۵.

Persian Time is one of them, and it is worth saying what it changes, because a time does not have a calendar the way a date does: 09:30 is 09:30 in either. What it changes is the digits — a Persian time reads ۰۹:۳۰ — and which format it takes, the Persian time format from Settings rather than the Gregorian one. Pick it for a time that sits beside Persian dates; pick plain Time for one that should read in Latin digits whatever the app language.

Troubleshooting

• A read-only or system field ignores the format. — it does not: it uses the format of the control the field is placed with. A field placed without choosing a control uses its data type's default control, then the app-level format for that kind, then that calendar's default (yyyy/MM/dd HH:mm in Gregorian, a long date in Persian). Set Date format on the placement to change it.
• The app is set to Persian and a field I set to Date and Time still shows Jalali. — it no longer does. A named control pins its own calendar; only Default follows Settings → Calendar. If a field is still following the setting, its control is on Default — name the one you want.
• A picture field's control cannot be changed. — correct, and the panel now says so rather than offering a dropdown. The platform stores the file itself, so there is no other control it could render with.
• A time moves after I save and refresh. — fixed. A time used to be sent without its date, leaving the server to assume one, and it was read back an offset away. It now travels as the whole moment, exactly as a date-and-time does.
• A Time control's format does nothing. — it does now. A time is written with HH, mm, and ss; a pattern made only of date tokens has nothing of a time to render.
• A date shows as typed rather than formatted. — the stored value is not a date the platform can read. It is shown exactly as stored rather than blanked, so you can see what is actually there.
• The Lookup table list is empty. — the environment has no other tables to point at yet. Create the table you want to look up first.
• A lookup on the form says "This field has no related table set". — the field has no relationship target and the control has no Lookup table property. Set one, or create the relationship the field is meant to follow.
• A lookup finds no records however I search. — the search matches the related table's primary field only. Searching for a value held in some other field of that record will not match it.
• A lookup says "Could not search the related table". — the search request failed, or the signed-in user has no read access to the related table. Confirm the user's role grants read on that table.
• The Dropdown shows no choices. — no options are configured. Enter them in the Options property, separated by commas.
• A field still shows the old input after saving. — the form was saved but the app is showing a cached form. Reopen the record.

Related scenarios

• Create a Form.
• Add a Field to an Entity.
• Bind a Custom Control to a Field.