A request form, a profile editor, and a customer workspace can all connect to the same Airtable base. That does not mean they should give users the same experience. Someone requesting a service needs a short path to submission; someone returning every week may need to find earlier requests, compare their status, and update the right one.
Choose your miniExtensions starting point by the job the user needs to complete—not by which option sounds most powerful. This comparison separates a standalone Form, a Form with Login for an existing record, and a Portal. It also explains the login-based submission shortcut, which creates a Portal behind the scenes.
Start with the record, not the screen
Write down one sentence before building: “After opening this link, the user needs to ___.” Then decide whether the blank is create a record, update a particular record, or work through a collection of records. These are different starting experiences, even when their fields look similar.
The documented distinction is primarily presentation and relationship complexity: a Form centers on one record, while a Portal starts from multiple records and can offer different views. A Form can still include linked records, so “more than one table” is not an automatic reason to reject it. See the Form and Portal comparison.
| What the user needs | Starting point | Main design question |
|---|---|---|
| Send a new request without browsing earlier ones | Standalone Form | Which information must each submission collect? |
| Correct one known record using a record-specific link | Form configured for editing | How will the correct editing link reach that person? |
| Return through one shared entry link to update their existing record | Form with Login: existing-record option | What identifies the record at login? |
| Submit new records associated with a logged-in user | Form with Login: new-record option | Is submission-only navigation enough? |
| Review and manage several related records over time | Portal | Which records and actions should each view expose? |
Choose a standalone Form for a focused submission
Consider a fictional studio accepting project inquiries. A new visitor supplies a name, email address, project summary, and requested date. They do not need to browse a workspace before making an inquiry. A focused form keeps the immediate task clear.
For a create-only Form, the documented controls are in the builder’s Share menu: enable Allow users to create new records and disable Allow users to update existing records. These standalone creation/editing controls apply when login is disabled. Child forms use their parent field or table’s Create & Expand Records settings instead. See creation and editing controls.
The tradeoff is intentional: a submission screen is not a history screen. If a customer later asks, “Where are all my requests?”, sending them back to a blank form does not solve that need. Decide whether a separate follow-up process is enough or whether returning users need a Portal.
Use an edit Form when the record is already known
Suppose the studio has already created a project brief and wants a client to correct its contact details. That is an update, not a new inquiry. A record-specific editing URL can open the existing record with its stored values.
The documented path is Form Builder → Share → Allow users to update existing records → Get Edit URL. Copy the supplied formula into an Airtable formula or button field to generate a distinct URL for each record. The editing-URL formula is not available while login is enabled. Follow the edit-record setup guide for the full walkthrough.
This approach fits a specific correction request. Its operational cost is link distribution: someone or a separately configured process must deliver the right URL. Decide deliberately how those links will be handled; a convenient editing link should not be described as an identity-verification system.
Choose Form with Login for a returning user’s record
A yearly profile update has a different rhythm. A member returns through the same entry point, finds their record, and updates a small set of details. Repeatedly sending individual edit links may be unnecessary friction.
The Form with Login creation shortcut offers View and update an existing record. For an existing Form, the documented access choice is Share → How do users access their records? → Login/Lookup page, with updating existing records enabled. Login settings identify records using information in Airtable; end users do not need miniExtensions accounts. See how login works.
Be precise about the word “login.” Some configurations can use a lookup list rather than requiring a person to type a value. The documentation presents that option for situations such as product lookup where privacy is not the main concern. Do not treat every lookup configuration as equivalent to verifying a person’s identity. Review the login-value selection options against your actual requirements.
Understand the login-based submission shortcut
The other Form with Login shortcut, Submit new records, creates a Portal with a Form view. It is not simply an existing-record Form with a different submit button. The documented setup associates new submissions with the logged-in user.
That can suit a staff member logging several expense requests without needing a dashboard at the point of entry. However, a Portal Form view is for creating records, not displaying or editing existing ones. It is configured at the table’s Default View Settings level, rather than for an individual view. Read the view-type documentation before choosing it for a workflow that also needs history.
Choose a Portal when the collection is the work
Imagine the same studio’s returning client now has five active projects. Their first question is “Which project needs my input?”, not “What should I type in this field?” A collection-oriented starting point is a better fit. The existing agency client-portal guide covers that broader scenario.
As a proposed data model, keep a Clients table with Name and Email fields and a separate Projects table with Project Name, Status, and a linked-record field pointing to Clients. That separates a person’s identity record from each work item. It is a design example, not a required template for every Portal.
Check the visibility configuration for each Portal table and view. The documented route is Portal Tables → table → Views → view → Filter and Sort → Choose Records to Display. Personal records only (linked to the logged in user) limits that view to linked records; Show all records has a different purpose. See user-linked record visibility. Merely adding a login page is not a substitute for reviewing those settings.
Record visibility and convenient filtering also solve different problems. The Portal’s client-side Filter button helps users narrow the records they are browsing; its availability and custom-view overrides are configured under User Actions. Do not use a user-selectable filter as your definition of which records belong to a person. See Portal filtering options.
Check the choice with a small acceptance plan
Before sharing a real workflow, prepare fictional records and write down the expected outcome of each action. This is a recommended test plan, not a claim that these tests have been run for your setup.
- New submission: does one submission create the intended record rather than change an existing one?
- Existing-record edit: does the record ID stay the same after a correction?
- Returning user: does the entry link lead to the expected record or collection?
- Two-user check: give two fictional users different linked records, then verify each user’s views, expanded forms, and available actions separately.
- Wrong or missing lookup: check the configured outcome rather than assuming registration happens automatically.
- Live configuration: test the published end-user version, not just the builder preview.
The sharing documentation explains that configuration changes remain in Draft until published. A correct preview therefore does not establish what existing users currently see.
Keep the starting experience as small as the job
Use a Form when the task is a focused submission or edit. Add login when returning through a shared entry point makes sense. Choose a Portal when finding and managing related records is itself part of the work. If the requirements change, revisit that decision instead of adding more steps to a screen that no longer matches the user’s goal.
