Four additions that work together: a way to total answers into a score, and a smarter Record Lookup field to feed it.
Calculated fields. A hidden number field can now total a group of other fields tagged with a shared score group: sum, average, min, max, or count. Unanswered items in the group are excluded from the total and flagged, so a routing rule can require a complete score before acting on it. Optional bands attach a label like “low” or “high” to ranges of the total.
Live score display. A content block can interpolate that running total, and its band, mid-conversation with {{field_name}} and {{field_name.band}}. The display isn’t saved; the server recomputes the canonical value at submit, on web and WhatsApp alike.
Lookup carry values. A Record Lookup field can now copy other columns from the matched row onto the submission, for example a numeric score sitting behind a Likert-scale label. The stored answer stays the label the respondent picked; the carried value resolves on the server and writes nothing if the label matches more than one row.
Lookup row filters. A Record Lookup field can be scoped to the rows matching a column value, so one shared table can back many different questions instead of needing a separate table per question. A label that repeats across the table stays unambiguous because it resolves within its own scope.
Available on all plans.
A hidden number field can sum, average, min, max, or count other fields tagged with a score group (plain numbers or values carried from a record lookup). Unanswered items are excluded from the total and flagged as incomplete. Optional bands write a label such as low or high. The server recomputes the total at submit.
A content block can interpolate a calculated total and its band from answers so far (for example {{abandono_total}} / {{abandono_total.band}}). That display is not saved. Web and WhatsApp both write carry columns and the canonical total when the submission completes.
A record lookup field can copy other columns from the matched Record Type row onto namespaced submission paths (for example p7.score). The stored answer stays the human-readable label. Carry is resolved on the server from that label; a label that matches more than one row writes nothing.
A record lookup field can now be scoped to the rows matching a column value, for example id_pregunta equals P1. One shared option bank serves every question instead of one record type per question, the option list only offers the rows in scope, and carried values resolve inside that scope so a label repeated across the table is no longer ambiguous.