How to add Clay prospects to Salesforce

The most direct way to send Clay prospects to Salesforce is Clay's built-in Salesforce integration. You connect your Salesforce account in Clay, then add a Salesforce action to your table as a new column. That column can create a record, update one, or look one up, and it runs on every row unless you give it a condition, such as only rows with a verified email. You choose the Salesforce object, usually Lead, and map your Clay columns to its fields: first name, last name, company, title, email, and whatever else your table holds. If you'd rather not connect the two tools, export the table from Clay as a CSV file and bring it into Salesforce with the Data Import Wizard, which handles up to 50,000 records at a time and can match incoming leads to existing ones by email or name.

Either route moves records reliably, but neither decides which records should exist. A Clay table often holds everyone a search returned, and the enrichment columns fill in details without judging fit. The person who changed jobs since the table was built still goes in. So does the contact at a company that already pays you, and the row whose email came back as risky. Unless you built a lookup column first, Clay can also create a lead for someone who already exists in Salesforce, and your org's duplicate rules either block that row or let the duplicate through.

Salesforce adds a decision that most CRMs don't ask for. New prospects usually go in as leads, which carry their own company name, title, and contact details until someone converts them. People at companies you already sell to usually belong as contacts, attached to that company's account. Sending a new person at an existing customer in as a lead splits that relationship across two kinds of record, and the account owner may never see it.

A good result, then, is a set of Salesforce records that sales would actually work: people who fit your ideal customer profile and still hold the role, entered as the right kind of record, never duplicated, assigned to an owner, and carrying the reason they were added.

Kite does that work for you. It qualifies the prospects from your Clay table, checks Salesforce for every person and company already there, and writes the records with the research attached.

Start by exporting your Clay table as a CSV file and sharing it with Kite in a Slack thread, along with what you want done:

"Here's our Clay table of RevOps leaders. Add the ones who fit to Salesforce and assign them to Priya."

Kite is an AI marketer in your Slack. It researches your business, builds a growth strategy, and ships the work that brings you new customers. By the time you ask, it already knows your ideal customer profile, your current customers, and your competitors from that research, so it can judge your Clay rows against a clear standard without a long brief. If a column in your table carries a judgment of its own, such as an AI research column or a score you built, tell Kite how much weight to give it.

You'll need to connect your Salesforce account through OAuth so Kite can read and write your records. Kite doesn't connect to your Clay workspace, so the CSV export is how your table reaches it. If you don't have a Clay list yet, Kite can build one from scratch with its own built-in prospecting sources, and you don't need any account for that part.

Adding leads to Salesforce is routine work, so Kite writes them and then tells you what it did. If you'd like to see the list before anything reaches Salesforce, say so in your request.

Kite reads every row and column in the export, then works out what each column holds. A typical Clay table carries a name, job title, company name, company domain, LinkedIn profile, and work email, plus enrichment columns such as headcount, industry, funding, technology used, or the output of an AI research column. Kite keeps all of it, because a detail that Clay already found is one it doesn't have to look up again.

Kite also notes what the table doesn't say. A Clay row records what was true when the enrichment ran, so a table built a few months ago may describe roles people have since left. Columns that came back empty, such as an email none of Clay's providers could find, become gaps for Kite to fill rather than reasons to drop the row.

Kite decides who belongs in Salesforce by checking each row against your profile before it writes anything. First it confirms that the person still holds the role at that company, using their public profile or the company's own pages, and drops anyone who has moved on. Next it removes your existing customers, your competitors, and anyone who has opted out of hearing from you.

For the rows that pass, Kite fills in what the table is missing through its built-in research sources: the work email, current title, seniority, and LinkedIn profile for the person, and the domain, industry, employee count, and revenue for the company. It keeps each email's verification status exactly as the provider returns it, whether that's verified, catch-all, risky, or unverified, and it marks a missing email as not found rather than guessing one. It includes only business details, which means it leaves out personal email addresses and phone numbers.

Every prospect who passes gets a fit score from one to five, with a one-line reason, such as "VP of revenue operations at a 300-person logistics software company that just opened three sales roles." When the list runs past about fifteen people, Kite splits it into primary and secondary groups so sales knows where to start.

If fewer people qualify than your table holds, Kite tells you how many it kept and why the rest fell short. A short list of good prospects is worth more in Salesforce than a padded one.

Kite searches your Salesforce org before it creates anything, because a person can already exist there as a lead, as a contact, or both. It searches leads and contacts by email address, and it searches accounts by company name and website, so it knows whether each prospect's company is one you already track.

When it finds an existing lead, Kite updates that lead instead of creating a second one. When it finds an existing contact, it leaves the person out of the new leads and tells you, since that person is already part of an account's relationship. Kite also respects your org's duplicate rules. If Salesforce flags a new lead as a likely duplicate of a record Kite's search didn't catch, Kite treats the warning as a match to look into rather than something to push past.

Kite decides what kind of record each prospect should become based on whether their company is already an account in your Salesforce. A person at a company you don't track yet becomes a new lead, which is how Salesforce expects a fresh prospect to arrive. A person at a company that already has an account is a different case, because adding them as a lead would separate them from the account's owner and history.

For those people, Kite follows the convention your records already show. If your team adds new people at existing accounts as contacts, Kite creates the contact and attaches it to the account. If your team routes everyone through leads, Kite creates the lead and notes the existing account on it. When your records don't make the convention clear, Kite asks you once in the thread and records your answer so later batches follow it.

Kite reads the fields on your Lead object before it writes, including the custom fields your team created and the allowed values for picklists such as Lead Status and Lead Source. That way each piece of research lands in a field your team already uses, with a value Salesforce will accept. A new lead gets the following:

• First and last name
• Company
• Title
• Work email
• Website, industry, number of employees, and annual revenue
• City, state, and country
• Lead Source, such as a value your team uses for Clay or outbound lists
• Lead Status, set to the first stage your team uses

Kite writes the fit score and its reason into fields on the lead, and if your org has no field for them, it can create one. It also adds a note to each lead that explains why the person fits, cites the source for each fact, and records any recent event worth mentioning, such as a funding round or a new sales leader.

Each lead also needs an owner. Kite assigns the person you named in your request, or it runs your org's lead assignment rules so each lead routes the way your other leads do. When you want the list tracked as part of a campaign, Kite adds every new lead to the Salesforce campaign you choose. When you want sales to follow up, it creates a task for each lead's owner with a due date.

When the work is done, Kite posts a summary in the Slack thread where you shared the table. It says how many leads and contacts it created, how many existing records it updated, and which rows it skipped and why, including the people who were already contacts on an account. It also reports how many rows from your table made the cut and how many of those have a work email. The full list comes with it as a table, so you can scan it without opening Salesforce.

From there, Kite can draft a personalized outreach email for each primary prospect, written from the research on their company. If you want to keep feeding Salesforce, share each new Clay export in the same thread, and Kite will qualify the batch against what's already in your org before adding anyone.

When Kite finishes, your Salesforce org holds a set of qualified prospects that sales can work right away, and your Slack thread holds the record of what changed.