Variables - Voxworks

Overview

This is the complete reference to every variable available during a call: the values your script, tools, conditions, response maps and Code Steps can read and write, and how tools populate them. Each field is listed with its data type and a realistic example value. A variable reference always uses double-brace notation — {{namespace.path}} — and you insert one by typing / in any supported field. If you are new to variables, read Variable notation first, then jump to the namespace you need from At a glance.

At a glance

Values are grouped into namespaces. The first part of every reference is the namespace; everything after it is the field path. Caller and call context

contact — Caller identity and contact-record fields.
call — Call-session facts: id, live transcript, current date and time, environment flags.
custom — Your free-form values and the home of your custom variables.

Scheduling

calendar — Booking inputs, availability and booking results.
timezone — The caller’s resolved timezone and verification state.
callback — The arranged-callback record and outcome.

Messaging and data capture

sms — Outbound text, collected email and send-error line.
data_collection — The result of a collect-confirm field capture.
surveys — Survey question inputs and the completed-question result.
webhook — The landing spot for a webhook response.

Transfers and consent

handoff — How the call’s handoff attempts to a person turned out.
analysis — In-call values that post-call analysis must not override, such as recording consent.

Verification

auth_check — The outcome of a caller-verification check.

Deployment-specific

auth — Caller-identity details captured for verification, read by the Auth | Check tool.
insurance — Policy, claim, FNOL and routing values for insurance deployments.
marketing — Disposition and lead-capture state for the Voxworks demo line.

Advanced — managed automatically

temp — Per-turn scratch slots maintained inside graph flows.
graph — The current position and bookkeeping within an advanced graph flow.
relationship — Rapport signals a graph flow reads to adapt how it speaks.

These specialised and engine-managed namespaces appear only in scripts built around them and are populated for you — see Specialised and engine-managed namespaces.

Variable notation

The user-facing notation is:

{{namespace.path}}

Examples:

{{contact.first_name}}
{{contact.email}}
{{calendar.booking_time_raw}}
{{insurance.claim.response_status}}
{{custom.claim_number}}

The first segment is the namespace; everything after it is the field path. The namespace must start with a letter or underscore, and the path must have at least two segments — a single token such as {{total}} is treated as ordinary text, not a variable. Do not put spaces inside the braces: write {{contact.first_name}}, never {{ contact.first_name }}. Insert references by typing / in any supported field to pick from the list, or type them by hand.

Reading variables

Use a variable reference inside text where you want the value inserted.

Thanks {{contact.first_name}}, I have your email as {{contact.email}}.

If the values exist, the caller may hear:

Thanks Jane, I have your email as jane@example.com.

A variable that has not been written yet resolves to an empty value. In tool inputs a missing variable simply becomes empty; in spoken script text an unresolved reference is dropped and noted internally for debugging. {{call.transcript.full}} is expanded first, before any other reference, so you can safely feed it to extraction tools.

Writing variables

Tools that write values expose a field such as Destination, Response Map or Output Map. Point it at a variable reference using the same notation:

{{contact.email}}
{{custom.claim_number}}
{{custom.appointment.datetime}}

The custom, call, contact and temp namespaces accept any field you write. The other namespaces have a fixed set of fields (the ones listed below): writing to a field that is not part of the namespace is ignored, and a later step reads that reference back empty. If you need a new field in one of the fixed namespaces, speak to the Voxworks team for further custom configuration.

Custom variables

Use the custom namespace for values that do not belong to a fixed system namespace.

{{custom.claim_number}}
{{custom.customer_sentiment}}
{{custom.appointment.datetime}}

Custom paths are free-form and can be nested — no setup is needed, they are empty until a step writes them, and they are scoped to the call. Installed custom variable types also surface here as {{custom.<type_name>.<field_path>}}, and the whole instance is available as {{custom.<type_name>}}. Always keep the custom. prefix — {{type_name.field}} on its own will not resolve. See Custom variables and Custom variable types for how these are defined and linked to contacts.

Nested reads

Some variables hold a whole object, such as a webhook response or a booking record. Read a nested field by adding a dotted path immediately after the reference — the stored value is resolved first, then the suffix digs into it.

{{webhook.response}}.data.customer.id
{{callback.record}}.window_spoken
{{custom.order_lookup}}.status

Response maps

A response map has the destination variable on the left and the source path (into the tool’s response) on the right.

{{custom.customer_id}} -> data.customer.id
{{contact.email}}      -> data.customer.email
{{custom.status}}      -> status

The left side is where the value is stored; the right side is where to find it in the response. An empty source path stores the whole response body.

Code step examples

Read a value:

def run():
    email = {{contact.email}}
    return bool(email)

Write a value (the assignment persists immediately, so the next line or step reads the new value):

