Join the Community

Troubleshooting Conditional Logic in Multi-Layer Enrichment Flow

·

·

Hey Clay team, I’ve hit a pretty advanced roadblock and wanted to see if there’s any clean workaround for it. I’ve set up a conditional multi-layer enrichment flow where I’m combining custom logic between Lookup Company Domain, Apollo, Clearbit, and other sources. The logic branches depending on which tool returns data and whether certain fields are blank for example, if Apollo fails to return an email but provides a name, it should trigger Clearbit next, and so on. The issue I’m facing is that Clay’s conditional rules seem to treat any non-error result as “success,” even if the fields returned are incomplete or basically unusable. So if a source returns just a company logo or a single social URL, the fallback steps get skipped. I’ve tried using “contains,” “does not contain,” and custom if/else logic on specific fields like email or job title, but it’s not reliable at scale especially with bulk runs. In some cases, enrichments freeze on “awaiting input” even though the data looks ready. In others, the fallback never triggers despite the result being clearly incomplete. What I need is a way to trigger fallback enrichments only if certain high-value fields (like verified email, title, or LinkedIn URL) are still missing not just based on whether the step technically ran. Either that, or a way to overwrite partial enrichments with better fallback results later in the sequence. Curious if there’s any way to handle this more intelligently. It’s been really hard to maintain accuracy across large dynamic tables because of how these edge cases behave.

6 comments

Clay
APP
·
·
For your multi-layer enrichment flow, you can create more precise conditional runs by checking specific field values rather than just step completion. Use conditional formulas to check if high-value fields are empty or contain meaningful data. For example, set up conditions like {{email}} is not empty AND {{email}} != "" or {{job_title}} contains "VP" to trigger fallbacks only when specific fields are missing or inadequate. In Run Settings, use the "Use AI" feature to generate formulas that check multiple field conditions simultaneously. You can combine conditions with AND/OR operators like {{email}} is empty OR {{linkedin_url}} is empty to ensure fallbacks run when key fields are missing. For handling partial results, create separate conditional runs for each enrichment step that specifically validate the quality of returned data, not just whether the step completed. Test your conditions with edge cases like empty fields and unexpected formats to prevent the "awaiting input" issues you're experiencing.
Sources: AI Formulas + Conditional Runs [CRM Enrichment] - Clay University AI Formulas + Conditional Runs [Clay 101] - Clay University Guide: Ways to save Clay credits | Documentation | Clay University Conditional runs | Documentation | Clay University Conditional runs | Documentation | Clay University Conditional Formulas Conditional statements | Documentation | Clay University
Suhaib S.
·
·
I had already tried setting up the conditional logic using those field-level checks (like {{email}} is empty OR {{linkedin_url}} is empty) and even used the AI formula generator for combining conditions. But the problem seems deeper than just the condition syntax. In practice, the fallbacks still don’t consistently trigger when expected. For example, even when {{email}} is clearly blank or returns something generic (like a catch-all or placeholder), Clay often marks the step as “complete,” so the fallback skips. I’ve also tested with nuanced conditions like {{email}} does not contain "@" or checking string lengths, but no luck. The biggest issue is that the enrichment steps don't behave reliably with partial or low-quality data especially when multiple enrichments are chained, and fields get overwritten or frozen in "awaiting input." Even separating into multiple conditional runs with strict logic hasn't helped much when working with 5-6 enrichment sources in a single flow. Would love to know if there's a more robust or scalable way to prioritize quality of data across branches, or possibly a way to re trigger fallback enrichment even after an earlier source “completes” with poor results.
Clay
APP
·
·
Clay's waterfall enrichment system stops further enrichments once a provider returns a valid data point to save credits. This behavior explains why your fallbacks aren't triggering even with incomplete results. For better data quality control, you can qualify leads before enriching by setting up conditional runs that filter based on specific criteria. Consider restructuring your flow to validate data quality after each enrichment step rather than relying on the waterfall's automatic stopping mechanism. One approach is to separate your enrichment into multiple sequential conditional runs, where each step validates the quality of returned data before proceeding. This allows you to re-trigger enrichments even after earlier sources complete with poor results. Are you currently using separate conditional runs for each enrichment source, or are you trying to handle all sources within a single waterfall enrichment?
Sources: Enrich Companies (Waterfalls) [Clay 101] - Clay University Enrich Companies (Waterfalls) [Clay 101] - Clay University Enrich People (Waterfalls) [Clay 101] - Clay University Guide: Ways to save Clay credits | Documentation | Clay University
Suhaib S.
·
·
Yeah, I’ve already broken the enrichment into separate conditional runs each one checking specific fields like email quality, LinkedIn URL presence, and even using length checks or pattern logic. The issue is that even when the returned data is poor (like placeholder emails or irrelevant job titles), Clay considers the step “complete,” so the next fallback doesn’t trigger. I understand the credit-saving logic behind stopping the waterfall early, but in high volume workflows where data quality matters more than credit efficiency, this behavior becomes a bottleneck. I’ve tried workarounds by validating fields post-enrichment, but it still doesn't fully resolve the gap where Clay thinks the job is done even if the result is unusable. If there’s a way to override this default behavior like treating certain values as invalid even if technically present that would solve a lot of edge cases I’m dealing with.
Clay
APP
·
·
For waterfall enrichments, you can configure catch-all email handling to treat certain results as invalid. In the waterfall settings, toggle "treat catch-alls as invalid" to prevent low-quality emails from stopping the process. For non-waterfall enrichments, use more sophisticated conditional formulas that check data quality patterns. Instead of just checking if fields exist, create conditions that validate meaningful content - like checking if emails contain specific domains you want to exclude or if job titles match certain patterns. You can also structure sequential conditional runs where each step validates the previous enrichment's quality before proceeding, essentially creating your own quality-controlled waterfall outside the standard waterfall system. However, there's currently no built-in way to override the waterfall's default "completion" behavior for other data types beyond catch-all emails.
Sources: Enrich People (Waterfalls) [Clay 101] - Clay University Enrich People (Waterfalls) [Clay 101] - Clay University Guide: Ways to save Clay credits | Documentation | Clay University Conditional Formulas
Hasnain R.
·
·
Great!
😊1

Troubleshooting Conditional Logic in Multi-Layer Enrichment Flow | Clay