Constants in a bot scenario: complete guide

A scenario is a chain of steps: send text, read a table row, check a condition, branch elsewhere. So the next step is not guessing in a vacuum but using facts from earlier steps—all intermediate values live in one shared data set.

Here a constant is not the “immutable value from a C++ textbook”; it is a named slot in that set: text, number, yes/no, list, or structured fields. In a template you refer to it by name in curly braces and inject the client’s name, a found row, a condition flag, and so on.

Startup and the Update event

The constant set is usually built on an Update event: the user wrote to the bot, pressed a button, a system event arrived, and so on. The “starter” bundle includes at least bot and user metadata, and the current date and time in the bot’s time zone. If downstream steps use external services, fields you explicitly request or pass through may also appear there.

Each block in the chain

The flow is simple and predictable:

1. the block receives the current constant set;
2. it performs its work;
3. it often appends or overwrites values;
4. it passes the set to the next block.

If a name already existed and you write it again, the last write wins: you always see the freshest result from the last step that touched that key.

Not every editor field allows templates. When expression support is enabled for a parameter (often labelled “expression” or “template”; in technical docs isExp), the string may contain substitutions like {PREFIX.TYPE.NAME} and special blocks such as {#IF}.

When it is off, the text is usually executed as typed, without substitutions. Before pasting a long {MAIN.STRING…} or an {#IF} block, check the field’s mode toggle—otherwise braces may reach the end user verbatim.

A key has three segments separated by two dots (exactly two in the usual scheme):

{ComponentPrefix.Type.Name}

The middle segment is the data type. Common values:

• STRING — plain text;
• ARRAY — list or object with fields (handy for table rows, catalogues);
• BOOL — yes/no, including the result of a condition step.

Illustrative examples (names may differ in your product):

# STRING
{MAIN.STRING.USER_TELEGRAM_ID}

# ARRAY — table row, list, or object
{DATA.ARRAY.CURRENT_ROW}

# BOOL — condition result (ID in the name)
{MAIN.BOOL.CONDITION_12_RESULT}

Editor hints that insert a ready-made key into a field follow the same idea: prefix, type, name.

Printing the whole value

If you use only the name without indexes or paths, the output is usually the raw form—often one long JSON string. Handy for debugging; less often for customer-facing copy.

Suppose {DATA.ARRAY.USER} holds:

[
  {
    "name": "Anna",
    "id": 10
  },
  {
    "name": "Boris",
    "id": 20
  }
]

Template without indexes:

Data: {DATA.ARRAY.USER}

The message will contain one long JSON string for the whole array—useful to verify structure while debugging.

Accessing a field or element

After the constant name, add steps in square brackets: element index or field name.

# index 0, field name (quoted)
{DATA.ARRAY.USER}[0]['name']
→ Anna

# index 1, field NAME (field name case is often ignored)
{DATA.ARRAY.USER}[1][NAME]
→ Boris

If the path is wrong (missing index or key), the fragment may stay exactly as you typed—a cue to check both the data and the path.

Nesting

For nested objects and lists, brackets alternate by level, for example:

{DATA.ARRAY.ORDER}['items'][0]['title']

Meaning: order → line items → first line → title.

When expressions are enabled, parsing follows a fixed order:

1. Loops — repeat a fragment for each array element.
2. Conditions — if / else branching.
3. Date and time — shift from a point on the timeline.
4. Math — evaluate a formula.
5. Plain substitutions for every {…} and array path.

In practice you cannot assume constants substitute everywhere first and only then conditions run. Loops and conditions expand first (respecting nesting), then “simple” braces.

1. {#EACH} … {/EACH}          — array loops
2. {#IF} … {#ELSE} … {/IF}   — conditions
3. {#DATETIME; … ; …}        — date and time
4. {#MATH} … {/MATH}         — formulas
5. {PREFIX.TYPE.NAME} + paths — plain substitutions and [...]

7.1. Loop {#EACH} … {/EACH}

Suppose {DEMO.ARRAY.PRODUCTS} contains:

[
  {
    "title": "Apple",
    "price": 50
  },
  {
    "title": "Pear",
    "price": 70
  }
]

Loop template (line breaks for readability; a single line in the field is also fine):

Catalog:
{#EACH {DEMO.ARRAY.PRODUCTS} @N as P}
  {P}['title'] — {P}['price'] RUB;
{/EACH}

Catalog: Apple — 50 RUB.; Pear — 70 RUB.;

The line above is the intended output. The loop header names the array, the row counter (@N), and the current element (P); the body uses {@N}, {P}['field'], and other constants as needed.

If the key is not an array or the loop markup is wrong, the text may stay unchanged or the loop may not run.

7.2. Condition {#IF} … {#ELSE} … {/IF}

Same two-item array as above. Template:

{#IF LEN({DEMO.ARRAY.PRODUCTS}) > 0}
  The catalogue has items
{#ELSE}
  Catalogue is empty
{/IF}

The catalogue has items

Catalogue is empty

What is allowed in a {#IF} expression

The condition text—from {#IF} to the branch boundary ({#ELSE} or {/IF})—is parsed as one expression. Below are typical grammar pieces; the exact set can depend on the editor version, but these match how the parser usually expects tokens literally, without hidden synonyms.

In practice: write AND/OR in capitals and separate them with spaces from field names and constants; watch quotes and escaping in strings. For debugging a complex condition, temporarily print intermediate pieces in another field or simplify with parentheses until literals and references substitute as you expect.

7.3. Date and time {#DATETIME}

The block expects a correctly filled instant structure: date, time, zone, timestamp — in the shape your constant provides. The idea: take a moment, e.g. from {MAIN.ARRAY.EVENT}['start'], add an offset (e.g. two days), and get one result string.

Missing data or wrong format — instead of a date you often see a bracketed diagnostic message, which makes drafts and debugging easier to spot.

{#DATETIME;
  …source parameters (constant holding the instant)… ;
  …offset and output format…
}

Shift modifier: sign + or -, then an integer, then one unit (Latin, as in the parser):

Meaning: + 2 days is forward two days, - 1 weeks is back one week (the exact spelling in the third part of {#DATETIME;…;…} is defined by your editor). Other block syntax and the result string format can differ by version; what matters is a valid instant in the source constant and a modifier written consistently with the parser.

7.4. Math {#MATH} … {/MATH}

Suppose {DATA.ARRAY.LINE} holds:

{
  "qty": 3,
  "price": 100
}

Template:

Due:
{#MATH}
  {DATA.ARRAY.LINE}['qty'] * {DATA.ARRAY.LINE}['price']
{/MATH}
RUB

Due: 300 RUB

Typical operations inside a formula:

References {…}['field'] inside MATH must resolve to a number or a string readable as a number. Otherwise you get an error-marked block inside {#MATH}…{/MATH} — e.g. division by zero or an “empty” value.

Special blocks are parsed before plain substitutions; on a markup or data error you usually get either unchanged “silent” text as in the editor, or an explicit bracketed message, or inside {#MATH} a #ERROR prefix with details. Typical cases for each construct are summarized below.

Special-construct error table

{#EACH}

{#IF} / {#ELSE} / {/IF}

{#DATETIME;…}

{#MATH}…{/MATH}

Constants and data outside special blocks

• First confirm the upstream block actually writes the constant you need — from the block name and field hints.
• Insert substitution templates only where expressions are enabled.
• For arrays, match the real shape: list vs object, exact field names; to verify, temporarily print the whole constant.
• Split complex markup: a condition or loop in one step, “clean” text with simple STRING in another.
• Bracketed error text in a message usually points to a condition or date/time issue, not a full bot failure.