Skip to main content
Data flow is the module that connects your data sources with woku’s customer feedback tools. Instead of exporting records and sending things by hand, you define once what should happen with each row of the source and woku runs it for you. You find it in the Data group of the side menu, next to Data source.

​
What a data flow is

A data flow is a saved recipe that goes through the records of a published data source and decides, row by row, which action to run: send a survey, invite someone to leave feedback, create a client or update their data. Each flow works on a single source, and each record can trigger at most one action. If a record does not meet the flow’s conditions, it is discarded or left on hold, depending on what you define.

​
Creating a flow

Creation has two steps:
  1. Choose source: you select the data source the flow will work on. Only published sources appear.
  2. Build and test: you define the flow logic by talking to the agent, review the result and test it with simulations until it does exactly what you expect.

​
Building with the agent

The builder is conversational. You describe in natural language what you want to do, for example “send an NPS by WhatsApp to each client with a delivered order, and if they have no phone use the email”, and the agent generates two synchronized representations of the flow:
  • Code: the complete JavaScript code that will run on each record. You can edit it by hand if you prefer to adjust something directly.
  • Pseudocode: a human description of the flow with its title, what will happen when it runs, the transformations applied and each rule with the command it triggers.
The agent knows your company’s customer feedback tools (NPS, CSAT, CES surveys, wokus and forms) and resolves them by name, so you can ask it to “send the post-sale survey” without looking up identifiers. It also suggests a name and a description for the flow, which you can change before saving. The conversation with the agent is saved together with the flow, so you can pick it up again later to request adjustments with all the previous context. The editor has three tabs: Code, Pseudocode and Simulation.

​
Available actions

These are the actions a flow can run for each record: Besides the actions, the flow code has:
  • Transformations: setField modifies a field of the record before evaluating the rules and setClientField prepares changes to the client data.
  • Row control: discardRecord discards the record and hold leaves it on hold, with no action.
  • Helpers: normalizePhone normalizes phone numbers to international format, hasContent checks that a field has content and lookupSingle looks up a value elsewhere in the source.

​
Testing the flow

The Simulation tab runs the code over the saved sample of the source in an isolated environment. It is a safe test: no message is sent and no client is modified. The result includes:
  • A headline with how many records would receive the survey.
  • A breakdown by result: sends by channel, records that do not meet the conditions, records with no available channel, clients that would be updated and errors.
  • Sample records with the View action detail: the data used, the conditions evaluated, the transformations applied, the changes to the client and the final result of that row.
  • A validation of the flow: that the source is available, that the referenced fields exist, that the channels are available and that the commands and rules are valid.
If the source does not have a sample yet, the simulation uses synthetic data and warns about it. In that case the result is useful to review the logic, but it does not reflect your real data.

​
Running the flow

Running is manual. When you press Run, a confirmation modal summarizes the result of the last simulation so you know what will happen before confirming. When you confirm, the flow processes the records in the source sample and runs the real actions on those that meet the conditions: the NPS, CSAT and CES surveys, the woku invitations and the forms are sent through the appropriate channel, and new clients are created. The run is recorded in the history. If the source does not have a real sample, running is blocked until the source has one.

​
History and versions

Each run is kept in the history with its date, the flow version used, who ran it, how many records were reviewed, the result and the errors. You can open the per-record detail to see what happened with each row. The flow code is versioned: when you run, if the code changed since the last run, a new version is frozen. From the version history you can view any previous version in read-only mode and restore it as the current version.

​
Limits

  • Running is manual. There is no automatic scheduling of runs.
  • Both the simulation and the run operate over the saved sample of the source, with a maximum of 50 records per run.
  • Each record triggers at most one action.
  • Updating the data of an existing client is reflected in the simulation, but is not yet applied in the real run. The real run dispatches the surveys, the invitations, the forms and the creation of new clients.
  • The per-record detail in the history shows up to 50 rows.