Sending Your Data: a Pipelines Overview

Your campaign displays to the right people. Now it's time to decide what happens after someone hits submit. That's the job of Pipelines.

What is a Pipeline?

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

Flow: Form submission → Pipeline (Digioh) → ESP/CRM.

For example, a simple Pipeline might: add the submitter to a Klaviyo list, and fire off a custom event. Each of those is a task, and they run in the order you arrange them.

Pipelines run automatically the moment a campaign gets a submission. You don't have to trigger them manually once they're set up and published.

How tasks work

A Pipeline is built from tasks, and most Pipelines lean on three types:

• Map Data: a row-by-row field mapper. It takes values from the submission (or a hardcoded value) and writes them to the field names your ESP expects, for example, mapping form.email to email. This is where most of the configuration work happens.
• ESP API task (Klaviyo API, Iterable API, etc.): makes the actual call to your ESP: subscribe to a list, update a profile, track an event. This task is intentionally lightweight, since Map Data already built the payload.
• Render Template (advanced): builds a fully custom JSON payload using a templating language like Liquid. Reserve this for ESP requirements that Map Data can't handle on its own, like conditional fields or nested objects.

Any task can also carry a condition, so it only runs when specific criteria are met, for example only running an SMS step if form.phone isn't empty, or routing to a different list based on a quiz answer.

For a step-by-step on adding a task to an existing Pipeline, see How to add a new task to a Pipeline.

Mapping Data: Fields and Named Custom Fields

Every submission passes a structured payload with a few top-level objects you'll reference by dot notation, like form.email, analytics.country_name, prq.results_url, and so on:

• form: the visitor's submitted data. What you'll map most often.
• analytics: session and visitor data captured automatically (device, browser, UTMs, geo, page URL).
• attributes: submission metadata (submission ID, campaign ID, date created), useful for logging and dedupe.
• prq: quiz-specific data (answers, results, a shareable results URL), present only on quiz submissions.
• Named custom fields: on quiz submissions, form.named_custom_fields lets you reference an answer by its actual question name instead of a field number. This protects against a mapping breaking if field order ever changes.

For the full field reference, see Available Fields in Digioh Pipelines.

Viewing Pipeline Logs

When a sync fails, logs are the first place to look. Every Pipeline execution is logged under Pipeline → Activity → Logs, and each log shows the full request sent to the ESP and the full response, which is where the actual error usually surfaces.

From a log's detail view, you can also click Test Pipeline to re-run that exact submission (even editing the payload first, like changing the email) without waiting for a new live submission.

If the logs are completely empty, the Pipeline was never triggered. Check that it's published, connected to the campaign, and that the campaign's "override campaign integrations" setting isn't skipping it. See How to view pipeline logs for the full walkthrough.

Pick the Guide that Matches your ESP

The Map Data setup above is the same everywhere, but the exact fields, connections, and quirks differ by destination. Pick the guide for your platform:

• Connecting a Klaviyo pipeline
• Connecting an Iterable pipeline
• Connecting other ESPs and CRMs

Need help deciding which one applies to you, or troubleshooting a specific sync? Reach out to support@digioh.com.