Design and Deploy New Surveys

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 Framework 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 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: GESI Survey 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:

show the login form;
decrypt and load user credentials;
determine which survey to open;
fetch that survey's settings.json;
fetch the latest version_...json;
fetch the referenced questions_...json, layout_...json, and config;
render the right controls;
autosave answers into the confidential account bucket.

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:

Filler app: the reusable survey renderer/player.
Survey: the data files that renderer loads.
Access link: the filler app URL plus survey name and user credentials.

If you skip application deployment:

If the Designer/Filler apps are already deployed somewhere valid, you can publish another survey. You are only adding or updating survey data.
If this is a fresh environment and no Filler app is deployed, you can create survey data in S3, but users will not have a working public survey URL.
If the Filler app exists but is stale, your survey may still work unless it depends on newer question types, bug fixes, branding, login changes, or save behavior.

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 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:

be added as a filler for that project, and
also as a member of an account (next step).

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—enabling the user to the externally deployed survey instance:

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: