Skip to main content

​
What are Composite Tools?

Most tools perform one action — send an SMS, call a webhook, extract a value. A composite tool wraps an entire pre-built conversation behind a single step: asking questions, reading values back, handling corrections and retries, and calling services along the way. You place one step in your flow; on the call it runs a complete, tested multi-step exchange. Each composite tool has its own page describing what it does and handles, its modes and use cases, and every input, output and variable: You may also see older provider-specific booking composites (for example Calendly | Book Time in Calendar | Pro) when their integration is connected — these are superseded by Book Calendar Appointment | Pro and shouldn’t be used in new flows. See Tools Overview. You configure a composite exactly like any other tool: open the step in the Script tab of your call script, choose the tool from the picker, fill in its inputs, and press Save tool configuration. Text inputs offer a Use variable / Use literal toggle, and you can insert variables by typing / in supported fields.

​
How a composite tool runs

When your script is prepared for calling, each composite step is expanded into its own private copy of the tool’s wrapped conversation — so two Data Collection steps in the same script run as two independent sequences, each with its own configuration. On the call, a composite step runs in four stages:
  1. Inputs are handed in. Each input you configured is resolved (variables are substituted) and written into the tool’s working variables as the step starts.
  2. The wrapped conversation runs. The caller experiences it as a natural exchange — they never know a “sub-flow” is running.
  3. The result routes your step. Every composite finishes with a true/false result: true follows your step’s first condition, anything else follows the final otherwise condition — the same routing convention as every other tool.
  4. Outputs are written back. Named outputs (like Data Collection’s Collected Value) are copied onto the variables you chose in the step’s Output mapping section.

​
Working variables are shared across the whole call

Each composite works in its own variable namespace — Data Collection in {{data_collection.*}}, Arrange Callback in {{callback.*}}, calendar booking in {{calendar.*}}, the SMS email round-trip in {{sms.*}}. These namespaces are call-wide, not per-step:
  • A second use of the same composite later in the call overwrites the namespace. If you need a result to survive, map it onto a durable variable (a contact field or a custom variable) in Output mapping — don’t rely on reading it out of the tool’s namespace in later steps.
  • Fields beginning temp_ in these namespaces are the tool’s private working state. Never read or write them from your own steps.

​
Result routing and Output mapping

Every composite’s first output is a hidden boolean result that routes your step’s conditions rather than being mapped. Composites that produce a value expose it as a named output — these appear in the Output mapping section of the tool panel (“Map outputs to global and custom variables to use them in later steps”). Each named output publishes one of the tool’s working variables. When the composite finishes, the final value of that variable is copied to whichever variable you map the output to. For example, mapping Data Collection’s Collected Value output to {{contact.first_name}} (string, e.g. Jane) writes the confirmed name straight onto the contact record. Two conventions worth following:
  • Map outputs to durable variables. Contact fields ({{contact.*}}) for standard contact data, custom variables for everything else — never leave an important result sitting in the tool’s own namespace.
  • Close the loop with skip inputs. Where a composite has a “skip if already set” style input, point it at the same variable the output writes to, so repeat visits skip cleanly instead of re-collecting.
An unmapped output isn’t lost mid-call — the value still exists in the tool’s namespace — but it will be overwritten by the next use of the same tool and is not written anywhere durable.

​
Script inheritance and commit_composite_outputs()

Two further behaviours matter mainly if Voxworks builds custom composite tools for your team:
  • Script inheritance. A step inside a wrapped conversation can be marked with [#inherit-script 'description']. At expansion time that marker is replaced with the script you wrote on the calling step itself, so one composite can speak differently in each place you use it. The standard composites take their wording through dedicated inputs instead (First Message, Custom Opening Ask, Opening Line).
  • commit_composite_outputs(). Inside a wrapped conversation built with Code Steps, this function publishes the composite’s declared outputs to your mapped destinations immediately, so exit paths that carry meaningful state deliver their outputs even on an early finish. It is never needed for ordinary variable writes — an assignment inside a composite persists instantly, and the very next step in the parent flow reads the new value.
There is no in-app editor for building composite tools yourself. Speak to the Voxworks team for further custom configuration.

​
Next Steps