Available on the Corporate plan. This capability is part of woku’s enterprise features. Talk to our sales team.
Where transformations live
Transformations are part of a data flow. A flow works over a published data source and decides, row by row, which action to run: send a survey, invite the respondent to leave feedback, create a client, or update their data. Before evaluating those rules, the flow can transform each record: clean values, derive new fields, normalize formats, or discard rows that are not useful. You find the module in the Data group of the side menu, next to Data source.How a transformation is built
You do not write the transformation from scratch. The flow builder is conversational:1
Describe what you need
In the builder chat you explain in natural language what you want
to do, for example “combine first name and last name into a single field, classify
the NPS as promoter, passive, or detractor, and discard the rows with no email or
phone”.
2
The agent generates the code
The agent writes the complete JavaScript code of the flow, including the
transformations, and shows it in two synchronized representations:
Pseudocode, a human description of each step, and Code, the
actual JavaScript, which you can edit by hand if you prefer to adjust something
directly.
3
Validate with a simulation
The Simulation tab runs the code over the sample records
of the source, without sending messages or modifying clients, and
shows you the effect of each transformation row by row.
Field transformation
Inside the flow code, transformations operate over each record with explicit operations:setField derives or modifies a field,
discardRecord discards the row with a reason, and hold leaves it on hold
with no action. There are also helpers like normalizePhone, which brings phones to
international format, and hasContent, which verifies that a field has
real content.
These are examples of fragments like the ones the agent generates, and that you can
adjust in the Code tab:
Simulation and versions
The Simulation tab is the way to validate a transformation before it touches real data. It runs the code over the saved sample of the source and returns a breakdown by result, examples of records with the detail of the transformations applied to each row, and a validation that the referenced fields exist and the commands are valid. The flow code is versioned. On running, if the code changed since the last run, a new version is frozen. From the history you can see any previous version in read-only mode and restore it as the current version, and each run is recorded with the version it used.Execution and runtime isolation
Flow execution is manual and always runs on the server side. The code runs in an isolated context, without network access or file system access: it can only read the input record and express what to do with it through the flow operations. You do not expose credentials nor maintain your own infrastructure.Best practices
- Null tolerance: source data may come in incomplete; use
??andhasContentbefore computing or concatenating. - Explicit derived fields: prefer creating new fields
(
fullName,npsCategory,purchaseDate) instead of overwriting the originals, so that the flow rules and the simulation detail are easy to read. - Discard with a reason: when a row is not useful, use
discardRecordwith a clear reason. The reason appears in the simulation and in the history, and makes it easier to understand why a record did not generate an action. - Simulate before running: validate the transformation in the Simulation tab and review the per-row detail before running the flow with real sends.