def run():
    email = {{contact.email}}
    {{contact.email_verified}} = bool(email and "@" in email)
    return {{contact.email_verified}}

Write a custom value:

def run():
    {{custom.customer_status}} = "verified"
    return True

Guard reads that might be empty with str({{custom.value}} or ""). See the Code Step docs for the full run() contract.

Where variables work

Variables are substituted in:

Voice step scripts
Condition next-step logic
Tool input maps and response maps
Function and Code Step logic
SMS message content
LLM tool response maps and destinations

Variable lifecycle

Call starts
   → Contact and other record-backed values are populated
   → Values written by tools are still empty

During the conversation
   → Tools, functions and Code Steps write values
   → Every variable is available to every step and sub-flow

Call ends
   → Variables are stored as end-of-call data

A written value has nothing in it until the step that populates it runs. Always place the populating step before any step that reads the value.

Namespace reference

Every namespace available in a call is listed below with its fields, data types and example values. The Written by note under each namespace shows how the values are populated.

`contact`

The caller’s contact record. Seeded at call start from the matched contact, and readable throughout the call. Fields backed by a stored record persist back to the contact after the call. Written by: Seeded at call start, then updated when you map a capture tool’s result onto a contact field (Data Collection, SMS email collection) or when the caller confirms a correction to their name or timezone during the call.

Variable	Type	Example	Description
`{{contact.full_name}}`	string	`Jane Citizen`	The contact’s full name.
`{{contact.first_name}}`	string	`Jane`	The contact’s first name. If missing at call start it is derived from the full name.
`{{contact.last_name}}`	string	`Citizen`	The contact’s last name.
`{{contact.email}}`	string	`jane.citizen@example.com`	The contact’s email address.
`{{contact.email_verified}}`	string	`jane.citizen@example.com`	The contact’s email once verified through a round-trip check.
`{{contact.phone}}`	string	`+61412345678`	The contact’s phone number.
`{{contact.company}}`	string	`Acme Pty Ltd`	The contact’s company name.
`{{contact.timezone}}`	string	`Australia/Brisbane`	The contact’s IANA timezone. Drives the user timezone for spoken times; falls back to the team timezone when not set or invalid.
`{{contact.location}}`	string	`Brisbane, Queensland`	The contact’s location text (city/state), kept alongside the resolved timezone.
`{{contact.address}}`	string	`12 Wattle St, Brisbane QLD 4000`	The contact’s street address.
`{{contact.date_of_birth}}`	string	`1985-03-12`	The contact’s date of birth.

`call`

Call-session facts kept up to date automatically for the current call. The date and time fields are computed fresh on every read in your team timezone, so a long call that crosses midnight sees the new values. Written by: Maintained automatically by the platform for the call session.

Variable	Type	Example	Description
`{{call.room_id}}`	string	`RM_x7Kd93hf2ab4`	The unique identifier for the current call session.
`{{call.transcript}}`	object	`{"full": "[ ...chat items... ]"}`	Container for the computed transcript reference.
`{{call.transcript.full}}`	string	`[{"role": "assistant", "content": "Hi, this…`	The full conversation so far, expanded at render time from the live chat context as a JSON array of chat items (function calls, images and audio excluded). Standard input for LLM Data / LLM Custom extraction and the Send Webhook transcript payload. It is substituted in its own pass before other variables.
`{{call.current_date}}`	string	`2026-07-15`	Today’s date in the team timezone, format YYYY-MM-DD. Computed fresh on every read (a long call crossing midnight reads the new date).
`{{call.current_day}}`	string	`Wednesday`	Today’s weekday name in the team timezone, e.g. Monday. Computed fresh on every read.
`{{call.current_time}}`	string	`14:32`	The current clock time in the team timezone, 24-hour format HH:MM. Computed fresh on every read.
`{{call.is_prod}}`	boolean	`True`	True when the call is running in the production environment. Use to gate copy or side effects that must not fire in testing.
`{{call.is_test}}`	boolean	`False`	True when the call is running in the test environment.
`{{call.live_sentiment}}`	number	`0.42`	The caller’s running mood score for the call, from `-1.00` (very negative) to `+1.00` (very positive). Starts at `0.00` and updates after each caller turn, weighted towards the most recent turns. Route on it to soften the approach or hand a frustrated caller to a person.

`custom`

Your own per-call values plus the home of your custom variables. Any {{custom.<path>}} of two or more segments works without any setup — write to it from a Code Step, an LLM tool or a webhook and read it back later. Installed custom variable types appear under this namespace in the / picker as {{custom.<type_name>.<field>}}. See Custom variables and Custom variable types. Written by: You — via Code Step, LLM Custom, or any tool with a {{custom.…}} destination. Custom variable types are seeded from your team’s records.

