Data & Flows — Dayalogs

The basic pattern: choose where the data comes from, then use conditions or repeats to decide what each respondent sees.

Use known data

Read contact fields, link metadata, URL parameters, survey variables or data from your own system.

Show relevant questions

Display a question or a whole block only when its condition is true.

Repeat when needed

Ask the same question or block once for each product, child, location or selected option.

Choose where the data comes from

Not every survey needs to ask for information you already have. Dayalogs can use data attached to a personalized link, values passed in the URL, internal survey variables or information fetched from another system.

Contact and link data

Use contact data for values such as name, department or age. Structured lists can also drive a repeated flow: for example, one follow-up for each product recently purchased by the respondent.

Use simple values for personalized text and conditions.
Use lists when the survey should repeat once per item.
Keep related values together, such as a product's name, category and price.

Try asking your AI

“For each product in the contact's last_products list, ask whether the price felt right.”

“Greet each respondent by name and show a different introduction for each department.”

Survey variables and URL parameters

URL parameters carry external context into the survey, such as a panel id, campaign code or partner reference. Survey variables give a useful internal name to a value that several questions, conditions, endings or exports need to reuse.

A common pattern is to read a URL parameter or contact field once, keep it as a survey variable and use that variable throughout the questionnaire.

Try asking your AI

“Read the gid URL parameter, keep it as a survey variable and include it in exports.”

Data from your own system

When the required information is not already on the contact or link, Dayalogs can fetch it before the survey starts. The request runs on the server so credentials are not exposed in the respondent's browser.

Under the hood: API-backed variable

{
  "id": "responsable",
  "alias": "v_responsable",
  "type": "json",
  "source": {
    "type": "api",
    "method": "GET",
    "url": "https://example.test/api/household",
    "headers": { "X-SURVEY-SECRET": "example-api-secret" },
    "query": { "id": "{{ @contact.id }}" },
    "response_path": "response"
  }
}

Use a stable response shape and a fallback for non-critical data.
Treat survey definitions containing credentials as sensitive.
Prefer contact or link data when it already contains what the survey needs.

Show questions only when they are relevant

A visibility rule can control one question or a whole block. Use one when a follow-up only makes sense after a particular answer, or when a section is relevant only to one audience segment.

Put the rule on a question to control one field.
Put it on a block to control the whole group beneath it.
Reference information already available at that point in the flow.

Try asking your AI

“Show a follow-up question only when the NPS score is 6 or lower.”

“Show the supplier section only to contacts whose organization type is hospital.”

Under the hood: visibility rule

{
  "id": "p24_reason",
  "type": "text",
  "title": "What went wrong?",
  "visible_if": { "question": "p24_recommend", "op": "eq", "value": 1 }
}

Choose the right comparison

Most flows only need a simple equality, presence or numeric comparison. The remaining operators cover multiple-choice arrays, ranges and text patterns.

Operators

Use with

What they check

answered, not_answered

Any value

Whether a value is present.

eq, not_eq

One value

Simple equality or inequality.

in, not_in

One value and an allowed list

Whether the value belongs to a set.

contains, not_contains

Multi, rank or arrays

Whether a list contains one item.

lt, lte, gt, gte

Numbers

Numeric comparison.

between, not_between

Numbers

Whether a value falls inside an inclusive range.

starts_with, ends_with

Text

Whether text starts or ends with a value.

matches, not_matches

Text

Whether text matches a regular expression.

Ask the same questions for each item

A repeat runs a question or block once per item in a list. It is useful for products, children, stores, employees, selected options or rows from an earlier scale question.

Each pass can refer to the current item, so the wording can include its name, price or any other value stored with it.

Repeat a block when several questions belong to each item.
Repeat one question when only a single answer is needed.
Keep related repeated questions inside the same block so they share context.

Try asking your AI

“For every child stored on the contact, ask their age and childcare arrangement.”

“Repeat this follow-up only for scale rows scored above 3.”

Under the hood: repeated block

{
  "type": "block",
  "id": "children_loop",
  "title": "Questions for {{ current_item.name }}",
  "repeat": {
    "source": { "type": "variable_path", "path": "family.children" },
    "as": "child"
  },
  "items": [
    { "type": "question", "question": "p10_child_score" }
  ]
}

Combine data, conditions and repeats

The most useful dynamic surveys combine these tools. Load or reuse respondent data, repeat over the relevant list, then show follow-ups only when an item or answer needs more detail.

For example, a customer survey can load recent purchases, ask one rating per product and show a comment field only for products rated poorly.

Check the flow before publishing

Avoid forward references. A condition should use information already available.
Repeat sources must be lists. One object cannot create several iterations.
Test missing data. Preview the survey with empty and unusual contact values.
Keep source paths stable. Changes to API or contact-data shapes can affect text, conditions and repeats.