Iâd delete that from the public channel, but yes â I can access your account on my end using our admin system (not your password). If it were blocked, Iâd see the same blocked message. Your account is fully active and working fine.
I checked your account, and the email mohamed.almagdy@sales-elephant.com is fully accessible â there are no active blocks or restrictions on our side.
If youâre still running into issues, it might be tied to another login email or a local browser problem. Try clearing your cache and cookies, then log in again using a different browser. You can also send us a short video showing how youâre signing in with this domain using the password method (just be sure not to show the password). You can share it privately if you prefer.
Everything should be working correctly on our end.
Okay, I see. No worries. Unfortunately, itâs not possible to use lookups on those properties since theyâre fixed in our database and mapped internally. This has come up before as feedback, though, so itâs definitely on our radar.
Hey, I get that this table isnât working right now. What I meant earlier is that you mentioned it worked before â could you share which previous table that was?
The âProperty Sizeâ and âRevenueâ columns are fixed setups, so they donât usually accept dynamic values from a lookup like this. Knowing where it worked before will help us check whatâs changed.
Hey, looks like this is just stale data. You can fix it by rerunning the affected rows â thatâll refresh the lookup and pull the values through again.
A quick way to do it: click the plus icon at the top of the column to manually refresh all inputs. Whenever a merge or lookup column isnât updating, itâs almost always because the data hasnât refreshed yet.
We detected other emails that were being linked to this account. Weâve been experiencing increasing spam usage of our free credits on the trial, so we recently implemented some robust security measures against this as we grow!
Unfortunately, we won't be able to unlock this email for you but if you have one that you've used previously that is locked, let us know and we can unlock it for you.
I get it. The catch is each enrichment also creates a verification column. So if you set up 11 enrichments, they count as 22 columns in total, which puts you over the limit even if it looks like youâre under.
Youâre seeing âwaiting for its inputsâ because the formula column depends on MDB check and DNC check, and those upstream cells didnât finish or didnât pass a run signal. Rerunning those inputs first will let the formula evaluate correctly.
Whatâs happening in your setup is three interdependent columns with layered conditions are firing out of order. The normalized domain feeds company domain, which both MDB check and DNC check depend on, and your formula also depends on normalized domain. If normalized domain doesnât complete, everything downstream can look stale and the formula stays unchecked.
Quick fix:
1.
Rerun normalized domain on all rows.
2.
Then rerun MDB check and DNC check where needed.
3.
After those complete, the formula column should update and the enrichment will proceed.
This can feel like a bug, but itâs mostly dependency timing. Weâre working to make these chains more resilient. In the meantime, keeping the column order clean and rerunning normalized domain first will unblock it.
Thanks for the detailed video â super helpful. Hereâs whatâs going on and how to get this working cleanly:
1. Why your current flow breaks
1. The âFind Peopleâ search doesnât respect row-level run conditions. Each new company can retrigger the whole search set, so your conditionals and sequential checks wonât line up.
2. Circular references in Clay arenât just possible; itâs better to work in a linear workflow (not A â B â A but A â B â C).
3. Itâs not possible to delay actions in a way that would catch everything from the Find People search. Because of that, using lookups to coordinate between tables becomes brittle, and the chain stalls or misfires.
2. What to use instead
1. Switch to the âFind Contact at Companyâ search. It runs at the row level, supports run conditions, and lets you control execution the way you want.
2. You can also use the custom âFind Peopleâ waterfall, which hits multiple providers while still keeping row-level control.
3. Reshape the workflow
1. Avoid circular flows (Table A â Table B â back to Table A).
2. Make it linear: Table A â Table B â Table C. That keeps dependencies clear and lets your run conditions work as intended.