Variable	Type	Example	Description
`{{custom.<free_form_path>}}`	any	`{{custom.route_index}} = 4`	Undeclared per-call scratch, e.g. `{{custom.route_index}}`, `{{custom.question_1}}`. Empty until a step writes it; scoped to the call.
`{{custom.<type_name>.<field_path>}}`	per field	`{{custom.survey_ro_sc.result}} -> "The Greens"`	A field of an installed custom variable instance, e.g. `{{custom.survey_ro_sc.result}}`, `{{custom.nepean_byelection_poll.question_5.jacinta_allan}}`.
`{{custom.<type_name>}}`	object	`{{custom.survey_ro_sc}}`	The whole custom variable instance as one object - what the Survey tool’s question-config input takes and what its output maps back onto.

`calendar`

Booking inputs and the availability and booking results produced by the calendar tools. The inputs marked Input are set on the booking tool’s own fields; everything else is written back for your confirmations and routing. Common calendar settings live on Calendar tools. Written by: Book Calendar Appointment | Pro.

Variable	Type	Example	Description
`{{calendar.event_id}}`	string	`evt_9f2ab4c1`	The calendar provider’s event/meeting-type identifier the booking targets.
`{{calendar.purpose}}`	string	`Product demo`	Input: what the meeting is for - captured from conversation or set in tool config; lands in the booking record.
`{{calendar.meeting_kind}}`	string	`demo`	Input: the kind of meeting being booked (drives copy and provider event selection).
`{{calendar.duration_minutes}}`	integer	`30`	Input: meeting duration in minutes for the booking.
`{{calendar.location}}`	string	`Google Meet`	Input: meeting location (address or ‘phone’/‘video’) for the booking record.
`{{calendar.sms_flag}}`	boolean	`True`	Input toggle: send an SMS confirmation after booking (drives the tool’s SMS confirmation branch via `{{sms.message}}`).
`{{calendar.availability_raw}}`	string	`["2026-07-21T14:00:00+10:00", "2026-07-21T15…`	Raw availability slot list (JSON, ISO datetimes) fetched from the provider; re-rendered into the caller’s timezone when the resolved zone changes.
`{{calendar.availability_spoken}}`	string	`I have Tuesday the 21st at 2 PM, or Wednesda…`	Speakable summary of the most relevant available slots, formatted for reading aloud.
`{{calendar.availability_error_spoken}}`	string	`I'm having trouble reaching the calendar rig…`	Speakable error text when availability could not be fetched.
`{{calendar.booking_time_raw}}`	string	`2026-07-21T14:00:00+10:00`	The booked slot in raw ISO form.
`{{calendar.booking_time_spoken}}`	string	`Tuesday the 21st of July at 2 PM`	The booked time phrased for speech (used in confirmations).
`{{calendar.booking_time_written}}`	string	`Tue 21 Jul 2026, 2:00 PM AEST`	The booked time formatted for written channels (SMS/email confirmations).
`{{calendar.booking_id}}`	string	`bkg_58d21aa7`	The provider’s identifier for the created booking.
`{{calendar.booking_link}}`	string	`https://cal.example.com/b/58d21aa7`	Link to the created booking (join/manage URL) for confirmations.
`{{calendar.booking_error_spoken}}`	string	`That slot was just taken - shall we try anot…`	Speakable error text when the booking attempt fails (cleared to empty on success).
`{{calendar.booking_status}}`	string	`booked`	Outcome status of the booking exchange, read by the parent flow after the tool returns.
`{{calendar.handoff_message}}`	string	`Caller wants a Tuesday demo but no slots mat…`	Message passed along if the booking flow escalates to a human handoff.

`timezone`

Timezone verification state. Seeded from the contact’s stored timezone at call start, then updated as the caller’s location is confirmed. Use {{timezone.resolved_iana}} as the zone the caller’s times are quoted in. Written by: Book Calendar Appointment | Pro, when its timezone check is enabled.

Variable	Type	Example	Description
`{{timezone.check_timezone}}`	boolean	`True`	Input toggle: when true the flow runs timezone verification before quoting times (exposed as an input on the calendar booking tool).
`{{timezone.record_iana}}`	string	`Australia/Sydney`	The IANA zone already stored on the contact record (pre-verification baseline).
`{{timezone.record_state}}`	string	`New South Wales`	State/region resolved from the contact’s stored timezone.
`{{timezone.record_city}}`	string	`Sydney`	City resolved from the contact’s stored timezone.
`{{timezone.record_label}}`	string	`Australia/Sydney`	Display label of the contact’s stored timezone.
`{{timezone.resolved_city}}`	string	`Brisbane`	Final resolved city after verification (or from the contact record when no check was needed).
`{{timezone.resolved_state}}`	string	`Queensland`	Final resolved state after verification.
`{{timezone.resolved_iana}}`	string	`Australia/Brisbane`	Final resolved IANA zone - the zone used to render availability and spoken times for the caller.
`{{timezone.resolved_location}}`	string	`Brisbane, Queensland`	Final resolved location display text (city + state).
`{{timezone.check_flag}}`	boolean	`True`	Set true once a timezone has been established for the caller (either from the record or by verification) - flows read it to skip re-asking.
`{{timezone.check_contact_result}}`	boolean	`False`	True when the contact record already had a usable timezone at call start.
`{{timezone.flag_result}}`	boolean	`True`	Set true once the resolved timezone has been written back to the contact record (false at call start).

