PostHog workflows let you trigger emails, Slack alerts, and property updates directly from product events—so you can automate onboarding sequences and sales notifications without bolting on a separate email tool.

This guide walks you through the full setup: triggers, frequency controls, email dispatch, and the built-in testing feature that makes PostHog workflows worth a closer look.

What PostHog workflows actually do

A workflow in PostHog starts with a trigger (a product event or action) and ends with a dispatch (an email, webhook, Slack message, or property update). Between those two points, you can add delays, conditions, and branching logic.

Think of it as a lightweight automation layer sitting on top of your product analytics. You already track events in PostHog. Workflows let you act on those events without piping data to a third-party tool first.

Best for: product-led teams that want to trigger transactional emails, internal Slack alerts, or person-property updates based on in-app behavior—without maintaining a separate CRM automation.

Step 1: Set up your trigger

Every workflow starts with a trigger. You have two options:

• Events — fire the workflow when a specific raw event occurs (e.g., identify_persisted).
• Actions — fire the workflow when a grouped action matches. Actions bundle multiple events under one label, so you can target broader user behaviors like “email capture” instead of a single event name.

We recommend using actions over raw events. Actions group related events together, so you can update the underlying event list without rebuilding your workflow.

You can also layer on filters—feature flag status, person properties, group membership—using the same filter logic available everywhere else in PostHog.

Step 2: Configure frequency (this matters more than you think)

Below the trigger, you’ll find the frequency setting. Two choices:

• Every time — the workflow fires on every matching event, no limits.
• One time — the workflow fires once per person within a defined window (30 minutes, 1 day, 30 days, etc.).

The “one time” option is where most teams trip up. Selecting “one time” opens a secondary field: how often that “one time” resets. Set it to 30 days, and the workflow fires once per person per month—even if they trigger the event 30 times in that window.

Use “one time” with a 30-day window for welcome emails and onboarding sequences. Use “every time” only for transactional alerts where duplicate sends are acceptable (e.g., internal Slack notifications).

Step 3: Define a conversion goal

Conversion goals tell PostHog what you want the user to do after entering the workflow. When the goal event fires, PostHog exits the user from the workflow automatically—so you can stop sending nudges the moment someone completes the target action.

A concrete example: you run a fintech app similar to Monarch, a personal finance platform. Users need to connect a bank account to get value from the product. Set “bank account connected” as the conversion goal. The workflow sends reminders until the connection happens, then stops.

You can also trigger a follow-up action when the goal is met—useful for internal alerts (“User X just connected”) or updating a person property for cohort tracking.

Step 4: Build the email dispatch

Click “Email” in the dispatch menu and you’ll need three things:

1. Sender — select from configured email senders, or add a new one.
2. Recipient — PostHog pulls from person.properties.email. Make sure your identify calls store email in this field, or the send will fail silently.
3. Subject line — required before the workflow will activate.

The email builder: an honest take

The drag-and-drop editor is rough. After using Kit, ActiveCampaign, HubSpot, and most major email builders, PostHog’s visual editor is the weakest we’ve worked with. The canvas is small, the pop-out panels are clunky, and building a polished layout takes more effort than it should.

The workaround that actually works: skip the visual builder entirely and use the HTML editor. Paste in a pre-built HTML template (use AI to generate one from your brand guidelines) and you get full control over layout, styling, and responsiveness. This is what we use for every client implementation.

Step 5: Add conditions, output variables, and error handling

Each dispatch step includes three optional layers:

• Output variables — store values from this step so you can reference them in later steps. Useful for multi-step workflows where step 2 depends on step 1’s result.
• Conditions — a final check before the action fires. If the condition isn’t met, the user skips this step. Use this as a safety net for edge cases (e.g., “only send if person property plan equals free“).
• Error handling — define what happens when a step fails. Retry, skip, or halt the workflow.

Bonus: Update person properties from workflows

This is one of the most underrated features. Workflows can set or update person properties and group properties as a step—so you can tag users as “completed_onboarding_workflow” or “received_activation_email” without writing any code.

Why this matters: once you set a person property, you can use it everywhere in PostHog. Build cohorts of users who completed a specific workflow. Compare LTV (lifetime value) between users who went through an automation and users who didn’t. Layer it into future feature flag targeting or experiment segmentation.

If your team uses PostHog person properties as a core part of your data model, this feature alone justifies running workflows inside PostHog rather than externally.

The testing feature (the best part of PostHog workflows)

PostHog’s workflow testing deserves its own section. It’s the standout feature—clearly built by engineers who understand the anxiety of shipping automations to production.

Here’s how it works:

1. Navigate to the Test tab in your workflow.
2. PostHog loads a recent event that matches your trigger. You can cycle through other matching events with “Load new event.”
3. Hit Run test. PostHog runs the workflow as a hypothetical—it simulates each step and shows what would happen, without actually sending an email, pinging Slack, or firing a webhook.
4. Step through each node. Green checkmarks confirm the step would execute; conditions show whether they’d pass or fail.
5. When you’re ready, toggle on real HTTP requests to send a live test to a single user.

This means you can validate an entire workflow—trigger logic, conditions, email content, Slack payload—before a single real message goes out. No more testing automations by triggering them on yourself and hoping for the best.

When to use PostHog workflows vs. your CRM

Here’s the honest assessment: if your team already runs a CRM (HubSpot, ActiveCampaign, Salesforce) with mature automation, PostHog workflows aren’t a replacement.

For most companies, the stronger pattern is:

1. Use PostHog as your CDP (customer data platform) to track events and build user profiles.
2. Pipe events to your CRM via data pipelines or webhooks.
3. Let the CRM handle email sequences, lead scoring, and sales routing.

PostHog workflows make the most sense when:

• You don’t have a CRM yet and need basic product-triggered emails.
• You want internal alerts (Slack notifications when a user hits a milestone) without CRM overhead.
• You need to update person properties as part of an automation—something CRMs can’t write back to PostHog natively.
• You want the testing and simulation layer before any message ships.

What’s still missing

One gap stands out: no direct survey integration. PostHog has a built-in survey tool, but surveys can’t trigger or feed into workflows yet. If they connected surveys to the workflow trigger system, you could capture an email via a form, immediately fire a follow-up sequence, and turn PostHog into a lightweight CS (customer success) and adoption tool using frameworks like SOAR.

Until that ships, you’ll need to handle survey-to-workflow connections manually through custom events.

Quick-start checklist

• ☐ Confirm your identify calls store email in person.properties.email
• ☐ Group related events into actions under Data Management
• ☐ Create a workflow with the action as your trigger
• ☐ Set frequency to “one time per 30 days” for onboarding emails
• ☐ Build your email in the HTML editor (skip drag-and-drop)
• ☐ Add a conversion goal to auto-exit users who complete the target action
• ☐ Run a hypothetical test before activating
• ☐ Add a “completed workflow” person property step for cohort tracking

Need help setting up PostHog workflows for your team? Book a call with our team—we’ll walk through your use case and build the right automation setup, whether that’s workflows, CRM pipelines, or both.

PostHog workflows let you trigger emails, Slack alerts, and property updates directly from product events—so you can automate onboarding sequences and sales notifications without bolting on a separate email tool.

This guide walks you through the full setup: triggers, frequency controls, email dispatch, and the built-in testing feature that makes PostHog workflows worth a closer look.

What PostHog workflows actually do

A workflow in PostHog starts with a trigger (a product event or action) and ends with a dispatch (an email, webhook, Slack message, or property update). Between those two points, you can add delays, conditions, and branching logic.

Think of it as a lightweight automation layer sitting on top of your product analytics. You already track events in PostHog. Workflows let you act on those events without piping data to a third-party tool first.

Best for: product-led teams that want to trigger transactional emails, internal Slack alerts, or person-property updates based on in-app behavior—without maintaining a separate CRM automation.

Step 1: Set up your trigger

Every workflow starts with a trigger. You have two options:

• Events — fire the workflow when a specific raw event occurs (e.g., identify_persisted).
• Actions — fire the workflow when a grouped action matches. Actions bundle multiple events under one label, so you can target broader user behaviors like “email capture” instead of a single event name.

We recommend using actions over raw events. Actions group related events together, so you can update the underlying event list without rebuilding your workflow.

You can also layer on filters—feature flag status, person properties, group membership—using the same filter logic available everywhere else in PostHog.

Step 2: Configure frequency (this matters more than you think)

Below the trigger, you’ll find the frequency setting. Two choices:

• Every time — the workflow fires on every matching event, no limits.
• One time — the workflow fires once per person within a defined window (30 minutes, 1 day, 30 days, etc.).

The “one time” option is where most teams trip up. Selecting “one time” opens a secondary field: how often that “one time” resets. Set it to 30 days, and the workflow fires once per person per month—even if they trigger the event 30 times in that window.

Use “one time” with a 30-day window for welcome emails and onboarding sequences. Use “every time” only for transactional alerts where duplicate sends are acceptable (e.g., internal Slack notifications).

Step 3: Define a conversion goal

Conversion goals tell PostHog what you want the user to do after entering the workflow. When the goal event fires, PostHog exits the user from the workflow automatically—so you can stop sending nudges the moment someone completes the target action.

A concrete example: you run a fintech app similar to Monarch, a personal finance platform. Users need to connect a bank account to get value from the product. Set “bank account connected” as the conversion goal. The workflow sends reminders until the connection happens, then stops.

