Creating surveys: the two methods
Survanta gives you two real ways to build the same survey. Both write to the same data, so a survey started one way can always be continued the other way. The difference is how much you do on one page.
- Method 1 — the Survey Builder. One page for the whole job. Recommended, and the right default for a new survey and for new users.
- Method 2 — the separate dashboard pages. One page per entity type. Best for editing a single existing record or doing administrative maintenance.
Method 1 — the Survey Builder (recommended)
The Survey Builder is a single page holding the survey's structure, the editor for whatever you select, and a review panel — all visible at once.
The workflow
- Create the survey. Open the Builder and use New survey. Give it a name and a code. The code is fixed once the survey exists.
- Add sections. Select the survey in the outline and use the add (+) control to create a section.
- Add groups. On a section, use add (+) and choose a group when you want to gather related questions.
- Add questions. On a section or group, use add (+) and choose the question kind.
- Configure choices and settings. The question's Details tab shows only the settings its type uses. For a choice question, the choices are edited inline on that same Details tab — there is no separate page and no separate tab to visit.
- Add conditions. Sections, groups, questions, and dynamic tables each have a Conditions tab beside their Details tab, so a show/hide rule is added without leaving the item you are editing.
- Review validation issues. The review panel lists every issue that blocks publishing and points at the item responsible. A refresh control re-runs the check after your changes.
- Preview the survey. Preview is available both as a workspace tab and in the review panel, with a toggle between the internal preview and the public view. Preview never stores a response.
- Correct issues without leaving the Builder. Because the readiness list, the editor, and the preview are on one page, fixing a validation issue is: click the issue, edit the item, refresh readiness, preview.
- Publish from the toolbar when nothing blocks it and you hold the publishing permission.
Builder creation currently sets the survey active before the separate Publish readiness action. Treat active
and published as distinct current facts; verify readiness and the Publish result instead of using IsActive
alone as evidence that respondents should see the survey.
Why it is the recommended method
You keep your place. The outline stays open, the item you are editing stays selected, and the effect of a change is visible in the same viewport. Most authoring tasks — structure, settings, choices, conditions, validation, preview, review — complete without a single page transition.
Full detail is in the Survey Builder guide.
Method 2 — the separate dashboard pages
The dashboard also exposes each entity type as its own list-and-form area, reached from the dashboard navigation:
| Area | What it manages |
|---|---|
| Surveys | The survey records themselves |
| Sections | Sections, each belonging to a survey |
| Question groups | Groups of related questions inside a section |
| Questions | Question records and their settings |
| Choices | The choices belonging to a choice question |
| Conditions | Show/hide rules |
| Assignments | The users assigned to a survey |
| Lookup datasets | Reusable lookup values used by lookup questions |
These areas expose list, create, details, or edit pages according to the entity. You choose the relevant parent (the survey, section, group, or question) on the form. Dynamic tables and static content are real supported survey items, but they are managed inside the Survey Builder rather than through an equivalent standalone classic page. File-question limits and allowed file types are edited on the Question form or in the Builder; files themselves are uploaded only when a respondent answers the question.
The compact Dynamic Table column editor does not offer a complete choice-option or lookup-dataset workflow. Static Content supports plain text or managed PDF/image files and never creates an answer. These are authoring boundaries, not reasons to replace the supported items with ordinary questions.
When this approach is genuinely useful
- Directly editing one existing entity. If you know exactly which question needs its maximum length changed, its edit form is the shortest path — no survey to open, no tree to expand.
- Administrative maintenance. Reviewing or correcting records across surveys, where the unit of work is the record rather than the survey.
- Reviewing a specific section or question without loading the whole survey.
- Working with existing records individually, especially where you arrived from a search, a report, or a link that already identifies the record.
It is not the efficient way to author a new survey from nothing: every section, group, question, choice, and condition is a separate form submission in a separate area, and there is no combined preview or readiness view.
Comparison
| Method 1 — Survey Builder | Method 2 — Separate pages | |
|---|---|---|
| Ease of use | Highest: one page, structure always visible | Lower for authoring: you track parents yourself |
| Page transitions | Almost none for normal authoring | One or more per entity created or edited |
| Preview available | Yes — workspace tab and review panel, with preview/public contexts | No combined survey preview from these pages |
| Review available | Yes — continuous readiness list naming blocking issues | No; validation is per form, on save |
| Best use case | Building and shaping a survey end to end | Editing or maintaining one known record |
| Editing individual existing entities | Possible — select it in the outline | Direct: go straight to that record's form |
| Recommended for new users | Yes | No |
Which to choose
- Building a new survey, or making more than one or two changes → Survey Builder.
- Changing one field on one record you can already name → the separate page for that entity.
Both methods act on the same survey, so switching between them mid-way is safe. Save your work before switching; the Builder warns you about unsaved changes before you leave it.
Runtime Compatibility Notes
- Both authoring methods write a mixed section-item order, but the current Razor player renders direct questions, groups, Static Content, then Dynamic Tables. Test the actual respondent order when these kinds are interleaved.
- Response editing is never implied merely by how a response was collected. Ownership, permission, survey activity, editing configuration, response status, and access mode are evaluated. Anonymous public-token routes provide submission but no public edit endpoint.