You cloned a proven welcome flow into a second brand's Klaviyo account, switched it live, and a week later it has sent zero emails. The flow looks identical on the canvas, but the trigger points at a metric the new account has never recorded, the entry segment references a list that does not exist, and half the email blocks came across empty. Cloning copies the shape of a flow, not the account-specific wiring underneath it, and that gap is where revenue leaks.
Key takeaways
- Metric IDs are account-scoped, so a cloned metric-triggered flow points at nothing in the destination and never enters anyone.
- Segments built with advanced operators or multiple where clauses do not clone across accounts at all, per Klaviyo's own documentation.
- Coupons, dynamic and universal content, review blocks and price-drop logic are stripped out of cloned emails even though the surrounding email copies over.
- Cloned flows arrive switched off, which is the one piece of luck here: it forces a manual review before anything sends.
- API reports, dashboards and integrations that hard-code a metric ID break the moment they run against the new account, because keys and IDs are both per-account.
What actually transfers when you clone a Klaviyo flow across accounts?
The canvas structure, the email layout and the static copy transfer. Almost everything that binds those emails to real data does not. Klaviyo's guide to cloning flows between accounts is explicit that information gets left out because the two accounts "may have different channels, metrics, list names, etc.", and it lists metrics, lists, segments, date properties, filters and custom metrics as the fields you have to reset by hand.
Think of it as copying a form letter that had mail-merge fields. The letter arrives intact and the merge fields arrive blank. The clone gives you a head start on design and sequencing, and nothing else you can trust.
| Element | Transfers on clone? | What you must do in the destination |
|---|---|---|
| Flow canvas and timing | Yes | Nothing, verify delays use profile timezone |
| Static email copy and layout | Yes | Review for account-specific references |
| Trigger metric | No, ID does not resolve | Re-select the metric by name |
| Entry and exclusion segments/lists | Partially or not at all | Rebuild advanced segments manually |
| Coupons and dynamic content blocks | No | Recreate coupon codes and dynamic blocks |
| Flow status | Arrives in draft | Enable only after full QA |
Why does the trigger metric point at nothing in the new account?
Because a metric ID is generated per account, and the destination account has its own IDs for the same conceptual event. Klaviyo's Metrics API overview describes the ID as a per-account identifier returned by fetching "all metrics in an account", which means the string that identified "Placed Order" in the source brand is meaningless in the destination brand even when both accounts have a metric with that exact name.
When a metric-triggered flow clones over, the trigger field either comes across unresolved or silently maps to the wrong thing. The flow can read as configured while entering nobody, because no event with that ID ever fires. This is the failure that produces a live flow with zero sends and no error to click on.
The fix is to reopen the trigger and re-select the metric by name inside the destination account. If you automate that step, do it by name rather than by ID: the Get Metrics endpoint returns every metric's name, ID and the integration that captured it, so you resolve the correct destination ID by matching on name and integration instead of copying a value that only meant something in the other account. That name-first discipline is the same principle behind a durable multi-account naming schema: never let an account-scoped ID become the join key.
Which segment and filter conditions silently fail to clone?
The complex ones, which are usually the ones doing the real targeting work. Klaviyo states that segments using advanced operators, meaning event operators beyond "equals" and "includes any of", or segments with multiple where clauses, cannot be cloned across accounts at all, in the same cloning documentation. A one-condition list membership clones fine. A "placed order at least twice in the last 90 days and has not opted out of SMS" segment does not.
The danger is asymmetric. A trigger that fails to resolve stops the flow, which is loud. A segment condition that drops out can make the flow more permissive than intended, which is quiet and expensive. An exclusion segment that was supposed to keep recent purchasers out of a re-engagement flow, if it fails to clone, leaves you emailing people you meant to protect.
What content inside the cloned emails does not travel?
Anything generated from account state rather than typed into the editor. Klaviyo's documentation lists coupons, review blocks, price-drop logic and dynamic or universal content as elements that do not transfer, even though the email object that contains them copies over. So the email arrives with a hole where the coupon block was, or a personalized product block that renders empty against a catalog the new account has not synced.
Two categories deserve specific attention before launch:
- Coupons. Codes are account-specific objects. A cloned email that promised a unique code will render nothing until you recreate the coupon in the destination account and repoint the block.
- Links and UTM parameters. Klaviyo flags template links and UTM parameters as items to review per account. A cloned email can carry tracking that still tags traffic as the source brand, which corrupts attribution in the new store's reporting from day one.
Why do API reports and dashboards break the moment the clone goes live?
Because the same account-scoping that breaks the trigger also breaks anything downstream that referenced the old account by key or ID. A private key is bound to one account: Klaviyo's API overview notes that a call using "a key from the wrong account" returns an error, and that rate limits are enforced on a per-account basis with separate burst and steady windows. A dashboard that hard-codes a metric ID, or an integration reusing one key across brands, does not degrade gracefully. It errors or, worse, returns another account's numbers.
This is why cross-account rollups drift after a migration wave. If a reporting job was built around IDs copied from the source account, every cloned brand quietly reports against the wrong metric until someone reconciles the mapping. It is the mechanism behind why multi-brand rollup reports never line up without a name-keyed metric map maintained per account.
What is the pre-launch checklist before you switch a cloned flow live?
The one advantage of cloning is that flows arrive in draft, so nothing sends until you deliberately enable it. Use that window. Before switching a cloned flow live in a destination account, confirm each of these:
- The trigger metric is re-selected by name and shows recent event activity in the new account, not a zero count.
- Every entry, exclusion and split segment resolves; rebuild by hand any segment that used advanced operators or multiple where clauses.
- Coupon blocks point at codes that exist in this account, and every dynamic or universal content block renders against the live catalog.
- Link UTM parameters name the correct brand, not the source account.
- Time-delay steps respect profile timezone so batches do not land overnight, and conditional splits reference metrics that exist here.
- You send a preview and a seed test through the full flow, not just a single email preview, so entry logic is exercised end to end.
What are the trade-offs, and when should you not clone at all?
Cloning earns its keep for structure and design. If you run five brands off one template system, cloning the skeleton and rebuilding the wiring is faster than starting blank. What it does not save you is the account-specific work, and pretending otherwise is how a flow ships broken.
My rule: clone the flow that is mostly static and lightly triggered, and rebuild from scratch the flow that is dense with segments, coupons and dynamic product logic. For the second kind, the manual rework after a clone approaches the effort of building fresh, and building fresh removes the risk of a stale ID or a silently dropped exclusion that a clone introduces. The most dangerous clone is the one that looks perfect on the canvas, because it invites you to skip the review the account-scoping demands. Treat every cloned flow as broken until each binding is proven against the destination account's own data.