> For the complete documentation index, see [llms.txt](https://docs.roadmap.so/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roadmap.so/reviews/integrations/klaviyo-review-integration/setting-up-a-klaviyo-post-purchase-review-flow-dynamic-table-styled-email.md).
# Setting up a Klaviyo post-purchase review flow (Dynamic table-styled email)
Build a Klaviyo post-purchase review flow using the Roadmap: Eligible for Review Request trigger, with a Review Submitted conditional split and follow-up email.
Build a post-purchase review flow that reaches only customers with reviewable products.
#### What you'll build
* **Trigger:** `Roadmap: Eligible for Review Request`
* **Timing:** A `10-day` time delay
* **Action:** A review request email
* **Follow-up:** A `3-day` delay, a conditional split, and an email on the **No** branch
#### About the trigger: Roadmap: Eligible for Review Request
This flow uses `Roadmap: Eligible for Review Request`, not a Shopify order trigger. It fires when an order is fulfilled and contains products eligible for a review.
An order or item is excluded when:
* The customer already reviewed the product and the review limit prevents another review.
* You permanently excluded the product or variant using **Filter Products**.
The metric respects the **Review limit** in Roadmap review settings. **One review per product** excludes products the customer already reviewed. **One review per product per order** lets customers review a reordered product.
Use **Roadmap admin → Klaviyo integration → Metrics → Filter Products** to exclude products or variants. Exclude gift wrapping and sample swatches permanently.
{% hint style="info" %}
If every item is excluded, the metric does not fire.
{% endhint %}
#### Set up the flow
{% stepper %}
{% step %}
**Create the flow**
Open **Flows**, then select **Create Flow**. Select **Build your own**.
Name the flow. For example, use `Roadmap: Eligible Post Purchase Dynamic Table Review Flow`.
Click the **Trigger** card. Under **Select a trigger → Your metrics**, choose **Roadmap: Eligible for Review Request**.
In **Confirm your trigger selection**, confirm the metric and select **Confirm and save**. The trigger card becomes **When someone Roadmap: Eligible for Review Request**.
{% endstep %}
{% step %}
**Add timing before requesting a review**
Under **Timing**, drag **Time delay** below the trigger. Open **Time delay details**.
Set the delay to `10 Days`. Optionally restrict delivery to specific days and times. Select **Save**.
The metric fires at fulfillment. A `10–14-day` delay gives customers time to use the product.
{% endstep %}
{% step %}
**Add the review request email**
Under **Actions**, drag **Email** below the time delay. Configure your review request message. See How to create your email design (Dynamic Table).
{% endstep %}
{% step %}
**Add a follow-up for customers who haven't reviewed**
The `Roadmap: Review Submitted` metric records each submitted review.
Add another **Time delay** below the review request email. Set it to `3 Days`.
Under **Logic**, drag **Conditional split** below the delay. In **Conditional split details**, set:
`What someone has done (or not done) → Person has Roadmap: Review Submitted → at least once → since starting this flow`
Add an **Email** action to the **No** branch. These customers have not reviewed since entering the flow.
Let the **Yes** branch end. These customers already submitted a review.
{% hint style="info" %}
You can trigger a separate thank-you flow from `Roadmap: Review Submitted`.
{% endhint %}
{% endstep %}
{% step %}
**Optional: filters and splits**
Use **Trigger filters** to limit events. Use **Profile filters** to limit profiles.
For example, exclude B2B customers when they should not receive review requests.
{% hint style="info" %}
Use **Filter Products** in Roadmap for permanent product exclusions. The eligible-review metric already excludes ineligible and reviewed items.
{% endhint %}
{% endstep %}
{% step %}
**Use a dynamic table for multi-item orders**
Use a dynamic table when customers can purchase several products. It lists each item and offers a review link for each one.
{% endstep %}
{% endstepper %}
#### Troubleshooting
**The trigger does not appear in Klaviyo**
* Confirm the Roadmap Klaviyo integration is connected.
* Open **Your metrics** when selecting the trigger.
* Check that Roadmap metrics have synced to Klaviyo.
**Customers do not enter the flow**
* Confirm the order was fulfilled.
* Check that it contains at least one reviewable product.
* Check the review limit and product exclusions.
**The follow-up sends after a review**
* Set the split to `at least once` and `since starting this flow`.
* Place the follow-up email only on the **No** branch.
#### Frequently asked questions
Why use the eligible-review trigger?
It only adds customers with reviewable products. Ineligible orders never enter the flow.
Can I thank customers after they submit a review?
Yes. Trigger a separate flow with \`Roadmap: Review Submitted\`.
#### Related guides
* How to set up your review form landing page for your Klaviyo flow
* Setting up a Klaviyo post-purchase review flow (Less design restrictions)
* Introduction to Klaviyo review flow setup
* How to create your email design (Dynamic Table)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.roadmap.so/reviews/integrations/klaviyo-review-integration/setting-up-a-klaviyo-post-purchase-review-flow-dynamic-table-styled-email.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
