From design to insight: the end-to-end workflow

From design to insight: the end-to-end workflow

Survanta separates survey work across clear platform boundaries. Authors configure and publish on the web, signed-in field users collect through the mobile app, the backend accepts and stores synchronized records, and authorized teams review and analyze through the web dashboard.

Understanding these boundaries helps an organization plan field procedures, connectivity, response review, and analysis without assuming that every action is available on every surface.

Workflow at a glance

Stage 1: Web — design and configure

Survey Managers and other authorized authors build the questionnaire in the web Survey Builder.

They can organize it into:

• main sections;
• question groups;
• individual questions;
• dynamic tables.

Question settings can make an answer required and apply available length, numeric, date, decimal-place, file-size, file-count, file-type, or displayed-unit validation.

Authors should test realistic paths before publication, including:

• the shortest and longest valid answer;
• values at numeric and date boundaries;
• required questions on each conditional path;
• every repeated target;
• dynamic tables with zero, one, and several rows where the design allows them.

Add conditions on the web

Conditions can Show, Hide, Require, Disable, or repeat authored content. Matching uses Equals, Not Equals, Greater Than, Less Than, Greater Than or Equal, Less Than or Equal, Contains, Starts With, Ends With, or In.

The objective is to keep the respondent on a relevant path. A condition should be reviewed together with the question that supplies its source answer and the content it affects.

A hidden question may correctly have a lower analytics coverage rate. The Explorer uses all stored survey responses as the question denominator because condition-based eligibility is not stored separately.

Configure repetition on the web

Repetition is an action in the conditions system. It has three cardinality operators.

The Repetition action can target a single Question, a Group, or a Dynamic Table block. The maximum is 20 occurrences.

Nested repetition is not supported. The authoring layer rejects a repeating question inside a repeating group, so authors should model the structure without one repeated target inside another.

Worked example: one table or several table blocks

A livelihoods survey asks an Integer question: “How many businesses does this household operate?” The respondent answers 2.

Option A: row count control

Use Dynamic Table Row Count Control on a Business roster.

Result:

• one Business table;
• exactly 2 rows;
• each row describes one business.

Option B: block repetition

Use Count From Answer with the Repetition action targeting a Dynamic Table block.

Result:

• 2 separate Business table blocks;
• each block has its own rows;
• each block is stored as a distinct occurrence.

These designs are not interchangeable. Row count control changes rows inside one table. Block repetition creates multiple complete table blocks.

Publish on the web

Publication makes the configured survey available to the collection channels allowed by the organization's setup and survey settings.

Before publishing, confirm:

1. Question wording and choices are ready for respondents.
2. Validation rules accept the intended values.
3. Conditions lead to the expected paths.
4. Count From Answer uses an Integer source.
5. Repetition does not exceed 20 occurrences.
6. No repeated target is nested inside another repeated target.
7. Table row control and table-block repetition are used for their distinct purposes.

Stage 2: Mobile — collect

Signed-in field users collect through the Survanta mobile application. The survey must first be made available on the device while a connection is available.

Once the survey is on the device, a signed-in field user can:

• start a new response;
• answer questions;
• follow supported conditional paths;
• add and edit dynamic-table rows;
• save unfinished work;
• leave the response and resume it later;
• continue collecting without a usable connection;
• review required answers before submitting.

Offline work is stored locally for the signed-in account. The user should keep the app and its local data available until queued work has been accepted by the backend.

Mobile collection boundaries

Offline collection is for signed-in field users working from surveys already available on the device.

The following require a connection:

• signing in;
• obtaining a survey on the device for the first time;
• refreshing the device copy after survey changes;
• opening and completing a public survey link;
• opening and completing a survey through QR access;
• editing an already-submitted response.

Public and QR respondents use an online collection path. Their activity is not converted into an offline mobile workflow merely because the link was opened on a phone.

Submitting from mobile

When the field user submits, the app tries to send the response immediately.

If transfer cannot complete, the response is held in the local synchronization queue. The running app can retry when it:

• starts;
• resumes in the foreground;
• regains connectivity;
• receives a manual retry.

There is no operating-system worker that continues synchronization while the app is closed. Reconnecting the device alone does not guarantee that a queued item is sent while the app remains closed.

Stage 3: Backend — synchronize and store

The backend receives a queued response when the running mobile app makes a synchronization attempt. It then validates the submission against the applicable survey definition and collection rules before accepting it.

An attempted transfer and an accepted response are different events. If the backend refuses the submission for a business or validation reason, the queue can show that result and offer a retry where retrying can help.

The backend is also responsible for keeping tenant data within the owning organization. Mobile users, dashboard users, public collection, exports, and integration access are evaluated within their authorized organization context.

How repeated occurrences are stored

Each occurrence of a repeated Question, Group, or Dynamic Table block is stored independently and retains its occurrence order.

This matters later because:

• the reviewer can distinguish one occurrence from another;
• answers inside a repeated group remain attached to that occurrence;
• rows inside a repeated table block remain attached to the correct block occurrence;
• analytics can count recorded group occurrences;
• response review can display occurrence labels.

Dynamic Table Row Count Control remains different: it stores rows inside one table rather than creating separate table-block occurrences.

A household example across the boundary

Consider an Integer question asking for household member count, followed by a repeated Group for member details.

1. Web: the author configures Count From Answer and targets the member-details Group.
2. Mobile: the field user records a count of 4 and completes four group occurrences.
3. Backend: the four occurrences are accepted and stored independently in order.
4. Web: the reviewer sees four labeled occurrences and can inspect the answers in each one.
5. Analytics: the group report can show the occurrence-count distribution and calculate fill and completion per recorded occurrence.

The Integer answer controls the count up to the maximum of 20. It does not create nested repetition inside any of the four occurrences.

Stage 4: Web — review, analyze, and export

Authorized users return to the web dashboard after responses have synchronized.

They can use the response-management area to:

• list and filter submitted responses;
• open a response for review;
• read occurrence labels for repeated content;
• inspect each repeated occurrence separately;
• correct a response when survey settings and permissions allow;
• export response data when permissions and plan controls allow.

Editing an already-submitted response is online-only. It is not an offline correction workflow in the mobile queue.

Analyze on the web

The analytics dashboard summarizes survey and response activity. It offers an all-time response count, completed-response count, active and inactive survey counts, and response activity over 30, 90, or 365 days.

The Entity Explorer resolves an authored Code for a Question, Question group, Main section, or Dynamic table and returns a report suited to that type.

The two-code Comparison displays common metrics and a signed difference calculated as Code B minus Code A. For different entity types, it restricts the table to common normalized metrics and names incompatible measures that were omitted.

Platform boundary checklist

Related guides

• What Survanta does
• Survey design overview
• Survanta Mobile overview
• Working offline and synchronization
• Analytics overview