A request often needs two different experiences: a draft that its author can revise, and a submitted version that they can read without changing the original answers. The important design question is not simply whether a record has been submitted. It is which fields should remain editable, who controls the status, and which route the requester uses to reopen the record.
This walkthrough builds a small example with two text fields. It uses the documented miniExtensions workaround for conditional editing: show an editable field in Draft, then show a formula-based copy in other states. It does not make the Airtable record immutable or establish a complete access-control policy.
Choose the behavior you actually need
There are three related, but different, requirements:
- Always read-only: use a field’s ordinary Read-only setting when it should never accept edits in that form. miniExtensions describes this as letting people see existing values without changing them.
- A confirmation screen: show submitted answers immediately after submission, without deciding how a later visit should behave.
- Status-dependent editing: let an existing record’s Draft answers be edited, but show their values without editable controls after an internal status change.
This article implements the third requirement. The read-only field explanation covers the first. For a confirmation only, the documented route is Form Builder → gear icon → Submission Actions → After Form Submission → Show read-only version of record after submission. That option requires login to be disabled. The confirmation guide also describes a separate read-only form for more customized confirmation experiences.
Prepare a deliberately small example
Imagine a fictional training team collecting workshop proposals. A coordinator creates each request, assigns Draft, and sends the author the appropriate editing route. After checking that the author has finished, the coordinator changes the status to Submitted in Airtable. This manual handoff is intentional: the example does not silently assume a submit button changes a business-status field.
You need permission to add fields to the base and configure the connected miniExtensions form. Use a test table or harmless example records before adapting an operational workflow. Start with one Workshop Requests table:
| Field | Airtable type | Purpose |
|---|---|---|
| Request ID | Single line text, primary field | A readable identifier such as WR-101. |
| Session title | Single line text | The proposed workshop name. |
| Session outline | Long text | The author’s proposed agenda. |
| Status | Single select | Draft, Submitted, or Closed; managed by the coordinator. |
| Session title display | Formula | A display copy of Session title. |
| Session outline display | Formula | A display copy of Session outline. |
No linked-table relationship is required for this example. That keeps status behavior separate from the additional choices involved in editing linked records. Do not add attachments, payment fields, or approval actions until the basic two-field behavior passes your checks.
Create WR-101 with Draft status, a title of “Introduction to urban sketching,” and a two-paragraph outline. Create WR-102 with Submitted status and different text. Keep both records easy to distinguish so testing cannot accidentally compare two URLs for the same record.
Add the display formulas
Set Session title display to:
{Session title}Set Session outline display to:
{Session outline}These are field references, not copies pasted by an automation. Airtable’s formula reference explains the braces used for field names containing spaces. Check the two display columns directly in Airtable: each should return the corresponding example text. If a formula reports an error, fix the spelling and field reference there before debugging the form.
Keep this version as plain text. A rich HTML summary is a separate presentation choice, not a requirement for the workflow. Starting with individual fields also makes it easier to identify which answer has an incorrect condition.
Configure the editing form
Use a form connected to Workshop Requests that edits existing records. For an existing non-login form, the documented route is Form Builder → Share → Allow users to update existing records → Get Edit URL. Copy the generated formula into an Airtable button or formula field rather than constructing record links by hand. The editing-form guide explains this setup and notes that the edit-formula option is unavailable when login is enabled.
Use the access method appropriate to your real audience; do not publish individual editing links in a public document. For this isolated exercise, test only the two fictional records. Existing-record editing loads saved record values. A generic creation URL is not an equivalent test.
Add Session title, Session outline, and their display formulas to the form. Leave Status out of the form outline; the coordinator will manage it in Airtable. The conditional-field instructions explicitly support conditions using fields that are not present in the form outline. This design does not depend on conditionally hiding Status.
Pair editable and display-only fields
The actual Read-only setting cannot currently be conditional. Instead, follow the documented conditional editing workaround:
- Select Session title in the form preview, expand Conditional Field, and use Add Condition to show it when Status is Draft. Apply the same condition to Session outline.
- Show Session title display and Session outline display when Status is not Draft. Formula fields are read-only by default.
- In each display field’s Standard Options, set its custom title to match the original field’s visible title.
The intended result is one visible version of each answer, not two. Check a blank Status separately rather than assuming how the condition treats it. For this proposed workflow, coordinators must assign Draft deliberately before asking an author to edit.
Test the complete handoff
The following is an acceptance plan, not a report of a scenario already run. Record the URL, record ID, starting status, observed controls, and saved values for each case.
- Draft: open WR-101 through its editing route. Change the title, submit the edit, and confirm the original Airtable field contains the new value.
- Submitted: open WR-102. Both answers should be visible without the original editable controls. Confirm the original answers remain unchanged after viewing.
- Status transition: change WR-101 to Submitted in Airtable, then reopen the record. Verify the new title is displayed and editing controls are absent.
- Correction: have the coordinator deliberately restore Draft, reopen, and verify the intended editing experience returns. Decide who is allowed to authorize this exception operationally.
- Empty and unusual content: test an empty outline, multiple paragraphs, punctuation, and a long title. Inspect both desktop and a narrow phone viewport.
- Already-open page: change status while another tab is open. Do not assume the open page immediately refreshes or enforces your desired concurrent-edit behavior. Evaluate that case before relying on the workflow for a deadline-sensitive process.
Formula fields are intended for existing records, or creation with Save & Continue enabled; they are not generally shown on a fresh creation form. See formula-field availability. Reopening the saved record is the baseline check here; this walkthrough makes no live-refresh guarantee.
Check the boundaries before rollout
A read-only display in one form does not mean every other editing route has the same configuration. Review any other forms, portal views, direct Airtable access, integrations, and automations that can change these answers. Document which route is supported for requesters and who owns corrections. Keep the status transition separate from the display rule in your operational instructions.
Linked records require a separate review: controlling whether users can change the selection and whether they can edit fields inside a linked record are distinct concerns. The linked-record read-only guide explains these levels. Do not infer that the two text-field pattern automatically locks child records.
Finally, verify the end-user version, not just the builder. Configuration edits remain in Draft until published, according to the sharing guide. After your checks pass, publish your intended configuration and repeat the Draft and Submitted cases through the actual sharing route. The result is a clear status-based editing experience for the selected fields, with an explicit correction process and known limits.