`callback`

State for arranging a callback. The record object is written every time the tool finishes and carries everything a person or the assistant needs to make the callback. Its input fields are configured on the tool. Written by: Arrange Callback | (BETA).

Variable	Type	Example	Description
`{{callback.callback_status}}`	string	`arranged`	Outcome of the exchange: arranged \| declined \| busy \| no_window. The parent flow routes on this after the tool returns.
`{{callback.record}}`	object	`{"type": "human", "name": "Jane", "endpoint"…`	The callback record object, written every time the tool finishes, even when no callback was scheduled, holding everything a dispatcher needs. Reference the whole object with `{{callback.record}}` or individual fields via the nested paths below.
`{{callback.record.type}}`	string	`human`	Record field: assistant or human callback.
`{{callback.record.name}}`	string	`Jane Citizen`	Record field: the name to ask for on the callback.
`{{callback.record.endpoint}}`	string	`sales_team`	Record field: the endpoint that will make the callback.
`{{callback.record.purpose}}`	string	`Discuss upgrade options`	Record field: purpose of the callback.
`{{callback.record.days}}`	string	`["2026-07-21", "2026-07-22"]`	Record field: the accepted callback dates as a JSON list of ISO dates.
`{{callback.record.is_range}}`	boolean	`False`	Record field: true when the accepted days form a range rather than a single day.
`{{callback.record.period}}`	string	`afternoon`	Record field: the period of day as the caller phrased it.
`{{callback.record.window_clock}}`	string	`14:00-16:00`	Record field: the accepted window as HH:MM-HH:MM in the endpoint schedule’s timezone.
`{{callback.record.window_spoken}}`	string	`Tuesday between 2 and 4 PM`	Record field: the window phrase as it was confirmed with the caller.
`{{callback.record.status}}`	string	`arranged`	Record field: arranged when a window was agreed; unscheduled when the tool finished without one.
`{{callback.record.created_at}}`	string	`2026-07-15T14:35:02+10:00`	Record field: creation timestamp of the record.
`{{callback.record.notes}}`	string	`Prefers mobile; do not call before lunch.`	Record field: free-text hints for whoever makes the callback.

`sms`

SMS results. {{sms.message}} is the outbound text, {{sms.email}} is the address collected and validated by the round-trip email tool, and {{sms.send_error_spoken}} gives the agent a natural line to say if a send fails. The email tool’s opening, body and fallback lines are configured on the tool itself. See Send SMS and Read SMS. Written by: SMS | Get Valid Email, SMS | Send to contact, SMS | Read from contact.

Variable	Type	Example	Description
`{{sms.message}}`	string	`Your appointment is confirmed for Tuesday 21…`	Generic outbound SMS text slot; also used by the calendar booking tool’s SMS confirmation.
`{{sms.email}}`	string	`jane.citizen@example.com`	The email address collected and validated by the SMS round-trip (read back from the caller’s reply).
`{{sms.send_error_spoken}}`	string	`I wasn't able to send that text message just…`	Speakable error text set when an outbound SMS fails to send, so the agent can explain the failure naturally.

`data_collection`

The generic collect-confirm-spell field-capture tool exposes just two results your flow reads after it returns. Everything it needs to run the exchange is configured on the tool’s own fields. See Data collection. Written by: Data Collection.

Variable	Type	Example	Description
`{{data_collection.output_result}}`	string	`jane.citizen@example.com`	Output: the final collected value. The parent flow reads (and usually maps) this after the tool returns.
`{{data_collection.output_extracted}}`	boolean	`True`	Output: true when a value was successfully collected; false when the tool gave up.

`surveys`

State for the Survey tools. The question configuration arrives as a custom variable instance, and the completed question is written back to {{surveys.output_obj}}, which the tool maps onto the same custom variable instance. The per-question capture is handled for you. Written by: Survey and Survey (graph).

