The problem is, I need my subscribers to finish up moving through the old flow, but all the new ones should go through the new flow.
As of now, my subscribers are moving through both flows because obviously I need the same contingent of people from my old flow to the new one (i’ve put some safeguards in the old one, but that’s just not tangible).
Creating custom fields is really a silly workaround. Similar (and better) features are widely available in the competition, why there’s such struggle to add some really useful features to Klaviyo?
Oh, that’s something great to know! Thanks for clarifying :)
Hi
Thanks for your reply. Of course, happy to clarify.
Some Klaviyo filters will evaluate users only at the point of entry into the flow i.e. a Trigger filter (not before each email send). A trigger filter is being used in the latter example using the metric-triggered flow (using $value) which is why it is effective for allowing existing users to continue through the flow.
Other flow filters, will evaluate before each email send i.e. a Flow filter and thus will not be effective at allowing users who don’t meet the criteria of the flow filter to continue moving through the flow. To better understand filtering in flows, I recommend checking out our article here.
I hope that provides further clarity.
Can you clarify, if I will setup the impossible trigger, will it only affect the new subscribers flushing into this flow and not the ones that are already in the flow?
Because I don’t think this works like that. Each flow email checks the triggers before sending the email, thus that would not allow the customers to receive what’s left of that old flow.
In other words, it’s not a great workaround. And plus, Klaviyo is basically based on triggers, so of course, we based our flows on that too. But maybe, when we’ll setup new accounts, we may start adding subscribers to list/groups, but I don’t see the benefits here, because lists are static and they outdate quickly.
Hi
Thanks for your reply and providing that additional information and example.
Yes, I understand exactly what you mean. With that said, on the point of avoiding new users entering a flow, this can be achieved in a few different ways depending on the type of flow trigger (list/segment, or metric) and the type of filters you’re using. If it’s a list-triggered flow, for example, you can add a conditional split at the beginning (similar to what you have in your example), to check if someone is added to a list before a certain day (say we use today’s date of 03/31/2022), if they were added to the list (in this case, the Newsletter) on that date or later, the user will travel down the “no” path and exit the flow. Anybody already in the flow will continue on their path through the flow undisrupted. This is because conditional splits only “check” the user when they reach that point in the flow, if a user is already passed that split, they won’t be subject to that filter. Here’s an example:
If the flow is metric-triggered, you can add a trigger filter (which checks if a user qualifies for the flow only when they initially enter the flow, as opposed to a flow filter which will check if the user qualifies for a flow before each email send in the flow), using the $value field, i.e. $value = 999999. Making it impossible for new users to enter the flow unless they have an item in their cart worth $999999 (which I’m guessing you won’t have unless you sell some really nice stuff :)) and anybody already in the flow will continue on their path through the flow undisrupted. Here’s an example:
To better understand filtering in flows, I recommend checking out our article here. But yes, I hear your request on directly adding people to to a list within a flow itself, that is certainly something we can take a closer look into in the future. I’ll submit a request, we appreciate your feedback. Hopefully the above was helpful for you (and others following along) as well.
I was testing with the same exact method as you described, Dov, but due to natural delays and other issues, this is not a viable solution.
Regarding the feature, I’d suggest looking into competition such as MailerLite (I do not recommend using them because they have the worst deliverability compared to any competition).
Here’s what they’re doing:
Their flows can be based on anything, especially groups or lists which you can move the subscribers from/to in their own automations.
As you see in this test flow that I’ve made, whenever subscriber joins the main group “test1”, we check (in this case it’s a random field, but the point is to move the subscriber, so any field will do) a random field that should force the subscriber to move to another group where’s a new flow waiting for him (the new flow is based on test2).
So basically, if this automation is an old one with like 8 flow emails active, we can put this condition at the start of the flow and move the subscriber to another flow which is based on “test2’ without forcing any new ones to go through the flow. All the other subscribers that started the flow before these conditions will continue to receive old flow emails. It’s super safe, super tested and works like a charm on ActiveCampaign as well (been working with several companies and products, hence the knowledge).
Do you get what I mean?
Of course… The best use case would just put a condition like this:
If customer email is set - move to abandoned_cart_flow_new
if customer email is not set - suppress subscriber.
This would put Klaviyo ahead of the competition because it’s simple, effective and doesn’t interrupt the old flow nor the new one.
Hi
Thanks for sharing this with us. I’m sorry to hear you’ve run into some frustration using flows, we’d love to make this as easy as possible for all of our users.
I’m assuming by “creating custom fields” you’re referring to using a create profile property block at the end of flow X and subsequently using that property in a segment to trigger segment-triggered flow Y? If you are creating custom fields in another manner, the above may serve as a more streamlined way to achieve your goal.
Also, an “update profile property” action has a number of other use cases you may find helpful to collect information about your users.
We’re always open to exploring new ideas within the product. I’m interested to hear more about how you’d like see this feature function within Klaviyo.
Looking forward to hearing from you.
Reply
Log in to the Community
Use your Klaviyo credentials
Log in with Klaviyo
Use your Klaviyo credentials
Log in with KlaviyoEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.