Baserow Forms: Create Rows, Edit Records or Share Views

A registration link should not give an attendee the same access as an organizer.

Consider a fictional product team running an event in Baserow. New registrations need a public form. Corrections need a link to the existing row. A status list needs read-only sharing.

The examples use fictional Name, Email, Session and Status fields. Status is the organizer's decision. This guide draws on Baserow's documentation: no instance was configured and no submission was tested. The proposed checks still need to be run.

Choose the link by the action: create, update or view

Baserow documents ordinary Form submissions as creating new rows. Its separate Edit row link feature connects a particular existing row to a prefilled form. For browsing rather than editing, use a publicly shared view.

Recipients can use these paths without a workspace invitation. Do not mistake that convenience for knowing who is on the other end of a link.

The public-sharing guide describes forms as accepting new submissions rather than editing existing data. That describes the ordinary public-form path. Baserow documents existing-row updates separately under Edit row link.

Use a public Baserow form for new registrations

Expose only the fields a respondent should submit

Start with a separate test table. In the table's view dropdown, select Form, choose the available permission type and give the view a name. The form guide describes the setup and says compatible table fields appear automatically.

For this fictional event, attendees supply Name and Email, then choose a Session. Hide Status through the Form view settings. Check labels, required answers and Session options before sharing.

An ordinary submission creates a row even if its email matches an existing registration. Baserow does not automatically prevent duplicates. Decide who will review suspected repeats and what should happen to them.

Preview deserves particular care. It opens the real public URL, and submitting from it writes actual data. Keep these experiments in the fictional test table.

Treat prefills and confirmation messages as presentation, not proof

The same guide documents query parameters such as ?prefill_Name=Example and ?hide_Field. These are presentation helpers. Recipients control their URL, so a prefilled value cannot establish identity. A query-hidden approval value is no basis for accepting a registration either. If campaign attribution must be trustworthy, a prefill alone is insufficient. Form view field hiding is a separate setting.

A confirmation containing {row_id} identifies the created record. It does not prove ownership of the submitted email, and it says nothing about whether downstream work finished. Likewise, required-field and field-type validation can check input constraints without establishing that an answer is true.

Use an Edit row link when an existing registration must change

Configure a dedicated update form and the Edit row link field

Give corrections their own Form view. Expose only Session if that is all the attendee needs to correct. Keep Status hidden in the Form view settings.

Then switch to Grid view, add a field with the Edit row link type and select that update Form view in its settings. Baserow's setup instructions say this generates a unique URL for each row. Opening one displays that row's current values; submission updates the existing row without creating another.

Adding a prefill to an ordinary form URL does not make it an update link. The Edit row link field supplies the documented connection to the existing record.

Protect the link and plan for conflicting edits

The Edit row link documentation says anyone with the link can see the exposed prefilled data and submit changes to that row. Treat the URL like a password. Send it privately. Leave the field out of public lists and check screenshots before sharing them. Keep live links out of copyable examples and URL analytics too.

Possession does not verify identity. Nor should the process depend on one-time use or automatic expiry without evidence that those controls exist.

The documentation says the most recent submission is saved; it does not promise merged answers or a conflict warning. Decide who will resolve disputed changes.

Check revocation separately. The documentation lists Form deletion, field removal from the Form view, or token regeneration where available. Field removal has an unclear scope: do not equate hiding one input with revoking the whole row link. Confirm the applicable control, then verify old-link access with disposable data; no universal token-reset button is established.

Use shared views for read-only updates, not attendee edits

Configure visible fields, filters and exports before sharing

Give the status list a dedicated Grid or Gallery. Show only fictional Session and Status values; exclude Email, unnecessary Name values and every Edit row link.

Baserow's public-sharing documentation describes shared Grid and Gallery views as read-only and says hidden fields remain hidden when records expand. Configure fields and filters before distributing the URL. Inspect both the initial list and expanded records from a signed-out session.

