I setup this flow. However, either the delay and/or the postgresSQL find row is not working as expected. It’s been shooting to the end and adding a tag to the MailChimp subscriber, then sending an unwanted email.
This post has been closed for comments. Please create a new post if you need help or have a question about this topic.
+7- Zapier Solution Partner
- 735 replies
Hey
Can you share the screenshot of action 3?
+14- Zapier Orchestrator & Solution Partner
- 34081 replies
Hi
For us to have more info, post screenshots with how your Zap steps are configured in EDIT mode.
Hi
Basically:
- Finds when a new member as joined the site
- The delay is set for 2 hours
- Afterward it checks if they have paid to subscribe. If they do pay, it updates their is_subscribed to true. If they did not pay, is_subscribed remains false. The 2 hours takes into account someone idling on a checkout page. I did not want to use Stripe’s webhook feature to watch for checkout expired because someone can also just signup for a free account.
- Filters to only allow users with is_subscribed = false to continue. At this point, if they are subscribed they should not go to step 5. In the screenshots, this user is not subscribed so it continues. If they are not subscribed it does show that this step 4 stops them...but that’s not the case.
- Updates their tag on MailChimp which then sends them into an email journey.
is_subscribed is always on the row in the table. It’s set to false by default.
This post has been edited by a moderator to remove personal information. Please remember that this is a public forum and to remove any sensitive information prior to posting.
+14- Zapier Orchestrator & Solution Partner
- 34081 replies
Screenshots do not show how the Delay step is configured in EDIT mode.
Check your Zap Runs history details to see the DATA IN/OUT for each step to help you trace the data flow, see timestamps for steps, and troubleshoot: https://zapier.com/app/history/
+11- Community Manager
- 9751 replies
Hi there,
Looks like there’s an issue with that Find Row action. At the moment, it’s searching the users table to find a record where the is_subscribed column contains a value that matches what is in the Is_subscribed field for the row that triggered the Zap. So if a row with an is_subscribed value of false triggers the Zap, after the delay runs it will then search the users table to find any row that also has an is_subscribed value of false not the same row that triggered the Zap. Instead, you’ll want to have it look for the exact same row that triggers the Zap.
To do that, the Find Row action will need to be set to search for an unique value that’s specific to that row. For example, you could set it to search for the email address as that would be unique to that user. That should ensure that it finds the correct row, then the filter will be checking the current is_subscribed value for the same row that triggered the Zap.
Can you give that a try and let me know if that fixes things?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.