Modules
Authored surveys, quizzes and checklists, and the responses to them. Core.
A survey is an authored set of questions laid out on pages. A quiz is a survey with a pass mark, a checklist one whose answers are ticks, and the public enquiry form is a survey whose audience is public. It is core because a training quiz, a work order's submission and the always-on marketing form all answer one, so the question-and-answer shape is built once.
| Table | Holds |
|---|---|
surveys | Type, status, audience, the window it accepts responses in, and the survey it supersedes. |
survey_pages | Ordered pages, each with a visibility rule. |
questions | Type, label, help, score, a visibility rule, and per-type configuration. |
question_options | An option's label, value and score. Correct means a positive score. |
survey_responses | One respondent's sitting: what it answers, its status, timings, score and position. |
question_answers | One value given to one question, exactly one of text, number, date, boolean, option or file. |
Structure is rows, behaviour is JSON: anything another table points at or filters on is a column, and everything that only governs how the survey runs sits in one configuration document a shared schema validates on web and mobile alike.
A survey's window is not its status: a published survey can be not yet open or already closed. A published survey is immutable; editing clones it as a draft that supersedes it, which is what keeps a pass mark from moving under a sitting.
Every write to a response is a privileged function, so a handset cannot forge an answer or a score. Saving a page mints the response, refuses a sitting outside the window, rejects an option from another question, and advances the position, which is the resume target for autosave and the mobile outbox. Submitting validates required and visible questions server-side, scores, stamps the time and returns the derived pass. A visibility rule is evaluated by the same logic in the database and on the client, so a hidden required question never blocks and a visible one always does.
/surveys: the builder, each survey's response list and per-question aggregates, and a preview that runs the survey in try mode writing no response.
create, add_page, add_question, set_options, publish, preview.
surveys.read and surveys.manage. A published survey is readable by any signed-in caller, a public one anonymously, and a respondent always reads their own response.
Never. Every project links it at provisioning.