A required answer is not necessarily a usable answer. A request can contain a project code with the wrong format, a negative quantity, or a date that has already passed. Catching those mistakes while someone fills out the form is easier than asking the operations team to interpret them later.
This tutorial uses a fictional print workshop to build a focused materials-request form in Airtable and miniExtensions. It checks a project reference, a requested length, and a needed-by date. The example deliberately stops short of approving a request or reserving stock: validation checks the answers against your rules, not whether the business should fulfill the request.
Define the rules before building the form
The workshop lends materials to its project teams. Each request should include a nine-digit project reference, a positive length of material below 100 metres, and a date that is today or later. Decimal lengths are acceptable; 2.5 metres is a legitimate request. These are example policies, not miniExtensions defaults.
Write down the boundary cases first. Is zero allowed? Does “future” include today? Are leading zeroes significant in a project code? Answering those questions now gives you a test plan and prevents the form from enforcing a different policy from the one staff expect.
You will need an Airtable base you can edit, that base connected to miniExtensions, and permission to create and configure a Form. Build the example in a separate practice table before adapting it to a working process. No linked tables are needed for this version: every submission represents one materials request.
Create the Materials Requests table
| Field | Airtable type | Example and purpose |
|---|---|---|
| Request | Single line text; primary field | “Display boards for autumn exhibition” identifies the request for staff. |
| Project Reference | Single line text | “001234567” is an identifier, not a quantity. |
| Length in Metres | Number, with decimal precision suitable for your materials | 2.5; the example accepts fractional metres. |
| Needed By | Date, without a time component | A date chosen by the requester. |
| Notes | Long text, rich text disabled | Optional context, such as material colour. |
Keep Project Reference as text so its format can include leading zeroes. Do not substitute a Number field simply because all the characters are digits. Put the unit in the quantity field’s name rather than asking people to type “metres” alongside the number.
Create a standard miniExtensions Form for this table and include those five fields. miniExtensions uses the Airtable fields directly rather than requiring a separate mapping for each answer. To inspect the imported configuration, open a field, expand Advanced, and look at Airtable Field Settings. That panel is read-only; change the underlying type or format in Airtable. See the field-mapping guide.
Separate required answers from valid answers
Click each of the first four field names in the builder and enable Required at the top left of its settings. Leave Notes optional. Keep the required fields visible: a conditionally hidden field does not enforce its required rule. This visibility requirement is documented in the required-field guide.
“Required” answers the question “did the person supply this?” The additional rules below answer “does it fit our intake policy?” Treat both as separate acceptance criteria, including a blank-field test even when you have also configured a format or range.
Check the project reference format
Open Project Reference, then Field Validation. Add a regular-expression condition using this pattern:
^[0-9]{9}$The anchors describe the entire value, and the middle expression requires nine characters from 0 through 9. For this workshop, “001234567” is valid; “12345678” is too short, while “12345678A” includes a letter. A reference with an added space should fail this deliberately strict format too.
Explain the expected format next to the question: “Enter the nine-digit project reference, including any leading zeroes.” Do not tell people that a rejected code means the project does not exist. This pattern checks its shape only; it does not search a Projects table or establish the submitter’s relationship to a project.
The regular-expression guide explains where regex conditions are supported. Use them for this text identifier, not for Number or Date fields, which need their own controls.
Constrain the requested length
Open Length in Metres and its Field Validation settings. Use the greater than and less than numeric conditions to require a value greater than 0 and less than 100. Both boundaries are part of this example’s policy. Numeric comparison conditions are documented in the field-validation guide.
Use a clear explanation such as “Request more than 0 and less than 100 metres.” That wording intentionally excludes 100. If your real policy allows exactly 100, change the boundary deliberately and add that value to your test plan rather than copying the example unchanged.
This limit is not a live stock check. Two requests for 80 metres each could individually meet this policy. Staff should still review the requests against available material before confirming fulfillment. Leave approval, stock deductions, and notifications out of this initial exercise.
Prevent past needed-by dates
Open Needed By, expand Advanced, and set Date range to today or in the future. This is a date-field setting, not a regex rule. The available ranges and navigation are covered in the date-range guide.
The workshop’s date is a request, not a delivery promise. Label it “Needed By” rather than “Confirmed Delivery.” Check yesterday, today, and tomorrow in the intended end-user environment. If your team works across time zones, include a near-midnight check before rollout so the business interpretation of “today” matches what users see.
For Notes, an optional length cap can keep the request summary manageable. Select the field, open Advanced, then Character Limit, and choose 500 for this example. This control applies to single-line text and non-rich-text long text; see the character-limit guide. Five hundred is an editorial choice for the workshop, not a platform limit.
Test one rule at a time
When the practice form is ready, publish it from the Options menu on its configuration page. Then use Share → Copy URL in the Form Builder and open that URL for the end-user checks. Configuration changes remain in Draft until published again; see the publishing guide and sharing guide.
Start with a complete valid request, then change only one answer for each failure test. Otherwise, one error can hide whether another rule is working. The following are expected outcomes to verify on your form, not a claim that this complete example has been run.
| Change from the valid request | Expected result |
|---|---|
| Reference 001234567; length 2.5; tomorrow’s date | Final submission succeeds; inspect the saved values in Airtable. |
| Clear Project Reference | Required-field check prevents final submission. |
| Reference 12345678 or 12345678A | Format check prevents final submission. |
| Length 0, -1, or 100 | The quantity falls outside the chosen interval. |
| Length 0.5 or 99.5 | The quantity falls inside the chosen interval. |
| Yesterday’s date | The date restriction prevents that choice from being accepted. |
| Today’s date | The date is permitted by the chosen range. |
After each rejection, correct the answer and retry. Check that the correction can succeed, that the leading zeroes remain in the saved reference, and that the quantity is stored as a number. Repeat after reopening the builder and after opening the version intended for end users. Record the test values and results rather than treating saved settings as proof of behavior.
Understand computed fields and draft saves
Attach validation to editable inputs. Computed fields can supply conditions for another field, but cannot themselves be edited to correct an error; read-only fields do not enforce field-validation rules. Direct field-to-field comparison is not supported by Field Validation. The documented alternative is an Airtable comparison formula used by validation on an editable field, with Save & Continue enabled. See the comparison and field-type limitations.
For example, comparing Requested Length with Approved Allowance would be a separate extension of this exercise. Define what should happen when either is blank, check the formula result in Airtable, and only then connect it to the form rule. After changing an input, save and verify the recomputed result before trusting it; do not assume an earlier displayed calculation reflects the latest edit.
There is an important tradeoff: Save & Continue creates or updates an Airtable record before final submission. Required-field and validation checks are applied at final submission, not those intermediate saves. Use the optional final-submission checkbox to distinguish drafts from completed requests, and design any later processing around that distinction. The Save & Continue guide explains this lifecycle. Formula fields can be displayed while editing a record, or during creation with Save & Continue; see formula visibility.
Keep the first version easy to explain
A good intake form should tell requesters what to correct without requiring them to understand your database. Keep the three policies visible, test their boundaries, and separate a valid submission from a staff decision. Once that small workflow is dependable, add more complex comparisons only where they solve a real review problem.
