# Survey apps overview (/docs/survey-apps/overview) A **survey app** collects answers from people outside your workspace. You build a form, publish it, and share one link; anyone with the link can answer it without an account and without signing in. Every response lands in your workspace as a row of data, ready to summarise or feed into an analysis. Where an analytic app reshapes data you already have and an indicator app gathers a measurement period by period, a survey app is built to ask **people** something and keep what they say. ## The three parts [#the-three-parts] A survey app has three surfaces, and the split between them is the thing worth learning first. * The **form** is what you build: the questions, their order, and the rules about which ones appear. Editing it changes a **draft**, and a draft is invisible to respondents until you publish. * **Settings** is what you operate: whether the survey is accepting answers, when it closes, how many responses it takes, and the links to send. Change what you like and press Save; a saved rule takes effect at once, with no publish involved. * **Responses** is what you read: a summary per question, the individual answers, and the way into an analytics app. The reason the first two are separate is practical. "Stop accepting responses" is a switch you want to work instantly. "Add a question" is a change respondents should only meet when you are ready. Who sees which part follows their role on the survey. Everyone who can open a survey app reads its published form and its responses. **Open editor**, the way into the form and its version history, is offered to people who may read the survey's configuration; the share link, and the Settings that change the survey, are for people who may configure it. Someone who may only view a survey never sees a draft. ## Building the form [#building-the-form] The **Questions** page is a canvas: every page of your form is a card, and every question a card inside it, laid out as a respondent will read them. An outline of the form sits on the left (fold it with the button above the canvas, or with ⌘), and clicking a question or a page's title opens its settings in a panel on the right. Hover a card for its actions: drag it by the grip to reorder it (a question can be dragged onto another page), duplicate it, or delete it. Press Escape, or click the selected card again, to close the panel. Each row of the form is either a **question** or a **page break** (a section). A page break starts a new page, so a long survey can be read a section at a time. Add a question with the **Question** button at the foot of the page it belongs to - you pick its type first - and a new page with the **Section** button under the last one. Switch the canvas to **Preview** (or press P) to walk the form exactly as a respondent will, including unsaved edits: the same page, the same Next and Back, the same required checks. Nothing you enter in the preview is stored. A phone width is a click away in the same bar. A question has a **type**, and the type is what a respondent sees: | Type | What the respondent gets | | ----------------------- | ----------------------------------------------------------- | | Short text, Long text | A single line, or a box | | Number | A number field, with an optional unit and range | | Single choice, Dropdown | One choice from a list | | Multiple choice | Any number of choices from a list | | Yes / no | Two buttons | | Scale | A row of numbered buttons, with labels at each end | | Email, Date | A field that checks its own format | | File upload | A button that attaches one file, up to 10 MB | | Table | A grid of columns you define, with rows the respondent adds | A question can also be **required**, and it can be **conditional**: "show this only if an earlier question was answered a particular way". A conditional question a respondent never sees is never required of them, and its answer is never stored. A **table** question is the one to reach for when the answer is a LIST: "tell us about each of your suppliers", "list the sites this applies to". You define the columns - a header and an answer type each, up to ten of them - and the respondent adds a row per supplier, up to fifty. A column can be a short text, a paragraph, a number, a date or an email address, and any of them can be required, which means a row somebody started has to fill it in. On the Results page and in the CSV each column becomes a column of its own, holding that respondent's entries in the order they typed them. A **file upload** question asks for a document: a certificate, a signed form, a photograph. The respondent picks one file per question and it is stored with the survey; on the Results page and in the CSV the answer reads as the file's name, and opening a single response gives you a button that downloads it. You choose what a respondent may attach - **Any file**, **Documents** (pdf, doc, docx, xls, xlsx, csv, txt) or **Images** (png, jpg, jpeg, gif, webp) - and that choice narrows the file picker they see. It is a guide for them rather than a security check. A survey link can be shared with anybody, and Ovidens does not scan what is uploaded for viruses or look inside it. A file is always downloaded rather than opened in your browser, so nothing runs by being listed - but treat what arrives the way you would treat an email attachment from somebody you do not know. A choice question can **allow another answer**. That adds an Other choice with a text box, under the label you give it, and it is stored in two columns: the choice column records that Other was picked, and a second column beside it holds what was typed. Filters and charts over the choice column keep meaning what they meant, and an analytics app importing the responses still resolves every choice to its label. Other catches outliers in a list you have already thought through - it does not recover a category you forgot, so it is worth reading what people typed. Once answers exist you can still ADD choices and reword them; removing a choice, or switching Other off, is refused, because either would leave answers pointing at something that is no longer there. ## Publishing, and editing afterwards [#publishing-and-editing-afterwards] Publishing takes a snapshot of the form and makes it the one respondents see. It is the same versioning every Ovidens app has: each published version is immutable, previous versions stay in History, and you can restore one. Until a survey is published for the first time, its link answers "not open yet" rather than an empty form. **You can keep editing after you publish.** An edit opens a draft, respondents go on answering the published form while you work, and your changes reach them when you publish again. Nothing you collected is lost or changed by any of it, and restoring an older version brings its QUESTIONS back as a new version - it never brings back old answers or removes new ones. Two things are worth knowing before you edit a live survey. * **A question somebody has already answered is partly fixed.** You can reword it, change its help text, move it to another page, make it required or optional, add a choice and rename one. On a table question you can add a column, rename one and change whether it is required. You cannot change its answer type, its column name, remove one of its choices, switch its Other choice on or off, remove one of its table columns or change a table column's type - each of those would leave answers pointing at something that no longer exists. Deleting an answered question hides it from the form and keeps its answers. * **Some changes mean the answers are no longer one measurement.** Moving a rating scale from 1-5 to 1-10, changing the condition that decides who is asked, making a required question optional, or changing a table question's columns at all - adding one included - all change what an answer MEANS. Ovidens tells you before you publish - the publish confirmation lists which questions would be "redefined" - and afterwards it marks that question on the Results page rather than averaging the two sets together. Rewording a question or adding a choice is not such a change: those answers still belong together. A respondent who had the form open when you republished is asked to reload before their answers are accepted, so nobody's answers are recorded against a questionnaire they were not shown. ## Starting a new survey from this one [#starting-a-new-survey-from-this-one] To run the same questions again - next year's edition, or a variant for another group - open the survey with Open editor and choose **Duplicate survey...** from the **More actions** menu (⋮) in the top bar. You name the new survey and, if you may create apps in more than one space, choose the space it goes into. The copy takes the questions in their order, the form's description and its messages, and starts as a draft. Everything else is new: it gets its own link and its own responses, and it holds no answers. This survey keeps its link and its answers. The menu appears only for people who may create apps in at least one space, because a duplicate is a new app. ## Sharing [#sharing] Every survey has **one** link. Anyone holding it can answer without an account, and every answer counts. To walk your own form before you send it, use **Preview** in the builder: it is the respondent's page over your draft, unsaved edits included, and it checks your answers against the same rules the live form applies - but nothing it produces is stored, so a rehearsal never becomes a response. If a link ever needs to stop working, regenerate it: the old address stops resolving immediately and cannot be brought back. ## What happens to the answers [#what-happens-to-the-answers] Each response becomes one row in the survey's **responses** table, with one column per question plus a few facts about the submission itself - when it arrived and which published version of the form it answered. That table is an ordinary Ovidens dataset. It is what the Responses page reads, what a CSV export writes, and what an analytics app imports through an **analytic-app-data** node. You can look at the table itself on the editor's **Pipeline** page: the responses table drawn as the one node this app holds, its columns and their types on the node's Configuration tab, and the answers on its Data tab. It is read-only - a respondent is the only writer - and it shows exactly what every other reader sees, so deleted responses are not in it. **When** a response arrived is recorded in UTC, in the `submitted_at` column. It is the moment the form was submitted, to the millisecond, and it reads back as that same moment wherever you look at it - the grid, the CSV export, and a query in an analytics app. Deleting a response keeps the row and marks it deleted, so the delete can be undone and the audit trail stays honest. A deleted response is excluded from every read. ## The limits a survey works inside [#the-limits-a-survey-works-inside] Five numbers bound one survey, and all five are your workspace's rather than the platform's - a workspace administrator can see them under **System -> Usage and limits**, and an operator can raise them. | Limit | Default | What it bounds | | ---------------------- | ------- | ----------------------------------------------------------- | | Responses per survey | 100,000 | how many responses one survey may collect | | Questions per survey | 100 | rows on one form - questions and page breaks together | | Pages per survey | 20 | page breaks on one form | | Upload size per file | 10 MB | the largest single file a respondent may attach | | Upload size per survey | 500 MB | everything one survey has ever been sent, across every file | A respondent whose file is over the per-file limit is told so while they still have the right file to hand, and one who arrives after the survey's total is reached is told the form cannot take more files - never what the limit is. The response limit works alongside the optional **response limit** you can set on the survey itself in Settings, and the LOWER of the two is what closes the form. A respondent who arrives after either is reached is told the survey is closed; they are never shown which limit it was. Setting your own limit above the workspace's is refused rather than quietly reduced, and the field says what the workspace allows. The editor's **Preview** is unaffected by either, because it stores nothing - so you can always rehearse a form that has filled up. Two more bounds are fixed and not per workspace: 50 options on one choice question, and 4,000 characters in one free-text answer.