# Trigger a workflow from a tracked event

Enable `Workflow trigger` for an event name to start a workflow whenever that event is recorded. Tracking also provides identification and completion triggers, plus actions for reading data and running supported operations inside a workflow.

Tracking continues collecting, resolving identities, and reporting without workflow setup. The conversion trigger is opt-in for each catalog name; none starts enabled.

**Before you start:** send at least one event with the intended name so it appears in the [event catalog](/acquire/tracking/events). For the Acme receipt example, replace `payment_completed` with your event name, ensure the event belongs to a person with an email, and prepare Mail to send the message.

## Send a receipt for every payment

Use the existing payment event as the workflow’s input:

1. **Your site sends the event.** Somewhere in your checkout you already call `lt('track', 'payment_completed', …)`, or your backend sends the same name over the Events API. Nothing about this changes.
2. **Tick the box.** Open the `Events` page, find `payment_completed` in the catalog and tick **Workflow trigger** on its row. That is the whole configuration.
3. **Build the workflow.** In Lepsto Workflows, start a new workflow with the `Conversion recorded` trigger and filter it to the event name `payment_completed`, so it runs on payments and not on every conversion you ever mark. Add a step: send an email through [Mail](/ship/mail), addressed to the email in the trigger.
4. **Wait about a minute, then test.** Ticking takes up to a minute to reach every part of the system. Send yourself a `payment_completed` and watch the run.

