Salesforce
Salesforce is where the relationship lives — every account, contact, opportunity and case, and the history of what was said and promised. Connecting it means an assistant can answer about a specific customer rather than in generalities.
Salesforce is where the relationship lives — every account, contact, opportunity and case, and the history of what was said and promised. Connecting it means an assistant can answer about a specific customer rather than in generalities.
What Salesforce holds, and why that matters here
Salesforce is the most widely deployed CRM in the world and, in most organisations that run it, the authoritative record of the customer. Sales pipeline, service cases, contact history and the commitments made along the way all sit in it.
The reason it produces so much internal contact is licensing and habit. Not everyone who needs to know about a customer has a Salesforce seat, and those who do often ask a colleague rather than search. Both problems have the same answer: let people ask in words.
- Accounts and contacts — who the customer is, who works there, and how to reach them.
- Opportunities — pipeline stage, value, close date and next step.
- Cases — service history, current state and resolution.
- Activities — the record of calls, meetings and emails against an account.
- Custom objects — whatever your organisation has modelled on top, which is usually substantial.
Questions Elbi can answer from Salesforce
What is happening with this account?
A plain-language summary of stage, open cases and recent activity, for someone about to walk into a meeting.
What stage is this deal at?
Opportunity stage, value and next step without opening the CRM.
Has this customer raised anything before?
Case history, which prevents the specific embarrassment of asking a customer to explain a problem they already reported.
Who owns this account?
Ownership and team, which is the most-asked internal question in any organisation over a certain size.
What did we promise?
Activity and note history against the account, which settles disputes.
Log this as a lead
Capturing an enquiry from a conversation straight onto the record, where you enable write-back.
How Elbi reads from a Salesforce org
- Your admin creates the connected appThe assistant reaches Salesforce through a connected app (or the newer external client app) that your administrator creates in Setup, with only the OAuth scopes the connection needs. The app belongs to your org, and so does the decision to block it.
- A dedicated integration user sets the outer limitRequests run as an integration user rather than as a named employee. Its profile and permission sets decide which objects are readable at all — Account, Contact, Opportunity, Case, and the custom objects you name — and field-level security hides every field not on the list.
- The person asking narrows it furtherInside that limit, answers follow the asking person's own access. A salesperson whose role and sharing rules keep another region's opportunities out of view in Salesforce will not see them through Elbi either.
- A question becomes a precise query"What is happening with this customer?" becomes a search for the account, then a read of its open opportunities, open cases and latest activities. Where two accounts match — common when the same company is recorded once in Arabic and once in English — Elbi asks which one is meant instead of choosing.
- API names are translated into a sentenceSalesforce answers with field API names, picklist values and record IDs. The reply turns a field such as Renewal_Date__c into "the renewal date", in Arabic or English to match the question, and leaves the IDs out.
- Writes happen only where you switched them onThe useful writes are few: a Lead from a new enquiry, a Case with the conversation attached, a completed Task logged against the account. Each is enabled separately, needs create permission on that object for the integration user, and can wait for a person to confirm.
Salesforce permissions, credentials and control
| Direction of access | Read by default. Creating Leads, Cases or Tasks is switched on per object and can be held behind human confirmation. There is no reason to give the integration user edit or delete rights on anything. |
|---|---|
| Objects and fields | Decided by the integration user's profile and permission sets. Field-level security keeps out what the assistant has no reason to read — national ID numbers, internal margin notes, free-text fields nobody asked for. |
| Sharing and record visibility | Your organisation-wide defaults, role hierarchy and sharing rules still apply. Answers stay within the asking person's access, established through your own sign-in rather than claimed in the chat. |
| Credentials | The connected app's consumer key and secret, and the tokens issued under it, belong to your org. Your admin can rotate the secret, revoke tokens or block the app from Setup, without asking us. |
| Where data goes | Records read for a question are used to form the answer and are not copied into a second store. Message content is destroyed within 24 hours, usually when the conversation ends, and no external AI service sees it. |
| Audit | Each lookup can be recorded — the question, the object queried, the conversation it belonged to. Salesforce's own login history for the integration user gives your admin an independent record on the Salesforce side. |
| If it is unavailable | If Salesforce cannot be reached, or the org's API allowance for the day is used up, the assistant says it could not check and offers a person rather than repeating an old value. |
What this replaces
The most valuable thing Salesforce holds is context, and context is exactly what is lost when a customer moves between channels. Someone who raised a case last week and now arrives in chat expects to be recognised. If the assistant can read the case history, they are. If it cannot, the customer repeats themselves, and every repetition is a small deposit against the relationship.
Internally, the pattern is different but the cost is similar. Sales managers ask salespeople for pipeline status; salespeople ask service for case status; everyone asks who owns an account. All of that is one lookup, and all of it currently interrupts someone.
The write-back case is genuinely useful here and worth treating carefully. Capturing a lead from a conversation directly onto the record removes the gap where enquiries are lost — but anything that writes should be deliberate, scoped and reviewable, because a CRM full of automated noise is worse than one with gaps.
Who asks Salesforce questions most
B2B sales organisations
Pipeline and account questions asked constantly by managers and colleagues.
Service teams
Case history and status, so a customer arriving in chat is recognised.
Field sales
Account summaries for people about to walk into a meeting, on a phone.
Marketing
Lead capture from conversations directly onto the record.
Where to start with Salesforce
The first questions worth connecting are the ones already arriving about single records: the status of an open case, who owns an account, and what stage an opportunity has reached. All three live on standard objects, need a handful of fields each, and can be answered without touching anything custom.
For customer-facing use, case status is usually the right opening. By the time a customer asks, they are identified, and the answer is one record. Internally, the account summary earns its place fastest: a manager or a colleague without a Salesforce seat asks what is happening with a customer and gets stage, open cases and last activity in a single reply, instead of messaging the account owner.
Leave the reporting questions to Salesforce. Reports and dashboards already aggregate pipeline properly, and an assistant answering "how did we do this quarter?" from raw queries is slower and less reliable than the dashboard someone already built. Custom objects come after the standard ones, once a month of real questions shows which of them people actually ask about.
Connecting Salesforce, step by step
- Trace each question to its objectsEvery question on the shortlist is traced to the objects and fields that answer it. "Who owns this account?" needs Account and its owner; "has this been reported before?" needs Case with status, subject and created date. That list becomes the permission set.
- Create the integration userYour admin creates a user for the assistant alone, ideally on an API-only profile, and grants read access through a permission set that covers exactly the objects and fields on the list — nothing inherited from a copied employee profile.
- Create and lock down the connected appIn Setup, the admin creates the connected app with the scopes the connection needs and restricts it to admin-approved users, so only the integration user can use it. The key and secret stay with you, and you can rotate or revoke them at any point.
- Map your org's own modelRecord types, picklist values, custom objects and fields added by installed packages are mapped so the assistant uses your terminology — including Arabic field labels, where your org has translated them in Translation Workbench.
- Rehearse in a sandboxWhere you have a sandbox, the connection is tried there first against realistic cases: an account that does not exist, two contacts with the same name, a record the asker should not see, Salesforce unreachable. Production follows once those behave.
- Go live narrow, extend the permission setLaunch on the shortlist, read what people actually ask, then add objects by extending the permission set rather than rebuilding the connection. Each change is yours to make and appears in Setup Audit Trail.
Salesforce data and the PDPL
A Salesforce org usually holds more personal data than its field list suggests. Names, mobile numbers and email addresses are the obvious part; case descriptions and logged emails, where customers explain their circumstances in their own words, are the part reviewers find later. Under the Saudi Personal Data Protection Law, what matters is what is processed, on what basis, who can see it and for how long.
Field-level security gives the first answer a precise form. If a question does not need a free-text field, the integration user cannot read it, and "what could the assistant see?" is answered by pointing at a permission set. On the Elbi side, message content is destroyed within 24 hours, usually when the conversation ends; Salesforce remains the system of record, and deletion requests are handled there as they are today.
If customers will have their own cases or account details read during a conversation, say so before the first lookup, in Arabic and in English. Designing that notice into the opening of the conversation is far easier than adding it after a legal review asks for it.
What organisations typically see
Salesforce's own AI options, and where Elbi fits
Salesforce has its own conversational tools. Agentforce, and Einstein Bots before it, run inside the Salesforce platform, act on your org's data and flows directly, and are administered by the same people who run the org. For an organisation whose customers and staff live mostly inside Salesforce channels, that closeness is the main argument for them.
The questions Saudi buyers tend to put to any option, Salesforce's included, are the same three. How good is the Arabic — in what customers type and in what comes back? Where is the language processing done, and does that fit your PDPL assessment? And does the assistant need to answer from more than Salesforce — a policy document, an ERP, a ticketing system — in the same conversation?
Elbi's answers are specific: Arabic and English are both first languages, conversation processing stays inside the Kingdom on infrastructure you control, no external AI service sees the data, and Salesforce is one connected source among several rather than the place the assistant lives. Running both is reasonable where the native tools already fit — Elbi as the bilingual front door, Salesforce automation for work that never leaves the org.
Whichever route you take, the same two mistakes cause most trouble: giving the integration user View All Data because it is quicker than building a permission set, and asking a conversational tool report-style questions that a Salesforce dashboard already answers better.
Common questions
Yes. Answers are bounded by the permissions of the person asking. Someone who cannot see a record in Salesforce cannot see it through the assistant.
Expected. Custom objects and fields are mapped during deployment; deciding which are relevant is a business conversation rather than a technical one.
Where you enable it. This is the most common write-back request and is scoped to specific object types with optional human confirmation.
No. Both live in the same org, so one integration user can read opportunities and cases alike. What it may read is set by its permission sets, not by which product a record belongs to.
Where you use Knowledge and give the integration user access to published articles, yes. They become one more source alongside account and case records, answered in the language of the question.
Where case creation is enabled, a new case with the conversation attached, which your admin can route with the assignment rules you already use. The agent picks it up knowing what was asked and what the assistant already checked.
Connect Elbi to your Salesforce org
A working assistant against your own accounts, cases and opportunities, in Arabic and English.