You can also trigger a follow-up action when the goal is met—useful for internal alerts (“User X just connected”) or updating a person property for cohort tracking.

Step 4: Build the email dispatch

Click “Email” in the dispatch menu and you’ll need three things:

1. Sender — select from configured email senders, or add a new one.
2. Recipient — PostHog pulls from person.properties.email. Make sure your identify calls store email in this field, or the send will fail silently.
3. Subject line — required before the workflow will activate.

The email builder: an honest take

The drag-and-drop editor is rough. After using Kit, ActiveCampaign, HubSpot, and most major email builders, PostHog’s visual editor is the weakest we’ve worked with. The canvas is small, the pop-out panels are clunky, and building a polished layout takes more effort than it should.

The workaround that actually works: skip the visual builder entirely and use the HTML editor. Paste in a pre-built HTML template (use AI to generate one from your brand guidelines) and you get full control over layout, styling, and responsiveness. This is what we use for every client implementation.

Step 5: Add conditions, output variables, and error handling

Each dispatch step includes three optional layers:

• Output variables — store values from this step so you can reference them in later steps. Useful for multi-step workflows where step 2 depends on step 1’s result.
• Conditions — a final check before the action fires. If the condition isn’t met, the user skips this step. Use this as a safety net for edge cases (e.g., “only send if person property plan equals free“).
• Error handling — define what happens when a step fails. Retry, skip, or halt the workflow.

Bonus: Update person properties from workflows

This is one of the most underrated features. Workflows can set or update person properties and group properties as a step—so you can tag users as “completed_onboarding_workflow” or “received_activation_email” without writing any code.

Why this matters: once you set a person property, you can use it everywhere in PostHog. Build cohorts of users who completed a specific workflow. Compare LTV (lifetime value) between users who went through an automation and users who didn’t. Layer it into future feature flag targeting or experiment segmentation.

If your team uses PostHog person properties as a core part of your data model, this feature alone justifies running workflows inside PostHog rather than externally.

The testing feature (the best part of PostHog workflows)

PostHog’s workflow testing deserves its own section. It’s the standout feature—clearly built by engineers who understand the anxiety of shipping automations to production.

Here’s how it works:

1. Navigate to the Test tab in your workflow.
2. PostHog loads a recent event that matches your trigger. You can cycle through other matching events with “Load new event.”
3. Hit Run test. PostHog runs the workflow as a hypothetical—it simulates each step and shows what would happen, without actually sending an email, pinging Slack, or firing a webhook.
4. Step through each node. Green checkmarks confirm the step would execute; conditions show whether they’d pass or fail.
5. When you’re ready, toggle on real HTTP requests to send a live test to a single user.

This means you can validate an entire workflow—trigger logic, conditions, email content, Slack payload—before a single real message goes out. No more testing automations by triggering them on yourself and hoping for the best.

When to use PostHog workflows vs. your CRM

Here’s the honest assessment: if your team already runs a CRM (HubSpot, ActiveCampaign, Salesforce) with mature automation, PostHog workflows aren’t a replacement.

For most companies, the stronger pattern is:

1. Use PostHog as your CDP (customer data platform) to track events and build user profiles.
2. Pipe events to your CRM via data pipelines or webhooks.
3. Let the CRM handle email sequences, lead scoring, and sales routing.

PostHog workflows make the most sense when:

• You don’t have a CRM yet and need basic product-triggered emails.
• You want internal alerts (Slack notifications when a user hits a milestone) without CRM overhead.
• You need to update person properties as part of an automation—something CRMs can’t write back to PostHog natively.
• You want the testing and simulation layer before any message ships.

What’s still missing

One gap stands out: no direct survey integration. PostHog has a built-in survey tool, but surveys can’t trigger or feed into workflows yet. If they connected surveys to the workflow trigger system, you could capture an email via a form, immediately fire a follow-up sequence, and turn PostHog into a lightweight CS (customer success) and adoption tool using frameworks like SOAR.

Until that ships, you’ll need to handle survey-to-workflow connections manually through custom events.

Quick-start checklist

• ☐ Confirm your identify calls store email in person.properties.email
• ☐ Group related events into actions under Data Management
• ☐ Create a workflow with the action as your trigger
• ☐ Set frequency to “one time per 30 days” for onboarding emails
• ☐ Build your email in the HTML editor (skip drag-and-drop)
• ☐ Add a conversion goal to auto-exit users who complete the target action
• ☐ Run a hypothetical test before activating
• ☐ Add a “completed workflow” person property step for cohort tracking

Need help setting up PostHog workflows for your team? Book a call with our team—we’ll walk through your use case and build the right automation setup, whether that’s workflows, CRM pipelines, or both.