**Verify it works:** confirm that Workflows shows the run and the receipt reaches your test address. If no run appears, allow the checkbox change to propagate before sending another event; see [Timing](#what-to-expect-from-timing).

The configured workflow now handles future recorded payment events that match its filter.

For onboarding, use `Visitor identified` after your site explicitly identifies a visitor with their email. Identification is always published and needs no conversion checkbox. The trigger does not contain the address itself; read the profile while observing the recipient limitations below.

## The conversion trigger carries your customers' personal data

Enabling **Workflow trigger** publishes each recorded event with that name. Its payload includes the known person’s email and phone, profile id, ad click id, and conversion value.

A messaging step can use the included recipient details to send its message. Review where that information will go before enabling the trigger.

Account for both effects:

- **Email and phone are included regardless of the visitor's consent choices for tracking.** Consent governs what Tracking collects and how it reports it; it does not decide what a workflow you built needs in order to run. If you use this trigger, you are choosing to move that data into a workflow. See [what tracking does with a consent answer](/privacy/tracking-consent).
- **The payload travels wherever your workflow sends it.** Every step you add sees it — including steps that hand data to third parties, and everyone in your organization who can read workflow runs. Check each one against the basis you rely on for that data.

The conversion trigger publishes only for enabled names. Clearing the checkbox stops publication after its propagation delay; with no names enabled, this trigger emits nothing.

**Free-form event properties are excluded from the trigger.** Plan names, internal ids, and other custom fields stay on the event. If a later step needs them, it must read the event using the id in the trigger.

## Events you can trigger on

Two triggers describe visitor activity. Four others report operation completion; a workflow can start the Google Ads sync, conversion upload, and profile erasure, while host verification is started outside a workflow.

| Trigger | Fires when | Narrow it by |
|---|---|---|
| `Conversion recorded` | An event whose name you ticked is recorded | The event name |
| `Visitor identified` | A visitor becomes a known person | Email or phone |
| `Google Ads cost sync finished` | A spend sync ends | Its outcome |
| `Offline conversion upload finished` | A conversion-feedback pass ends | Its outcome |
| `Tracking host verification finished` | A verification attempt ends | Its outcome |
| `Profile erasure finished` | A profile erasure ends | Its outcome |

### Conversion recorded

The payload identifies the conversion name and time, visitor, known person and contact details, value, and visit attribution: source, medium, campaign, ad click id, and country.

**Convert minor units before displaying money.** `1999` with EUR means EUR 19.99: divide by the currency’s divisor (100 for EUR), not by its exponent. Other currencies differ; see [Revenue units](/acquire/tracking/revenue).

### Visitor identified

The payload gives the person, whether email or phone resolved them, and the time. It fires on identification rather than each later page view. The identifier itself is omitted; read the profile if needed.

### The four completion triggers

Completion triggers report an action’s outcome, including failure. For actions available as steps, start the operation and wait for its matching completion instead of assuming a duration. Host verification can be observed the same way, but cannot be started as a step.

Inspect the outcome before treating completion as success:

| Trigger | Outcomes |
|---|---|
| Google Ads cost sync | `ok`; `skipped` — nothing to sync, because the account is not selected yet, needs re-authorizing, or was unavailable; or `failed`. |
| Offline conversion upload | `ok`; `partial` — Google accepted some rows and rejected the rest, which usually means a conversion action is mapped wrongly and is worth acting on; `skipped`; or `failed`. |
| Tracking host verification | `verified`; `not-serving` — one check finished and the host is not serving the script, while the binding is unchanged and the automatic retrying continues; `gave-up` — the retrying window ran out and the binding has failed for good; or `abandoned` — the binding was deleted while verification was still running. |
| Profile erasure | `erased`; `nothing-to-erase` — there was no such person here; or `failed`. |

For tracking hosts, alert on `gave-up`; `not-serving` is expected while DNS changes propagate. [Domain setup](/acquire/tracking/domains) explains when to retry verification.

The erasure completion intentionally omits the erased person’s identifier. It is emitted after deletion and can persist in workflow run history.

### Each run reports its own completion

Each invocation has its own completion identity. Google Ads sync and offline upload return `runId`; profile erasure returns `requestId`. Match that value between the step output and trigger payload to distinguish concurrent attempts or multiple runs in a day.

Two separate invocations in one day produce separate completions.

## Actions you can use as steps

Supported steps include reading domain and install-checklist data, listing event names, reading/exporting/erasing profiles, running Google Ads sync and offline uploads, and querying reports and health views. See the [MCP tool reference](/reference/mcp-tools) for the current inventory.

For values already known to Tracking, such as event names and Google conversion actions, the editor offers a list to choose from.

Google Ads sync, offline upload, and profile erasure are long-running steps. Their completion triggers let a workflow wait for the outcome.

**Host verification has a completion trigger but no workflow step.** Claiming, verifying, and releasing the host require setup outside the workflow, including DNS records. A workflow can wait for the result of a manually started verification; see [Excluded steps](#what-is-not-a-step-and-why).

### What is not a step, and why

The following actions remain available through MCP and HTTP but are excluded from workflow steps.

These are configuration actions, often involving decisions or setup outside Lepsto:

| Not a step | Why |
|---|---|
| Claim, verify or release a tracking host | You claim a host and then publish a DNS record yourself, and a workflow cannot do the second half. Verification still reports back, so a workflow can wait on a claim you made by hand. |
| Add or remove an install-checklist domain | The checklist is filled in once, while the script is being put on a site. |
| Add or remove a cross-domain link domain | The linking group changes once, when a second domain joins it. |
| Archive or unarchive an event name | Catalog housekeeping, done once on a name you are finished with. |
| Tick or untick `Workflow trigger` on an event name | This checkbox arms a trigger. A workflow able to flip it would be editing the conditions under which it runs. |
| Change the conversion-feedback rules | It rewrites what your Google Ads account is told about every conversion from then on, and it is set by whoever owns the ad spend. Sending one pass of conversions stays a step. |

The offline-conversion upload history is also excluded because its rows identify individual clicks.

Reading a link domain group is a supported step; adding or removing its domains is not. See [Register domains](/acquire/tracking/domains).

## Retrying a step is safe

A step may be retried after a timeout, connection loss, or deployment interrupts its result. For mutating steps, retries within 24 hours return the first attempt’s result rather than repeat the operation. An erasure or upload pass therefore runs once in that window. Concurrent copies of the same step are refused rather than duplicated.

A retried backend batch likewise does not publish conversions a second time.

## What a workflow cannot do yet

**A profile does not identify a preferred contact address.** Tracking retains all known emails and phones but stores no primary, verified, or contact-consent flag to select one.

Identifiers are ordered newest first for consistent reads, not to rank the best recipient. A webinar work address could be newer than someone’s everyday address; blindly taking the first value can send to the wrong place without an error.

Use a source that knows the appropriate recipient, such as your customer system or the contact fields associated with `Conversion recorded`. Reading a profile returns all identifiers, not a recommendation about which to contact.

**The editor cannot bind a profile’s nested ad click id to a step input.** Journey events and identity signals contain nested lists, and two list hops exceed the editor’s binding support. A conversion-upload flow cannot use that profile path; the click id carried directly by `Conversion recorded` remains usable.

## What to expect from timing

Allow about **one minute** for `Workflow trigger` changes to reach every part of the system. Some events sent immediately after enabling may not trigger runs; some sent just after disabling may still do so.

Test after the delay: enable the name, wait a minute, and send a new event.

The trigger-setting delay does not delay event recording, counts, or `Live`.

## Next steps

- [Record your own events](/acquire/tracking/events): the catalog the checkbox lives on, and how a name gets there.
- [Send revenue from your backend](/acquire/tracking/revenue): the minor-unit amounts the conversion trigger carries.
- [Close the loop on Google Ads](/acquire/tracking/google-ads): the sync and the upload the completion triggers report on.
- [Fix tracking that is not working](/acquire/tracking/troubleshooting): what to check when a workflow does not run.