Looking up real records on a form

When to use entity pickers

Entity pickers let users pick a value from real data stored elsewhere in the system — your employees, projects, suppliers, cost codes and so on — rather than typing it in by hand or picking from a fixed dropdown you have to maintain.

Use them whenever you want the form to stay connected to the rest of your company data. For example:

• An incident report should record which employee was involved, not just a typed-in name
• A delivery note should pick the supplier from your supplier list so you can later report on deliveries by supplier
• A daywork sheet should pick the cost code so the time can be allocated correctly
• A site visit log should record which project the visit was for

The big advantage is that the answers stay accurate — if you ever need to filter, group or report on the submissions later, the data lines up cleanly with the rest of the system.

The eight pickers

You'll find these in the field palette of the Form Builder under "Entity":

What the user sees

When someone fills in a form with one of these fields, they'll see a searchable dropdown. They start typing, the system finds matching records as they type, and they pick the one they want.

This is much faster than scrolling a long list, and it scales to thousands of records — useful when (for example) your company has hundreds of employees or suppliers.

Settings

Entity pickers are simple to set up — there's no list of choices to maintain, because the choices come from your live data automatically.

The settings you can change:

• Label — the question the user is answering
• Helper text — a small description below the field
• Required — tick to force the user to pick something before submitting

That's it. The list of choices keeps itself up to date — if you add a new employee or supplier next week, they'll show up in the picker the moment they exist.

Real-world examples

A few patterns that turn up again and again on construction forms:

• Incident report — an Employee picker for the person involved, a Project picker for the project, and a Subcontractor picker (with conditional logic) only if the person works for a subcontractor
• Delivery note — a Supplier picker for the supplier, a Project picker for where the goods went, and a Cost code picker for the budget line
• Daywork sheet — a Project picker, a Cost code picker, and an Employee picker (in a repeating section so you can list everyone who worked the daywork)
• Site visit log — a Client picker for who you visited and an Employee picker for who from your team attended

Picker versus dropdown

Use an entity picker when:

• The choices are real records elsewhere in the system
• You want to be able to filter or report on submissions by employee, supplier or project later
• The list is large or grows over time
• You need the answers to stay accurate as records are added or renamed

Use a regular Dropdown when:

• The choices are arbitrary and specific to this form (like "weather conditions")
• The list is small (under twenty) and unlikely to change
• You want full control over the option text

Combining with conditional logic

Entity pickers work nicely with conditional logic. A common pattern is to show a follow-up question only if a particular employee or supplier is picked — for example, asking for a subcontractor reference only when a Subcontractor picker actually has a value.

Next steps

• Adding basic fields — for text, number and date inputs.
• Adding dropdowns and checkboxes — for fixed-list choices.
• Showing fields only when needed — for using picker values to drive show/hide conditions.