AI Chatbot Salesforce Integration

Decide what a conversation becomes in Salesforce

Salesforce is not a single contact list. It is an object model shaped by years of your own org’s customization: record types, validation rules, required fields, automation and sharing settings that someone configured for good reasons. A chatbot that ignores all of that and simply posts leads will either be rejected by the org or quietly pollute it.

So the first design question is not technical. For each kind of conversation, what record should exist afterwards, and who should see it? The mapping we most often agree with clients looks like this:

Orgs that use Person Accounts for consumer customers need a different branch, because the individual is both the account and the contact. That is one of several questions we answer by looking at your org’s actual configuration rather than assuming a default setup.

Authentication through an app definition and a dedicated integration user

The chatbot’s server authenticates with OAuth 2.0 against an app definition in your org. Historically that has been a Connected App; Salesforce has also been rolling out External Client Apps, and we confirm with your admin which one your org should use. Because no human is present to click an approval screen, we use a server-to-server flow: the JWT bearer flow, signed with a certificate we generate and you upload, or the client credentials flow where your org’s policies allow it. No stored passwords, no security tokens glued onto passwords in a config file.

Requests run as a dedicated integration user, never as an administrator’s personal login. That user receives a permission set granting exactly what the bot needs — create Leads, read Contacts by email, create Cases and Tasks, write the transcript object — and nothing more. Salesforce has offered an API-only integration user license for this purpose; whether your org has seats available is quick for your admin to check.

The payoff is practical. Every record the bot creates shows the integration user as its creator, so reports can separate chat-sourced data. A staff member changing a password cannot break the bot. Revoking access is a single switch. One prerequisite to check early: API access depends on your Salesforce edition. It is included in Enterprise and Unlimited, while some lower editions require it as an add-on, so edition is the first thing we ask about.

Match before you create: avoiding duplicate Leads and Contacts

The most frequent complaint about chat-to-Salesforce connections is duplicates. A returning customer asks a question and becomes a brand-new Lead; a prospect who chatted twice now exists three times. Sales reps stop trusting the data within a month.

Our integration looks things up before writing anything:

1. Normalize the identifiers the visitor gave: lowercase and trim the email, convert the phone number to a consistent international format.
2. Query Contacts by email, then open Leads by email, and by phone as a secondary check.
3. If a Contact matches, attach the conversation to it as a Task or a Case. The bot does not create a Lead for someone who is already a customer.
4. If an open Lead matches, update it with new information — without overwriting fields a rep has already filled, unless you tell us a particular field should always take the newest value — and log the conversation against it.
5. Only when nothing matches is a new Lead created.

Your org’s own duplicate rules and matching rules also apply to API inserts. When a rule blocks a save, the API returns a duplicate error, and we handle it by attaching to the existing record the rule identified rather than forcing the insert through. Each chat session also carries a unique ID stored in a custom external ID field, so if a write is retried after a timeout, the integration upserts against that ID instead of creating a twin.

Field mapping, picklists, record types and validation rules

Most integration failures in production come from the gap between what a visitor typed and what your org will accept. We work through these with your admin using a written mapping sheet:

• Required fields. The standard Lead object requires Last Name and Company. Consumer visitors rarely have a company, so we agree on a convention with you instead of letting the bot invent one.
• Restricted picklists. A value must match an allowed entry exactly. Free-text answers such as “we need it for our warehouse” are mapped in code to your allowed Industry or Product Interest values, with anything unmatched set to a fallback and the original wording preserved in the description.
• Record types. If your Leads or Cases use record types, the integration sets the correct one explicitly, and the integration user needs access to it.
• Validation rules. Active rules on each target object are listed during discovery, because a rule written for manual data entry can reject every API insert.
• Attribution. UTM parameters and the landing page are captured from the browser and written to fields your marketing reports already use, and optionally the Lead is added to a campaign as a Campaign Member.

The mapping sheet becomes documentation your admin keeps. When someone later renames a picklist value or adds a required field, the sheet shows immediately whether the chatbot is affected.

Assignment rules, owners and follow-up tasks

A Lead owned by the integration user is a Lead nobody works. Salesforce’s lead and case assignment rules can run on records created through the API — on the REST API this is controlled by a request header, Sforce-Auto-Assign — so your existing territory or round-robin logic decides the owner exactly as it would for a web form. If your org routes through queues or Omni-Channel, we respect that too.

The integration also creates a Task for the new owner with a due date matching your response target and a subject line that summarizes the request in plain words. Notification can come from Salesforce itself, through a Flow your admin controls, or from our service by email or team chat when reps live outside Salesforce during the day.

