Conditional logic issue with Typeform Properties

  • 22 April 2024
  • 8 replies


Hi there, 

I’m trying to build out an email that sends a list of resources to a user based upon options they have selected in a Typeform survey. The custom properties are being passed to Klaviyo and can be viewed on an individual’s profile, but I cannot get anything to appear.


The only thing I can gather is that it is because the values are being passed as an array which is causing the property to be ignored in the conditional logic input. Is there any workaround here? I feel like this should be straightforward, but I must be missing something.


The below screenshots show the property and values we have captured and the second screenshot shows the logic which is not working when I preview as this profile. I’ve tried double quotes, reversing it to use “Low FODMAP Recipes” in person|lookup…, I’ve even tried using numbers like you would an array, but nothing seems to work. Thanks in advance for any answers you might have!




Best answer by Omar 22 April 2024, 18:46

View original

8 replies

Userlevel 6
Badge +24

Hi @cs_cooke,

Welcome to the Klaviyo community!

I believe the issue here is the == statement - this looks for an absolute match of this value. 

The correct query in this case would be

‘Low FODMAP Recipes’ in person|lookup:'Almost done... (ETC)'

More information around the different lookups can be found in here.

As an alternative, you could also approach this by using a conditional split in a flow. You’d have to build out different templates, but it could be a good way to increase the length of your flow as you could send each item in an individual email rather than send them all at once. The conditional split could look something like this:

Then after YES you could merge it back in with the remainder of the flow. It is a little bit more work but it would allow you to measure the impact of each of the emails with the information provided (open, click, placed order rate) and it would potentially be less overwhelming if I’ve given in multiple options (so that each of the emails has a clear CTA).

Hope that helps!



Appreciate the response @DavidV , I have tried that query as well and had no luck. I can see the upside to your suggestion for sending individual emails, but I’m not sure how people would respond to getting potentially 7 emails in a row after requesting resources. We’re already dealing with some domain reputation issues so I’d like to be as conservative with emails as possible for the time being.


I was hoping to only build one template that would show/hide relevant resources in a simple list. I guess I’ll just include all of the resources regardless of what they selected until I can sort this out. 


Thank you!


For some additional context I can get the block to work correctly by using: 

not person|lookup:'Almost done! Are there any categories below where we can provide further resources or support?'

despite the fact that this is in the custom properties as seen below. The strange thing is, personalization works just fine, but for whatever reason it is just not passing correctly to conditional logic and nothing I do makes it work as I would like.




Userlevel 6
Badge +24

No worries @cs_cooke - and definitely wouldn’t send them one after another, just build in some wait steps :) Especially if you’re delivering food ideas, I wouldn’t mind getting recipes every few days.

It is odd though that you’re not getting the right value out of the string. Let me ask the other champions and see if they have an idea of how they can pull this part - I’ve never created logic based on such a long string! 



@DavidV Thank you so much for your effort on this! And.. I’m with you, it is a very long string. I wondered if that may be causing issues. I even looked at creating a Profile Property Update within the flow to address that very thing, but that appears to be opening up another can of worms altogether. I was never terribly good at math, but suffice to say it would create a lot of variance.

Userlevel 7
Badge +44

 @cs_cooke, always an interesting case - this is also the reason why I prefer using Zapier for Typeform synchronisation. It allows you to be more in control of those custom properties and also sync is near real-time. 

This will take some trial and error to get right - I would start at trying to get it working and see if you can get it working with either an easy string - or - have the complete string with all variables in there first to see if that works. 

That way you can make sure you find what's causing the issue first. Is it your formatting or the data itself.

Create a new profile (or use an existing test profile) and add a profile property with only one answer to keep it simple. See if you can get that to work. 

Alternatively you could test it with the whole string to see if that gives you a winner

‘[“Low FODMAD...”, “Dessert & Snack”, "….”]’

Could you paste the whole string in this community so we can also test with it? 


You mentioned you can get it working by using a negative not person|lookup but I'm assuming it's just showing it for everyone so not a solution unless you want it to show only for people that don't have this profile prperty.

not person|lookup:'Almost done! Are there any categories below where we can provide further resources or support?'

I do have a feeling the == will not work properly as @DavidV mentioned above and you'd need to use a contains condition to better match.


Let us know what comes out of this.


Omar Lovert // Polaris Growth // Klaviyo Master Platinum Partner

We help with e-commerce growth through CRO, Klaviyo and CVO

Let's connect on linkedin

Userlevel 6
Badge +24

Thank you so much for jumping in @Omar!


Just wanted to give everyone an update on this. I do believe the issue is due to the length of the string. I’ve done several tests with similarly long strings as the key and experienced similar results. I’ve also done tests with a much shorter string as the key and the conditional logic worked as expected.

I don’t know exactly what the maximum character length for a string is in this case, but it seems pretty evident that this is the issue. Unfortunately for me there is no simple workaround, but as @Omar mentioned this could be circumvented by passing these properties through Zapier.