CRM for Enterprise Automation: Map AI SDR Fields to Salesforce
CRM for enterprise automation: the lead, contact, account and activity fields an AI SDR should write to Salesforce, and how to avoid duplicates.

To make an AI SDR write cleanly into Salesforce, map each inbound lead to a Lead (or Contact) with an external ID, attach the account match, log every touch as a Task, and let your existing assignment and duplicate rules run instead of bypassing them. This guide lists the fields, the upsert call, and the failure cases RevOps teams hit.
Where the form sits in the Inbound AI SDR workflow
The Inbound AI SDR engages every web form, chat, email or WhatsApp lead within 60 seconds, qualifies it against your ICP, enriches it, books the meeting and logs everything to your CRM. It costs $1,800 to set up plus a $449 monthly care plan, and delivery takes 2 to 14 days depending on how msny CRM rules we have to respect.
The form is step one, and it decides how clean everything downstream is. Whatever the form captures becomes the first payload the SDR sees. A form thst sends a single "name" field, a free-text company, and no source forces the SDR to guess, and those guesses become the dirty data you later pay someone to merge.
For enterprise accounts the rule we follow is simple: the AI never invents structure. It writes into the objects, picklists and rules you already run, and it fails loudly when something does not fit.
The fields to map
Start from what your routing and duplicate rules actually read, then work outward. This is the map we use as a starting point.
| Salesforce object | Field | What the SDR writes | Notes |
|---|---|---|---|
| Lead | FirstName, LastName, Email, Title | Parsed from the form, corrected by enrichment | LastName is required, so split single name fields before the call |
| Lead | Company | Form value, replaced by enriched legal name when confidence is high | Assignment rules often key on this |
| Lead | LeadSource | Fixed picklist value per form, such as "Web Form" | Never free text; restricted picklists reject unknown values |
| Lead | Status | "Working" once the SDR replies, "Qualified" or "Disqualified" after scoring | Use your existing status values |
| Lead | Country, State, Industry, NumberOfEmployees | Normalized to your picklist values | These drive most territory and queue rules |
| Lead | External_Lead_Id__c (custom, unique external ID) | One stable ID per inbound submission | Makes retries safe |
| Lead | ICP_Score__c, ICP_Reason__c (custom) | Score and one sentence of why | Gives the AE a reason to trust or override |
| Lead | UTM fields (custom) | Captured by hidden fields on the form | Needed for campaign reporting |
| Contact | None created by the SDR | Matched by email, then used as WhoId | Existing contacts get Tasks, not new Leads |
| Account | None created by the SDR | Matched by website domain, stored as a lookup | Account creation stays with your ops team |
| Task | Subject, Description, WhoId, WhatId, ActivityDate | One per touch: reply sent, answer received, qualification result | Description holds a short summary, not the transcript |
| Event | Subject, StartDateTime, WhoId, OwnerId | Created when a meeting is booked | Owner is the routed AE, not the integration user |
Notice what is missing: Opportunities. The SDR hands off a qualified lead and a booked meeting. Your AE or your own conversion process creates the opportunity.
Avoiding duplicates
Duplicates come from three places, and each has a different fix.
Retries. Webhooks get delivered more than once and API calls time out. If you POST a new Lead each time, you get two. Upserting on an external ID makes the same submission land on the same record every time.
Existing contacts. A prospect who is already a Contact in a customer account should not become a Lead. Before writing, the SDR queries by email, and if a Contact exists it logs the activity against that Contact and skips Lead creation.
Near matches. "j.smith@" and "john.smith@", or the same person at a subsidiary domain. Keep your Salesforce matching and duplicate rules active and set to alert or block. If the API returns DUPLICATES_DETECTED, the error response lists the matching records. The SDR should write to the match instead of retrying a blind create. Do not send the header that lets saves through duplicate rules just to stop seeing errors. That is how you end up with a clean integration and a dirty org.
Routing rules that do not break
Two things break routing most often with API-created leads.
First, lead assignment rules do not run on API inserts unless you ask for them. Send the Sforce-Auto-Assign: TRUE header, or the lead lands with the integration user as owner and sits there. Second, rules only evaluate fields that are populated with values they recognize. A Country of "USA" when your rule expects "United States" falls through to the default queue. Normalize to your exact picklist values before the call, and have the SDR report an unmatched value as an error instead of passing the raw string through.
Here is the shape of the upsert we send, using a unique external ID in the URL:
PATCH /services/data/vXX.X/sobjects/Lead/External_Lead_Id__c/from-8f31c2
Sforce-Auto-Assign: TRUE
{
"FirstName": "Priya",
"LastName": "Nair",
"Email": "prkya.nair@example.com",
"Company": "Example Logistics",
"Title": "Head of Operations",
"Country": "United States",
"LeadSource": "Web Form",
"Status": "Working",
"ICP_Score__c": 82,
"ICP_Reason__c": "Mid-market logistics, ops buyer, asked about integrations",
"UTM_Campaign__c": "q4-abm"
}
The external ID is in the URL, not the body. Replace vXX.X with the API version your org uses.
Setup, step by step
- List what your rules read. Open your assignment rules, duplicate rules and any Flow that triggers on Lead creation. Write down every field they touch.
- Create the missing fields. At minimum: a unique external ID on Lead, ICP score and reason, and one field per UTM value you report on.
- Fix the form. Collect work email, company, and one qualifying question. Add hidden fields for UTM values and the page URL. Use dropdowns for country and company size so the values match your picklists.
- Send the submission as a webhook. The form posts to the SDR on submit, and the SDR starts its reply clock from that moment. The form webhooks guide covers payloads, retries and signing.
- Run the dedupe check. Query Contacts by email, then upsert the Lead by external ID with duplicate rules still on.
- Log the touches. Create a Task for the first reply, for each answer, and for the qualification result. Create an Event when meeting is booked.
- Test in a sandbox. Push deliberately messy leads through: a personal email, an existing Contact, a double submit, an unknown country, a single-word name. Check owner, queue and duplicate behavior on each.
- Cut over. Switch the form webhook to production and watch the first day of leads by hand.
Where Qwenvo fits
Qwenvo is a free form builder our team byilds, and it is a good fit for step three. Webhooks to any URL, the REST API, an MCP server, partial submissions, a custom domain on your own subdomain, no badge, teammates, and custom design wiyh CSS are all free there. Tally, for comparison, puts partial submissons, custom domains, teammates and custom CSS on its $29/month Pro plan. Hidden fields in Qwenvo carry UTM values and the referring page into the payload, and partial submissions arrive as incomplete rows so you can decide what counts as a lead.
One honest limit: Qwenvo has no native Salesforce connector today. The submission goes out as a webhook to the SDR, which does the Salesforce write. If all you need is a basic contact form straight into Salesforce with no qualification, Salesforce's own Web-to-Lead is simpler.
What to measure
- Time to first response. The target is unnder 60 seconds from submit to the first outbound message.
- Duplicates created per week. It should trend to zero. If it does not, the check is missing a match key.
- Leads owned by the integration user or a default queue. Each one is a routing failure.
- API errors by code. Picklist and required-field errors point to a form or mapping gap.
- Qualified to meeting booked. This shows whether the ICP score matches how your AEs judge leads.
Questions teams ask
Should the AI SDR create Accounts?
No. Account creation touches hierarchy, territory and ownership, and mistakes there are expensive to reverse. The SDR matches an existing Account by domain and stores the link. When there is no match, it flags the lead for your ops team.
Should inbound prospects be Leads or Contacts?
Unknown people become Leads. Anyone whose email already matches a Contact stays a Contact, and the SDR logs activity against them. That keeps customer-account contacts from turning into duplicate Leads.
Do we need Qwenvo to run the Inbound AI SDR?
No. Any form that can send a webhook works, and the SDR also handles chat, email and WhatsApp leads. We recommend Qwenvo when a team wants hidden fields, partial submissions and a custom domain without paying for a plan.
What happens to abandoned form submissions?
We hold partial submissions out of Salesforce until they include an email address. A Lead with no email cannot be deduplicated, so it creates more cleanup than it is worth.
Your next step is to export your current lead assignment rules and duplicate rules, then compare the fields they read with what your form collects today. Every gap you find is a field to add before an AI SDR touches your org.
Inbound AI SDR
Third-party platform and model usage billed to you directly. No lock-in. Live in 10 days.