Variable	Type	Example	Description
`{{surveys.input_type}}`	string	`survey_ro_sc`	Input: which survey question family to run (matches the custom variable type, e.g. survey_ro_sc).
`{{surveys.input_obj}}`	object	`{{custom.nepean_byelection_poll.question_1}}`	Input: the full question configuration - a custom variable instance passed whole (e.g. `{{custom.survey_ro_sc}}`).
`{{surveys.input_mode}}`	string	`standard`	Input: standard question or screening mode (screen mode records pass/fail rather than just an answer).
`{{surveys.output_obj}}`	object	`{"question": "...", "result": "The Greens",…`	Output: the completed question object with the recorded result - the tool’s output maps this back onto the custom variable instance (e.g. `{{custom.survey_ro_sc}}`).

`webhook`

The conventional landing spot for a Send Webhook response. Map the response with an empty path in the tool’s Response Map to capture the whole body here, then dig into it with a dotted suffix. See Send Webhook. Written by: Send Webhook.

Variable	Type	Example	Description
`{{webhook.response}}`	string	`{"status": "ok", "customer": {"id": "C-1042"…`	Catch-all destination for a Send Webhook response body: map it with an empty path in the tool’s Response Map to capture the whole response. Because a dotted suffix digs into resolved JSON, downstream steps can read `{{webhook.response}}.fieldname` to extract a field.

`handoff`

The outcome of the call’s handoff attempts, so a script can tell why a transfer to a person did not work and respond honestly instead of guessing. Written after every attempt, whether it came from Live Handoff, the Warm Handoff tool, or a handoff triggered on a live call. Route on {{handoff.last.status}}. Written by: The platform, at the end of each handoff attempt.

Variable	Type	Example	Description
`{{handoff.attempts}}`	number	`2`	How many handoff attempts have finished on this call. `0` before the first attempt.
`{{handoff.connected}}`	boolean	`True`	True once any attempt reached the point where the caller and the team member were connected.
`{{handoff.last.status}}`	string	`rejected`	Outcome of the most recent attempt: `connected`, `rejected`, `busy`, `timeout`, `voicemail`, `routing_unavailable`, `no_trunk` or `error`. Empty before the first attempt.
`{{handoff.last.timed_out}}`	boolean	`False`	True when the last attempt rang out — the same as `{{handoff.last.status}}` being `timeout`, in a form that is easy to route on.
`{{handoff.last.reason}}`	string	`CALL_REJECTED`	The underlying cause detail for the last attempt.
`{{handoff.last.duration_seconds}}`	number	`4.8`	How long the last attempt took, from dialling to outcome. A rejection that comes back in seconds looks very different from a genuine ring-out.
`{{handoff.last.timeout_seconds}}`	number	`180`	The timeout the last attempt was configured with. `0` when none was set.
`{{handoff.last.endpoint_id}}`	string	`3f6c2c1a-8b0d-4e2f-9a41-6c7d5e8f9a01`	The routing endpoint the last attempt dialled.

`analysis`

Values captured during the call that post-call analysis must not override. Written by: Your script — a Data Collection step, a Code Step, or any tool with an {{analysis.…}} destination.

Variable	Type	Example	Description
`{{analysis.standard.recording_approved}}`	string	`agreed`	The caller’s recording consent: `agreed`, `declined` or `not_disclosed`. Set it to `declined` and no recording of the call is kept. Empty until your script writes it, which means the call is recorded as normal.

`auth_check`

The result set written by the verification tool after it compares the caller’s answers against the record. Route on {{auth_check.verified}} or {{auth_check.status}}. See Auth Check. Written by: Auth | Check.

Variable	Type	Example	Description
`{{auth_check.verified}}`	boolean	`True`	Overall verification outcome - true when enough checks matched.
`{{auth_check.status}}`	string	`verified`	Verification status word for routing and copy (e.g. verified / failed / error).
`{{auth_check.matched_count}}`	integer	`2`	How many verification checks matched.
`{{auth_check.required_count}}`	integer	`2`	How many checks were required to pass verification.
`{{auth_check.matched_checks}}`	json	`["full_name", "date_of_birth"]`	List of the check names that matched.
`{{auth_check.failed_checks}}`	json	`["vehicle_registration"]`	List of the check names that failed to match.
`{{auth_check.exact_match}}`	boolean	`True`	True when the match was made on exact string comparison.
`{{auth_check.semantic_match}}`	boolean	`False`	True when the match was made semantically (LLM-judged equivalence rather than exact text).
`{{auth_check.method}}`	string	`exact`	Which matching method produced the result.
`{{auth_check.notes}}`	string	`DOB matched after format normalisation`	Free-text notes about the verification outcome (also surfaced in the call’s system note).
`{{auth_check.verified_data}}`	string	`full_name=Jane Citizen; date_of_birth=1985-0…`	Summary of the data points that were verified, for downstream display or logging.

Specialised and engine-managed namespaces

