Clay makes Functions the primary reusable enrichment building block

Functions become Clay's primary reusable enrichment surface

Clay's September 21 product roundup says Functions are now the primary way to save and reuse enrichment logic in tables. The company says users can turn an enrichment setup into a reusable step with Save as Function, migrate private Recipes to user-managed Functions in one click and use managed functions that are automatically installed in workspaces. Clay also says public Recipes, column templates and Table Template Library entry points have been retired, while waterfalls can point users toward an equivalent managed function.

The same roundup introduces workspace Auto Top-Ups for data credits. Admins can set a balance threshold, choose the amount of credits to purchase when the threshold is crossed and optionally set a daily spend limit. These are vendor-described workflow and billing controls. They do not by themselves prove lower enrichment cost or better data quality, but they change how reusable logic and resource availability are operated.

Sources: Clay Product Roundup, September 21, 2026

Reusable enrichment logic should have a contract

A saved function can spread one enrichment decision across many tables faster than a manually copied column setup. That is useful only when the function's behavior is explicit. Record its business purpose, required inputs, provider or waterfall logic, expected output fields, null handling, normalization rules, credit behavior and owner. If the function changes, operators should be able to identify which downstream workflows consume the new version.

Treat output schema as an interface. If a function once returned a normalized job title and now returns a richer object, downstream filters, CRM mappings and scoring logic can fail without the function itself being broken. A small contract around field names, data types and allowed unknown values makes reusable logic safer than copying opaque enrichment steps into every table.

Recipe migration needs representative regression cases

A one-click migration path reduces mechanical work but does not remove the need to compare outcomes. Choose representative records from the existing Recipe or template workflow: a clean match, a missing identifier, an ambiguous company, a provider miss, a record that triggers a fallback source and a record that should produce no enrichment. Run the old and new paths and compare the fields that downstream systems actually consume.

Do not require byte-for-byte equality if the migration intentionally changes a provider or normalization rule. Instead define which business outputs must remain stable and which differences are accepted. Keep the old logic discoverable until the new function has passed normal operating volume. If several tables depend on the same migrated logic, roll them over in a controlled sequence instead of changing every consumer at once.

Managed functions create a vendor-change boundary

Clay says managed functions are installed in every workspace and that waterfalls can offer equivalent managed functions. A managed building block can reduce maintenance, but it also creates a dependency on logic the vendor may evolve. RevOps should distinguish user-managed functions from vendor-managed ones in the inventory and document which outputs are material enough to warrant release review when behavior changes.

For consequential enrichment, keep source attribution and timestamps downstream. If a managed function changes provider order or normalization in the future, a CRM field should not become impossible to explain. Store enough evidence to identify the source used for a material value, especially where enrichment can trigger routing, sequence enrollment, territory assignment or account qualification.

Auto Top-Ups solve availability and introduce a spend control

An automatic credit purchase can prevent production enrichment from stopping at an arbitrary balance threshold, but it converts an availability problem into an automated spending decision. Set the threshold from observed workload rather than fear of running out, and use the optional daily spend limit as a hard guardrail. Name the workspace owner who receives low-balance, top-up and unusual-consumption alerts.

Measure credits by workflow or business purpose where possible. A sudden increase can come from legitimate volume, a newly expensive provider path, duplicate processing, a loop or an overly broad audience. Auto Top-Ups should keep expected work moving while making abnormal consumption visible; they should not make a runaway workflow harder to notice because the balance silently refills.

Promotion should separate logic readiness from volume readiness

Before a shared function becomes the default across a workspace, test correctness on a bounded sample and then test cost on realistic volume. Record match rate, unknown rate, provider distribution and credits consumed for the sample without turning those figures into universal benchmarks. Compare them only with the workflow's own prior baseline and requirements. A function can be correct yet economically unsuitable at production volume.

The useful outcome of Clay's shift is a clearer reusable unit for enrichment logic. RevOps can make that unit safer by versioning behavior, tracing source evidence, testing migration cases and pairing automated credit availability with explicit spend limits. The product surface becomes simpler; the operating contract should become more precise at the same time.