Collecting data from people who never see the spreadsheet
A shared spreadsheet is a poor intake channel. Whoever has the link can read everything in it, edit the wrong cell, or paste a request into the middle of someone else's row. The usual workaround is a form tool that dumps answers into a sheet, and then somebody copies them across.
In Appdor the form is part of the table, so there is nothing to copy. Here is how it works and where its limits are.
From a table to a link
Open a table and choose Create form from the table's actions. Appdor creates a public form for that table, or reuses the one that already exists, and includes the table's editable fields. It then opens the form builder and gives you a link.
The wording on the share dialog is worth reading closely: Public form link, and "Anyone with this link can submit a new record to this table — no account needed. They cannot see records that already exist." A submission adds a record. It does not give the submitter a view of the table.
Some fields cannot be asked, and the builder says so instead of hiding them. A field that Appdor works out itself, such as a formula, has nothing for a submitter to fill in. A field hidden from someone by the table's field permissions is not published on a public form either.
Shaping the form
The form builder has three tabs: Build, Preview and Responses, with a Share form button. In Build you can reorder questions by dragging or with the arrows, put a question beside the one above it, split the form into pages, add help text, and place content blocks such as headings between questions. You can also add a welcome message and a logo. The logo must be a full web address beginning with http or https, and the builder refuses anything else.
Preview shows the current draft as a respondent would see it, on a desktop or a phone layout, and states plainly that submissions and uploads are disabled in the preview. That is the place to check the form on a small screen before you send it to anyone.
A form can also carry repeating child records. A subform lets a submitter enter several lines of the same kind, such as order lines, in one submission, and the parent and children are created together. The builder blocks a subform if the child table has not been set to accept records from public forms, and it says that this setting lives on the child table and is never implied by the form being public.
Controlling who can answer and how often
The response controls sit beside the responses list. You can set when the form opens and when it closes, cap the total number of responses, and choose Responses per person: no limit, or one per signed-in person. The builder notes that responses are counted from the moment a limit is set, not from the form's history.
What a visitor sees is spelled out in the product strings. Before the opening time: "This form opens on …". After the closing time: "This form closed on …". When the owner shuts it: "The owner has closed this form." When the cap is reached: "This form has all the responses it was set to take." The same rules are enforced where the record is written, so a form that closed a moment ago refuses the submission rather than only looking closed.
Spam defences are available, and off by default: a hidden trap field, a minimum fill time and a limit on submissions per hour from one connection. There is also a setting for a human verification provider, with a plain caveat: Appdor ships no verification service, so a provider named there is never reached. These reduce junk; they are not a guarantee.
What arrives, and what happens next
Each submission becomes a record in the table. Because the submitter has no account, the record is attributed to a fixed non-person identity labelled Anonymous (public form), not to whoever owns the table, so the audit trail does not claim that a colleague created something they never saw.
The Responses tab lists the latest submissions, and the table itself shows them as ordinary rows you can filter, assign and sort. A workflow can react to them: there is a form-submitted trigger, and a plain record-inserted trigger works as well. The Forms Pack template, which ships bug reports, event registrations, IT requests, product feedback and job applications as separate tables with their own forms, includes rules like a notification when a bug report arrives through the public form.
Forms can take files. The file picker on a public form is enabled only when the running upload service and database confirm the capability for that form, and older deployments keep the controls disabled. The upload path accepts raster images, PDFs and ZIP or Office containers, and rejects SVG, HTML and scripts. The documentation is explicit that this is a type check, not malware scanning.
For someone who has to stop partway, the builder offers a setting to let visitors save the form and resume from a private, expiring link; answers stay on the server. For customers who need to correct something afterwards, Record edit link creates an expiring link that lets a customer update one existing record.
The inside of the app has a related, separate piece: the Form page element, which puts input fields for a table on an app page.
Start with the smallest version: a handful of questions, a check of the preview on a phone layout, and a closing date.