API limits, batching and what happens when Salesforce says no

Every org has a rolling 24-hour allocation of API requests based on its edition and licenses, and that allocation is shared with every other integration you run: marketing automation, ERP sync, data enrichment. A careless bot that queries Salesforce on every message can consume a noticeable share of it.

We keep the footprint small by design:

• Write at milestones — contact details captured, conversation ended, case requested — not after every message.
• Combine lookup and write into a single Composite API request where the logic allows, cutting several round trips down to one.
• Cache metadata such as picklist values and record type IDs rather than fetching them per conversation.
• Watch consumption through the limits resource and alert well before the allocation gets tight.

Writes pass through a durable queue. If Salesforce returns a temporary error or is in a maintenance window, the job retries with backoff. Permanent errors, like a validation rule rejecting the data, go to a review list with the exact error message and alert your admin, so a record is never silently dropped. The visitor sees none of this; their conversation finishes normally either way.

Letting Salesforce data flow back into the conversation

Integration does not have to be one-way. Once a visitor is verified — for instance by entering a short code we email to the address on their Contact record — the bot can answer questions from live Salesforce data: the status of their open Case, the name of their account manager, or the date of a scheduled appointment. Each lookup is a narrowly scoped query run by our server, and the model sees only the fields that answer the question.

For changes that happen on the Salesforce side, a push beats polling. Depending on your edition and preferences, a record-triggered Flow can call our endpoint when a Case closes, or we can subscribe to Platform Events or Change Data Capture. That lets the bot tell a returning visitor their issue was resolved yesterday without querying Salesforce on every page view. Which mechanism fits your org is settled during discovery.

If your team maintains articles in Salesforce Knowledge, published articles meant for customers can be synced into the bot’s knowledge index so answers stay consistent with what support agents use. Internal-only articles stay out.

Salesforce’s own conversational tools versus a custom chatbot

Salesforce sells its own conversational AI and messaging products inside Service Cloud. If your support operation already runs there, with agents working in the Service Console and routing through Omni-Channel, the native route deserves a serious look. We will say so on the consultation call rather than steer you toward a custom build.

A custom chatbot connected through the API tends to make more sense when:

• The website assistant serves sales and support at once and draws on several systems, with Salesforce as one of them.
• You want freedom to choose or switch the underlying language model.
• Salesforce is your sales CRM, but support, scheduling or billing live elsewhere.
• Additional per-user or per-conversation licensing does not fit your budget or usage pattern.

To be clear about our position: EVOTECH IT LLC is not a Salesforce partner and has no affiliation with Salesforce. We build against its public, documented APIs, the same ones available to any customer’s developers.

Proving it in a sandbox before production

Your admin creates a Developer or Developer Pro sandbox, and the integration is built and tested there with its own app credentials, separate from production. Our test script covers the cases that break real integrations:

• A brand-new prospect, producing one Lead with correct source, owner and campaign.
• An existing Contact asking a support question, producing a Case and no Lead.
• A returning Lead supplying a new phone number, updating rather than duplicating.
• An answer that matches none of your picklist values.
• A validation rule rejection, confirming it reaches the review list with a readable message.
• A duplicate rule block, confirming the conversation attaches to the right existing record.
• Salesforce unreachable for several minutes, confirming queued writes complete afterwards.
• A very long transcript, confirming nothing is truncated without notice.

Your reps then run their own tests in the sandbox, playing visitor and checking what lands in their queues. Production credentials are issued only after they are satisfied.

How an EVOTECH Salesforce chatbot project runs

Discovery

It starts with a no-cost call, by phone or video, followed by a working session with your Salesforce admin covering edition, objects, rules and the automation already in place. Our Houston-area staff have run EVOTECH IT LLC for over 20 years and deliver this integration work remotely to clients anywhere in the country.

Design and quote

We produce the mapping sheet, the matching logic and the list of permissions the integration user needs. Those three documents are what our fixed-scope written quote is priced from, which means nothing in the build is left open to interpretation.

Build, sandbox, user acceptance

The integration service and chatbot tools are built, run through the test script above, then handed to your reps for acceptance.

Production and monitoring

After cut-over we watch the review list, API consumption and duplicate reports closely through the first weeks. If your wider CRM strategy is still taking shape, our AI chatbot CRM integration page compares approaches across platforms, and broader connected-systems work sits under our AI integration services.

Related services

Frequently asked questions