These namespaces are not general-purpose variables you author — they belong to specific flow types and are populated for you, so you will only see them in the / picker on a script that was built around them. auth and insurance back specific customer deployments (identity verification, policy and claim lookup, First Notice of Loss lodgement); marketing is the Voxworks demo line; and temp, graph and relationship are maintained automatically inside advanced graph-based flows. Speak to the Voxworks team for further custom configuration.

`auth`

Caller-identity details captured before verification, consumed as the inputs of the Auth | Check tool. A legacy shape built for an insurance client’s caller-verification flow. Written by: Code Step / LLM | Data extraction steps in the flow, ahead of Auth | Check.

Variable	Type	Example	Description
`{{auth.user}}`	object	`{"full_name": "Jane Citizen", "date_of_birth": "1985-03-12"}`	Container object for the identity details captured from the caller before verification.
`{{auth.user.full_name}}`	string	`Jane Citizen`	The caller’s full name as captured for verification.
`{{auth.user.first_name}}`	string	`Jane`	The caller’s first name as captured for verification.
`{{auth.user.last_name}}`	string	`Citizen`	The caller’s last name as captured for verification.
`{{auth.user.date_of_birth}}`	string	`1985-03-12`	The caller’s stated date of birth used as a verification check.
`{{auth.user.vehicle_registration}}`	string	`ABC123`	The caller’s stated vehicle registration used as a verification check.

`insurance`

The namespace behind an insurance deployment: policy and contact details, claim lookup results, First Notice of Loss (FNOL) draft identifiers, incident/vehicle/complaint capture, intent-menu state and sub-organisation routing metadata. Backed by the claims-system integration. Written by: FiveSigma | Get Claim and FiveSigma | Post FNOL, plus the deployment’s own policy lookup and capture steps (Code Step / LLM | Data).

Variable	Type	Example	Description
`{{insurance.policy}}`	object	`{"id": "POL-448291", "contact_first_name": "Jane"}`	Container for the caller’s policy details.
`{{insurance.policy.id}}`	string	`POL-448291`	The identified policy number.
`{{insurance.policy.contact_full}}`	string	`Jane Citizen`	Full name of the policyholder contact on record.
`{{insurance.policy.contact_first_name}}`	string	`Jane`	First name of the policyholder contact.
`{{insurance.policy.contact_last_name}}`	string	`Citizen`	Last name of the policyholder contact.
`{{insurance.policy.contact_phone}}`	string	`+61412345678`	Phone number of the policyholder contact.
`{{insurance.policy.contact_email}}`	string	`jane.citizen@example.com`	Email of the policyholder contact (used e.g. as an SMS/email confirmation target).
`{{insurance.policy.endpoint_queue}}`	string	`claims_general`	Primary handoff/routing queue for this policy.
`{{insurance.policy.endpoint_queue_2}}`	string	`claims_overflow`	Secondary handoff/routing queue for this policy.
`{{insurance.policy.endpoint_queue_3}}`	string	`claims_afterhours`	Tertiary handoff/routing queue for this policy.
`{{insurance.policy.url}}`	string	`https://portal.insurer.example/policies/POL-448291`	URL of the policy record in the deployment’s system.
`{{insurance.policy.phone}}`	string	`+61390001234`	The policy line / callback phone number associated with the policy.
`{{insurance.claim}}`	object	`{"id": "CLM-2210", "response_status": "open"}`	Container for claim lookup results.
`{{insurance.claim.id}}`	string	`CLM-2210`	The claim identifier looked up or referenced (also passed in handoff payloads).
`{{insurance.claim.response_full}}`	string	`{"claim": {"id": "CLM-2210", "status": "open"}}`	The full claim lookup response payload for downstream reads.
`{{insurance.claim.response_status}}`	string	`open`	Status extracted from the claim lookup (drives routing and copy).
`{{insurance.fnol}}`	object	`{"draft_id": "FNOL-88412"}`	Container for First Notice of Loss lodgement identifiers.
`{{insurance.fnol.id}}`	string	`FNOL-88412`	Identifier of the lodged FNOL.
`{{insurance.fnol.draft_id}}`	string	`FNOL-DRAFT-88412`	Identifier of the FNOL draft created from the captured incident details.
`{{insurance.fnol.draft_id_spoken}}`	string	`8 8 4 1 2`	The draft id rendered for speech (digits spaced) so the agent can read the reference to the caller.
`{{insurance.incident}}`	object	`{"date_time": "2026-07-14 08:30", "location": "Pacific Hwy, Chatswood"}`	Container for captured incident details feeding the FNOL.
`{{insurance.incident.date_time}}`	string	`2026-07-14 08:30`	When the incident happened, as captured; read by FiveSigma \| Post FNOL.
`{{insurance.incident.location}}`	string	`Pacific Hwy, Chatswood NSW`	Where the incident happened; read by FiveSigma \| Post FNOL.
`{{insurance.incident.description}}`	string	`Rear-ended at the lights; rear bumper damaged.`	The caller’s description of the incident; read by FiveSigma \| Post FNOL.
`{{insurance.vehicle}}`	object	`{"registration": "ABC123", "condition": "drivable"}`	Container for captured vehicle details feeding the FNOL.
`{{insurance.vehicle.registration}}`	string	`ABC123`	The vehicle registration involved; read by FiveSigma \| Post FNOL.
`{{insurance.vehicle.condition}}`	string	`drivable`	Whether the vehicle is safe/drivable; read by FiveSigma \| Post FNOL.
`{{insurance.complaint}}`	object	`{"summary": "Unhappy with assessment delay"}`	Container for complaint capture.
`{{insurance.complaint.summary}}`	string	`Unhappy with assessment delay on claim CLM-2210.`	Summary of the caller’s complaint (also passed in handoff payloads).
`{{insurance.call_intent}}`	object	`{"intent": "new_claim", "menu_attempts": 1}`	Container for intent-menu state.
`{{insurance.call_intent.intent}}`	string	`new_claim`	The classified reason for the call (drives routing between claim lookup, FNOL, complaint and so on).
`{{insurance.call_intent.menu_attempts}}`	number	`1`	How many times the intent menu has been attempted.
`{{insurance.organisation}}`	object	`{"sub_organisation": {"name": "Example Fleet"}}`	Container for organisation routing metadata.
`{{insurance.organisation.sub_organisation}}`	object	`{"id": "ORG-01", "name": "Example Fleet"}`	Container for sub-organisation (broker/fleet partner) metadata.
`{{insurance.organisation.sub_organisation.id}}`	string	`ORG-01`	Identifier of the sub-organisation the caller belongs to.
`{{insurance.organisation.sub_organisation.reference}}`	string	`EXAMPLE-FLT`	Reference code for the sub-organisation.
`{{insurance.organisation.sub_organisation.name}}`	string	`Example Fleet`	Display name of the sub-organisation.
`{{insurance.organisation.sub_organisation.claim_identifier}}`	string	`EF-`	Claim identifier prefix/format used by this sub-organisation.
`{{insurance.organisation.sub_organisation.claim_identifier_spoken}}`	string	`E F dash`	The claim prefix rendered for speech.
`{{insurance.organisation.sub_organisation.handoff_queue}}`	string	`example_fleet_claims`	The handoff queue to use for this sub-organisation’s callers.

