Understanding Digioh Pipelines

This article explains how Digioh pipelines work end to end: what a pipeline is, the most common task types, the structure of the data a form submission passes through, and how to read logs and add conditions. Read this first if you are new to pipelines or troubleshooting one. For ESP-specific setup and errors, see the companion Klaviyo and Iterable articles linked at the end.

What is a pipeline?

A pipeline is the layer between a Digioh form submission and your ESP or CRM (such as Klaviyo or Iterable). It receives the raw submission data, transforms it, and routes it to the destination through a series of tasks that run in order.

• Pipelines run automatically when a form is submitted.

• They transform and route submission data into the ESP using a sequence of tasks.

• They are separate from the legacy "integrations" system.

• Every execution is logged under Pipeline › Activity.

The three most common task types

A pipeline can contain many task types, but three account for the large majority of configurations:

Map Data task

The Map Data task is a row-by-row field mapper. Each row maps a value (either from the submission payload or hardcoded) and writes it to an output field, generating a JSON that is passed to the next step in the pipeline.

Copy a task's full configuration: The button in the top-right corner of a task opens its entire configuration as JSON. Copy it to reuse a complex mapping in another pipeline or account - paste it into the same button on the destination task instead of rebuilding the mappings row by row. (See the caveat under Render Template if the task references another task by ID.)

Chaining steps

One Map Data step can feed into another. Switch the Input Field dropdown from Item Data to the name of a prior step, then reference a field path inside that step's output. The output of Step A becomes the input for Step B.

For example, in a quiz pipeline the Map Quiz Results step can feed the Map Final Event Payload step:

quiz_results.[0].name → data.attributes.properties.prodRecName_1

quiz_results.[1].name → data.attributes.properties.prodRecName_2

Working with arrays

Some payload fields are arrays - sets of values rather than a single value (quiz answers and results are the common example). Reference a specific item by its position using bracket notation and starting with a zero-index:

prq.results.[0].name → name of the top recommended product

prq.results.[0].url → product URL for the top recommendation

prq.results.[1].name → second recommended product name

prq.answers.[0].page_name → first quiz page name

Klaviyo / Iterable API task

This task makes the actual API call to the ESP. Configuration is intentionally minimal because the payload was already built in the Map Data step before it.

Render Template task

The Render Template task builds a fully custom payload from scratch using a templating language. Use it when the ESP expects a very specific JSON structure that Map Data cannot produce - for example nested objects, conditional fields, or arrays of subscriptions.

Reading an example template:

{% if model.form.email != null and model.form.email != "" %}

"email": "{{model.form.email}}",

{% endif %}

This includes the email field in the outgoing payload only if the user actually submitted an email - preventing a blank email key from reaching the ESP.

The item data payload

When a form is submitted, Digioh passes a structured JSON payload with four top-level objects. You reference fields using dot notation (e.g. form.email, analytics.country_name, prq.results_url). A full list of the available fields is available here.

Quiz data: the prq object

The prq object is only included on quiz submissions. It contains three sub-objects:

Because prq.answers and prq.results are arrays, reference individual items by position:

prq.answers.[0].page_name → "Bike type" (first quiz page)

prq.answers.[1].entries.[0].value → "Performance Oriented" (display label)

prq.results.[0].name → "KICKR CORE 2" (top product)

prq.results_url → shareable results page URL

Accessing and reading logs

Pipeline logs live under Pipeline › Activity. Each log shows the full request sent to the ESP (your mapped payload) and the full response (where errors surface).

• You can re-run a log from the log detail view using Test Pipeline - useful for testing a fix without waiting for a new live submission. On quiz pipelines, this reprocesses the full payload without retaking the quiz. You can even edit the previewed payload (e.g. change the email) before re-running.

Adding conditions to tasks

Any task in a pipeline can be given a condition so it only runs when specific criteria are met. This is key for multi-step pipelines that route data differently based on what the user submitted. Any payload field (form.*, analytics.*, attributes.*, prq.*) can drive a condition. Examples:

• Only run a Klaviyo step if form.opt_in equals true.

• Skip the SMS step if form.phone is empty.

• Route to different lists based on a quiz answer.

• Run a step only for US visitors (analytics.country = US).

Conditions are configured similarly to a Map Data step.

One pipeline or several?

Whether to split work across multiple pipelines or keep it in one depends on reuse and complexity.

• Use separate pipelines when a flow should be reused across several campaigns - for example a shared sign-up pipeline that you connect to many campaigns, while only some of those campaigns should also trigger a quiz-submission pipeline.

• Keep related steps in one pipeline when the logic is simple - a typical Iterable flow of update profile, then subscribe to a list or message type, is only a few tasks.

• Avoid very large pipelines (e.g. 30 tasks). Smaller, focused pipelines are easier to troubleshoot because you are only looking at one place.

Troubleshooting: nothing is sending

If submissions are coming in but no data reaches the ESP and the pipeline logs are completely empty, the pipeline was never triggered. Check the connection before investigating the pipeline itself:

• Make sure you've Published the pipeline.

• The pipeline must be connected to the campaign. A pipeline exists independently and only runs when it is explicitly linked.

• On the form tab, check the override campaign integrations setting. If it is set to skip integrations, the pipeline will not run even when it is connected at the campaign level.