Clay's changelog says Functions replace the older Recipes and column templates: enrichment logic you can save and reuse. The entry is dated 21 September 2026 and marked beta. It is short, so I will stay close to what it says and add only what I would do about it.
What does Clay say Functions are?
Reusable enrichment logic, saved once and used again. The changelog, in the product roundup for the week of 14 September, states that Functions replace Recipes and column templates. It gives no more detail than that, so I am not going to describe internals I cannot see.
One related fact helps. Clay's Sculpt recap says Workflows can call existing Clay functions. So a function you save is not locked to the table you wrote it in.
Why does reuse matter?
Because the same few pieces of logic show up in almost every build: find a work email through a waterfall, check a company really matches the ICP, look for a hiring signal. If each table carries its own copy, a fix has to be made in every copy. A reusable function means one fix.
That is why I describe the waterfall and qualification logic as the main work in what a Clay automation agency does: it is logic worth building once and carefully.
How would I organise a function library?
This is a suggested structure, not something I have run at scale on Functions yet.
| Function type | Example | Rule |
|---|---|---|
| Contact finder | Work email through an ordered set of providers | One input (company, name), one output (verified email) |
| Qualifier | Read a site, return fit or not fit and a reason | Return a short label, not a paragraph |
| Signal | Hiring for a role, recent funding | Return a date and a source |
| Writer | First line from a signal | Smallest model that sounds right |
Four habits I would keep:
- Name by job, not by client. "Find work email" will be reused; "Acme email fix" will not.
- One job per function. If it does two things, the next person cannot reuse half.
- Say what goes in and out. Put inputs and outputs in the name or description. You will forget in a month.
- Test on three rows before it becomes the standard. The same credit habit as in how to stop burning Clay credits.
For the waterfall piece, the logic itself is covered in Clay waterfall enrichment explained.
What should I check first?
Open your workspace and see what happened to your existing Recipes and column templates. The changelog says Functions replace them but gives no migration detail. Pick one you rely on and confirm it still behaves the same on a sample before it feeds a live campaign.
What is the smallest useful first step?
Take the one piece of logic you have copied into the most tables, probably an email finder or an ICP check. Save it as a single function, run it on three rows, then swap it into one existing build in place of the copy. If the output matches, you have proved the idea on something small, and you can move the next piece. If it does not, you have lost an afternoon rather than a campaign.
Where this advice stops working
If you build one table a quarter, a function library is overhead. It pays off when you repeat the same logic across many builds. And the feature is in beta, so details may shift; check Clay's docs.
Functions are the reusable parts that workflows call, so the next read is the Workflows versus tables decision guide. If you are still choosing your stack, see Clay vs Apollo for outbound.
I'm Malik, a GTM engineer in Islamabad. About me.