Design and Deploy New Surveys

Step 1: Login

Enter admin user credentials to use this interface.

Step 2: Deploy or verify survey application runtimes

Before creating or publishing survey content, confirm that the browser runtimes needed to use that content already exist in the target environment. If this is a fresh environment and the runtimes do not exist yet, deploy them here.

The Survey Designer app lets authorized users select a survey, edit questions, layout, and configuration, preview the result, and write new survey versions into S3. The Survey Filler app is the respondent runtime: it reads ?survey=someSurvey from the URL, logs in the user, loads that survey's latest version from S3, renders the form, and saves responses.

Staging and production are selected by the hosted app URL, not by login credentials. Deployment copies the AWS-hosted dist app shell artifact into either the production path (/survey/index.html) or the staging path (/survey-staging/index.html). The deployed shell still loads its JavaScript, CSS, and other shared assets from the canonical dist build; local development is only a preview/build source. Credentials determine which surveys and accounts a user may access after the selected runtime opens.

Deploy the Survey Designer Application

Deploy the Survey Filler Application

Verify deployed applications

You do not need to redeploy these app shells for every survey. Creating, editing, and publishing a survey writes survey data into S3; the deployed Filler runtime reads the latest survey data at request time.

Redeploy the Designer or Filler applications only when the application shell changes: SurveySlate code, runtime dependencies, static shell HTML, CSS/assets, CSP behavior, login/credential behavior, save behavior, new question types, bug fixes, or deployment targets. For normal survey content changes, use the later survey publish step instead.

The filler app is the reusable survey player/engine, not the survey content itself. It is the static front-end bundle built from src/survey/index.md and served through CloudFront/S3: index.html, JavaScript modules, runtime code, CSS, assets, and the page logic that creates root, shows loginForm, and calls renderSurvey after credentials are accepted. That runtime knows how to:

Survey content is loaded later from S3 based on the selected survey. In the current shared-runtime flow, one deployed respondent app can serve many surveys by changing the query string:

/survey/index.html?survey=energy&username=...&password=...
/survey/index.html?survey=transport&username=...&password=...

You can also load the filler app without a survey parameter. In that case it still loads the app shell. After login, it attempts to choose a survey from the user's allowed survey tags, falling back to config.DEFAULT_SURVEY or the first allowed survey.

The clean mental model is:

In SurveySlate's intended "one website per survey" deployment model, a published survey should also have a dedicated public entrypoint, such as:

https://dev.surveyslate.org/surveys/energy/index.html

That page can still reuse the shared filler runtime internally, but it should be bound to one survey, for example by baking in survey=energy or by routing/redirecting to the shared filler runtime with that survey fixed. From the respondent's perspective, this is the standalone website for that survey.

If you skip application deployment:

Publishing a survey without an existing filler app only creates data. Users still need a deployed filler app URL, or a survey-specific entrypoint backed by that runtime, to open and submit it.

Step 3: Create a survey instance

In this page, we assume your intention is to create a new survey. However in case you wish to check first whether there's an existing survey that already suits your needs, below is a list of all existing surveys:

To create a new survey, simply enter your desired name below and click submit. The list above will automatically update to reflect that your new survey has been created.

Step 4: Grant permissions

Note: To add, edit, or modify the content of a survey, your user must be assigned the roles of designer for that survey.

Before a user can modify the content of a survey, that user must be assigned designer permissions.

Step 5: Add content

You may add content manually—building your survey out one question at a time. You may also use the import questions and layouts feature within the Designer UI to automatically load a pre-designed survey.

Step 6: Configure page navigation

Use this section to rename the survey title and visible tab labels. Add pages, move questions between pages, and reorder survey content in the editor above. Image backgrounds are managed from Survey Image Stacks.

Step 6B: Survey Preview

Step 7: Select a target account

Surveys only work in the context of an account. Below is a list of existing accounts:

Optionally, create a new account:

Step 8: Manage User Permissions

Select a user to manage:


Survey Filler Access Tags ()

For a user to fill out a survey, they must:

  1. be added as a filler for that project, and
  2. also be a member of an account.

These are the surveys that the selected user can access:


Add user as a filler to a survey project

Application users with admin permissions can grant access to any existing survey. This grants the user permission to open that survey through the respondent runtime or through a survey-specific published entrypoint:


Remove user as a filler to a survey project


Assign user to an account

Users must also be assigned to an account were survey responses are saved—allowing the user to respond on behalf of that account. These are the accounts to which the selected user is currently assigned:

Application users with admin permissions can authorize any user to respond for any account:

To allow a user to respond on behalf of an account:

To disallow a user to respond on behalf of an account:

Step 9: Deploy survey data changes

This deploy action publishes the selected survey's current content. It saves the latest config, writes a new version_...json, and updates the survey's settings.json so the filler runtime can load the latest version.

This is the survey-specific data deployment. It does not redeploy the generic Designer or Filler application runtime, and by itself it does not create a dedicated "one website per survey" public entrypoint. If the intended delivery is a standalone survey website, verify after this step that the survey-specific entrypoint exists and is bound to this survey.

Last deployed:

Revert survey data changes

Rollback survey to last deployed version

Access links are web links to the respondent application. In the current shared-runtime flow, they point to the configured filler app URL and include the survey name and user credentials in the query string.

For the intended "one website per survey" model, the public link should instead be the dedicated survey entrypoint, or that entrypoint should internally route to the filler runtime with the survey fixed. In either model, the survey data published in Step 9 is only useful to respondents once a deployed filler runtime or survey-specific entrypoint can open it.

If you remove the username and password from the URL, the user must fill them out manually but it looks more secure.