For a shared Grid, Allow export on shared view is documented as off by default. If enabled, exports respect the configured filters and hidden fields. Check export scope with fabricated records; a request not to download cannot replace the setting.

Separate a shared password from individual authorization

A password on a public share link remains a shared secret. It cannot identify each reader or establish identity-based row authorization. Putting the view in an iframe does not change who may access it.

Generating a new public share URL invalidates the previous URL according to the sharing guide. Do not assume that this also revokes every row-edit token.

When links travel by email, check the audience separately from what the destination permits. Optijara's guide to separating publication, reading access and email recipients explores that distinction in Ghost, not Baserow configuration.

Run a Create-Update-View preflight before sending any link

Prepare a harmless test fixture

The Optijara Create-Update-View preflight is this guide's proposed review checklist. It is not a Baserow feature or a validated security framework. Check the intended action, visible data and link retirement.

Prepare fabricated registrations in a separate table. Use no real email addresses. Production credentials and live recipient tokens also stay outside the fixture. Assign someone to distribute and retire each link, and write down which fields the recipient may change.

This diagram summarizes the decision, not Baserow's internal execution. Its text equivalent is the three sharing paths in the opening table.

Check the intended action and the unintended exposure

Use the documented form, row-edit and sharing behaviors as expectations, then inspect stored results. None of the following checks has been run for this guide.

If overlapping corrections matter to the workflow, add a concurrency check on a disposable row and record which submission survives. Inspect the stored row or access result for each check; a thank-you message is insufficient evidence.

Record expectations before a future test

Record expectations, later observations and unresolved questions. The JSON below is a planning note with lowercase identifiers, not an API payload or test result. In the fictional Baserow table, the organizer-only field is still named Status.

{
  "playbook": "create-update-view-preflight",
  "fixture": "fictional-event-registrations",
  "actions": ["create", "update", "view"],
  "organizerOnlyField": "status",
  "retirement": "verify-per-link-type",
  "executionStatus": "not-run"
}

Check whether people can use the form too. Read its labels and try keyboard navigation, including the path through validation errors. Optijara's Playwright guide to testing rendered form states offers a separate testing approach. Its local fixture does not test Baserow, and automated accessibility checks cannot establish full conformance.

Common mistakes: treating every Baserow link as the same permission

A familiar-looking email is not an instruction to update an existing row. Ordinary submissions and row-specific corrections follow different paths. Publishing an edit-link column is a separate mistake: it distributes credentials, even if the column looks like an ordinary reference field.

Field controls also need careful reading. Form view visibility differs from user-controlled URL hiding. Field-level edit permissions have another purpose. Baserow's field-permissions guide says they restrict editing, not the visibility of existing values to members with table access. API reads still return field data when table access exists.

Do not invite an attendee as a workspace Member merely to collect a correction. The permissions overview describes broad workspace access for Free and Premium Members. Granular database and table RBAC is associated with Advanced and Enterprise, with cloud and self-hosted licensing distinctions. Check your deployment rather than assuming a workspace invitation is narrowly scoped.

Limits, plan checks and what to monitor after launch

This documentation-based guide is not a runnable implementation, deployment test or security audit. Check your deployed version and current plan, then confirm the controls your process depends on.

Survey mode is a paid presentation option; standard forms are available on the free plan. Survey presentation is not required for the create, update or view decision, and this guide predicts no completion-rate improvement.

Forwarded links can defeat an otherwise careful distribution plan. Accidental disclosure also needs a response, while duplicate registrations and conflicting corrections leave someone with reconciliation work. Budget for that work rather than assuming the form removes it.

Sensitive information or verified-user requirements call for a separate access design. If named accounts become necessary, Optijara's account sign-in and recovery planning guide offers background. It is not a Baserow integration recipe. Signing someone in still leaves record-level authorization to solve.

After implementation, keep a small review log. Use it to judge the workflow instead of assuming it saves time. No measurements have been collected for this guide.

Use the log to improve instructions or change sharing paths. Assign unresolved access questions to an owner.