`marketing`

State for the Voxworks marketing/demo-line flow: booking intent, lead-capture progress, recovery fire-counters and the final call disposition. Written by: Code Steps and LLM | Custom classification steps in the Voxworks demo-line flow.

Variable	Type	Example	Description
`{{marketing.wants_booking}}`	string	`true`	`true` when the caller wants a demo booked, else `false` (string-typed true/false, not a boolean).
`{{marketing.lead_captured}}`	string	`true`	`true` once name/phone/callback have been taken (string-typed true/false).
`{{marketing.offer_made}}`	string	`false`	`true` when a callback was already offered upstream, so later steps do not re-offer (string-typed true/false).
`{{marketing.decline_count}}`	integer	`1`	Times the caller declined an offer; at 2 the flow moves to a polite close.
`{{marketing.fallback_count}}`	integer	`0`	Fire-counter for the honest defer line (“I don’t have that detail…”).
`{{marketing.clarify_count}}`	integer	`1`	Fire-counter for the repeat/clarify recovery.
`{{marketing.wrongnum_count}}`	integer	`0`	Fire-counter for the wrong-business recovery.
`{{marketing.realbook_count}}`	integer	`0`	Fire-counter for the real-world booking trap (a caller trying to make a real booking with the demo line).
`{{marketing.disposition}}`	string	`meeting_booked`	Final disposition of the call: lead_captured \| meeting_booked \| support_lead \| engaged \| declined \| terminated.
`{{marketing.lead_name}}`	string	`Sam`	The lead’s first name captured for the callback.
`{{marketing.lead_phone}}`	string	`+61400111222`	Best callback number for the lead.

`temp`

Fixed platform scratch slots for per-turn state in graph flows — ten slots each of boolean, string, number and object. You use the existing slots; you cannot add fields to this namespace. Design docs may use conventional alias names (temp.line for {{temp.string.str_1}}, temp.tone for {{temp.string.str_2}}), but the resolvable reference is always the slot path. Written by: Code Steps in graph flows (Select & Route, Line-Select and similar).

