Skip to main content

Subject: Issue with Email Validation Condition Not Working Properly

 

Hello Community,

I'm experiencing an issue with email validation in ManyChat that I can't seem to resolve. Here’s the setup and problem:

Setup:
1. Email Collection Block:
   - User input type is set to email.
   - The email is saved to the default system field for email.
   - Retry is set to 0.

2. Condition Block (immediately after the Email Collection Block):
   - Condition 1: Email contains "@".
   - Condition 2: Email contains ".com".
   - Set to match “all” of the following conditions (meaning both conditions must be true).

3. Flow Paths:
   - True Path: If both conditions are met, it triggers a Zap to send the user a message.
   - False Path: If any condition is not met, it sends an error message stating that the email doesn't look valid.

Problem:
Despite the setup, the flow proceeds as if the email is valid even when it clearly isn't. For example, typing just the letter "L" still triggers the Zap to send the user a message, bypassing the validation checks entirely.

Actions Taken:
1. Verified that the conditions are set to "match all".
2. Simplified the conditions to check only for "@" to isolate the issue, but the problem persists.
3. Recreated the condition block to ensure no hidden configuration issues.

Request for Assistance:
- Has anyone experienced similar issues with ManyChat's condition handling for email validation?
- Are there any known bugs or additional steps I might be missing to ensure proper email validation?

Any insights or suggestions would be greatly appreciated. Thank you!

Here are some screenshots.

 

Add a test step, and print out the email right before and right after the step you're asking for the email.

My guess is that you're testing with your account that already has an email assigned to it.

Since you have it set to 0 retries, when the email capture fails, Manychat will not update the email field. And since you have a valid email in the Email field (from before), the condition will go to the True path.

If you want to do this logic, you need to either change the email capture to a normal text field (and capture whatever the person writes), or make sure the email field is empty before entering this (and empty after it, since Manychat will only update the email field if the email is valid).

Also, I see that you're using the 'Account Update' tag for your messages. You should not use those, stick to messages within the 24 hours and Messenger lists for messages outside the 24 hours. Use account updates exclusively for 'Account Update' actions as defined by Meta (you can search for the documentation, they're very specific about it).


Ok got it. Condition tests couldn't work because my account was already tested and had a valid email in it.

As for the “account update” tag: I have multiple messages that wouldn't be able to be sent to the user if the user comes back to the message and clicks a button for a question (message block with buttons) or answers a multiple choice question (user input) after 24 hours. User input blocks are not able to be used if the messenger list tag is“Promo & Update”.

 

I can change most of my “user input” blocks that hold “multiple choice” options (quick replies) to buttons, instead of multiple choice blocks with these quick replies, so that I can use message list tag “Promo & Updates”on them… except for ones that require an email to be inputed (which is a user input block).

 

So, In conclusion if someone interacts with a message block that contains buttons that says “enter email” or “ill pass” after a 24 hour window (maybe they were busy, got side tracked, or tended to something else on their phone while they were participating with the bot and didn't come back to it until after 24 hours) and they click “enter email”, the next step that would be sent is a user input block requesting a typed email value. This user input block would not be able to be sent to the user because messenger list tag “promo & update” are not allowed with user input blocks, which is why I was choosing account update.

 

What is your thoughts or recommendation to fix or work around this?


The button click that triggers a message is an interaction, and therefore resets the 24 hrs window.

So if they come back and click a button (that triggers a message), the next message will be within the 24 hours window.


ok makes sense, thank you!


Reply