Adding rows to a datastore is one of the simplest things a user does on the platform — but the form they fill in is auto-generated, and every field on that form comes from your datastore's configuration. Get the field set right and the form is intuitive; get it wrong and users will struggle.
In the top-right corner of each datastore you will see a green button to allow you to add a new row to the table. When you click this button, a popup will open to allow you to complete the editable fields and save the row to the datastore.
What the form looks like
The platform auto-generates the form based on the fields configured on the datastore. Each field is rendered according to its type:
- Text Boxes get single-line text inputs.
- Text Areas get multi-line text inputs.
- Dropdowns get select boxes (or searchable dropdowns for larger lists).
- Dates get date pickers.
- Date and Times get combined date + time pickers.
- File Uploads get file picker dialogs with drag-and-drop support.
- Tickboxes and Toggle Switches get checkbox or sliding-switch widgets.
- Signatures get a drawable canvas.
- … and so on for all 50+ field types.
Note: The name of the button may be different if the "Name of Rows" field within the datastore settings has been populated. On a datastore where Name of Rows is set to "Customer", the button reads "New Customer" rather than "New Record". It's a small touch but it makes the platform feel much more polished to end users.
Required fields
Fields marked Required must have a value before the row can be saved. Required validation runs both client-side (instant feedback as the user types or tabs out) and server-side (caught at save time even if a malicious user bypasses the client-side check). If a required field is empty, the form refuses to submit and highlights the failing field with an inline error.
Conditional fields
If the form has Conditional Forms or Custom Form Rules attached, some fields appear or disappear as the user fills in others. For example: a Status dropdown with options "Open / Closed / Declined" might reveal a Reason text area only when Declined is picked. The reveal happens instantly as the user changes the trigger field — no page reload needed.
Validation
Beyond required-ness, each field's Validation setting can reject specific values. Common validation rules:
- Email format — rejects strings that aren't valid email addresses.
- URL — rejects strings that aren't valid URLs.
- Postcode — rejects invalid UK postcodes (or whichever locale you configure).
- Regex match — rejects strings that don't match a custom pattern.
- Numeric range — rejects numbers outside a min/max bound.
- Unique — rejects values that already exist on another row in the same column.
Validation failures show inline next to the field. The row can't be saved until every error clears.
After saving
The popup closes and the new row appears in the datastore list. If the datastore has audit mode enabled, the creation is recorded in the audit log automatically — every change tracked with who, when, and what.
If the datastore has a trigger task or a post-insert callback configured (via custom code), it runs after save. Common post-insert actions:
- Send a notification email to relevant parties.
- Update a related row in another datastore (e.g. recalculate a total).
- Push the row to an external system via the API or a Table Sync.
- Generate a document from a template.
Tip: Test the New Record form with a representative user from each role that'll use it before declaring the datastore done. The auto-generated form is generally good, but field order, required-flag placement, and conditional logic can all need tuning based on how real users actually fill it in.