Variable	Type	Example	Description
`{{temp.boolean.bool_1}}` … `{{temp.boolean.bool_10}}`	boolean	`True`	Ten boolean scratch slots. By convention bool_1 gates speaking the precomputed line in `{{temp.string.str_1}}` and bool_4 is the no-match flag; the rest are flow-assigned.
`{{temp.string.str_1}}` … `{{temp.string.str_10}}`	string	`No problem — what day suits you best?`	Ten string scratch slots. By convention str_1 holds the precomputed spoken line and str_2 the tone; the rest are flow-assigned.
`{{temp.number.num_1}}` … `{{temp.number.num_10}}`	number	`2`	Ten numeric scratch slots (counters, indices), flow-assigned.
`{{temp.object.obj_1}}` … `{{temp.object.obj_10}}`	object	`{"candidates": ["a", "b"], "picked": 0}`	Ten object scratch slots for working JSON state, flow-assigned.

`graph`

Generic graph-runtime state — the current position within an advanced graph flow, visit and peak bookkeeping, intent-detour return addresses and line-rotation and tone counters. Flow-agnostic and maintained for you. Written by: The Code Steps emitted by the graph build (Select & Route, Line-Select and similar).

Variable	Type	Example	Description
`{{graph.node}}`	integer	`12`	The current node number within the active graph.
`{{graph.visits}}`	string	`{"main:12": 2, "main:15": 1}`	JSON map of `<graph>:<node>` to visit count — drives rung ladders (different copy by attempt).
`{{graph.peak}}`	string	`{"main": 15}`	JSON map of `<graph>` to the furthest node reached — used for progress-aware recovery.
`{{graph.return_graph}}`	string	`main`	Intent-graph return address: the graph to come back to after an intent detour.
`{{graph.return_node}}`	integer	`12`	Intent-graph return address: the node to resume at after an intent detour.
`{{graph.rot}}`	integer	`3`	Variant-rotation counter; line selection picks the variant at `rot % count` so line variety stays deterministic.
`{{graph.tone}}`	string	`warm`	Call-level tone default applied to line selection.
`{{graph.tone_directive}}`	string	`Be brisk and apologetic; the caller is short on time.`	Instruct-mode tone directive text injected into prompts for the current turn.

`relationship`

The relationship-dimension scores and their observation inputs that graph-method flows use to adapt how they speak — comfort, engagement and trust scores, per-turn observations, and the qualitative reads injected into prompts. Written by: The relationship-update and relationship-read Code Steps in graph flows.

Variable	Type	Example	Description
`{{relationship.comfort}}`	number	`0.7`	Numeric comfort score for the caller relationship, updated as the call progresses.
`{{relationship.engagement}}`	number	`0.55`	Numeric engagement score — how actively the caller is participating.
`{{relationship.trust}}`	number	`0.8`	Numeric trust score for the caller relationship.
`{{relationship.last_response_latency_s}}`	number	`1.8`	Observation input: seconds the caller took to respond on the last turn.
`{{relationship.last_user_word_count}}`	integer	`14`	Observation input: word count of the caller’s last utterance.
`{{relationship.rel_read_alignment}}`	string	`aligned`	Qualitative read of the alignment dimension for prompt injection.
`{{relationship.rel_read_comfort}}`	string	`settled`	Qualitative read of the comfort dimension for prompt injection.
`{{relationship.rel_read_status}}`	string	`steady`	Qualitative read of the status dimension for prompt injection.
`{{relationship.rel_read_trust}}`	string	`trusting`	Qualitative read of the trust dimension for prompt injection.

Common issues

A variable does not resolve — check the spelling, namespace and path.
A write is skipped — the destination may not be a valid variable reference, or the field is not part of a fixed namespace (see Writing variables).
A fixed namespace rejects a field — that field is not part of the namespace; use custom for ad-hoc values.
A nested field is empty — confirm the stored value is actually an object and the suffix matches the response shape.
{{custom.some.path}} works but {{contact.some.path}} does not — this is expected: custom is free-form, while the system namespaces have a fixed set of fields.

Best practices

Use {{...}} notation everywhere — in scripts, tool maps and Code Steps.
Use descriptive custom paths — {{custom.claim_number}} rather than {{custom.value}}.
Keep response maps small — store only the values a later step needs.
Store full responses only when needed — when several later steps read different fields from them.
Populate before you read — run the writing step before any step that references the value.

Next Steps

Custom variables — Define your own typed, per-contact data.
Tools overview — See every tool and the variables it reads and writes.
Tool steps — Pass variables to tools and map their results back.
Data collection — Capture, confirm and store values from the caller.

​Overview

​At a glance

​Variable notation

​Reading variables

​Writing variables

​Custom variables

​Nested reads

​Response maps

​Code step examples

​Where variables work

​Variable lifecycle

​Namespace reference

​contact

​call

​custom

​calendar

​timezone

​callback

​sms

​data_collection

​surveys

​webhook

​handoff

​analysis

​auth_check

​Specialised and engine-managed namespaces

​auth

​insurance

​marketing

​temp

​graph

​relationship

​Common issues

​Best practices

​Next Steps