Account and Contact. A B2C org can use Person Accounts. Enterprise orgs can add entitlements, assets, subscriptions, account hierarchies, record types, and custom objects.
The integration keeps those differences behind a Salesforce profile layer instead of exposing every org model directly to agents.
Agent-facing tools
Agents call tools named after work, not Salesforce storage details:| Tool pattern | Purpose |
|---|---|
find_customer | Resolve a customer identity from Salesforce records. |
list_cases | Find Service Cloud cases by customer, account, contact, owner, queue, or status. |
get_case | Read the full case record for support triage. |
list_case_activity | Read comments and timeline context for a case. |
search_knowledge_articles | Find published Knowledge content for support answers. |
add_case_comment | Add a controlled support note or customer-visible comment. |
Generic Salesforce tools
The integration also exposes generic tools for expert and fallback paths:| Tool | Purpose |
|---|---|
describe_object | Read Salesforce object metadata, fields, relationships, and permissions. |
run_soql_query | Run a bounded read-only SOQL query for custom objects and advanced reports. |
Customer model
customer is a Veryfront semantic concept, not a native Salesforce object.
The default Service Cloud profile maps customer context to:
| Concept | Default Salesforce source |
|---|---|
| Customer account | Account |
| Customer person | Contact |
| Support issue | Case |
| Case timeline | CaseComment |
| Help content | KnowledgeArticleVersion |
Salesforce profile
A Salesforce profile defines how Veryfront maps semantic tools to one Salesforce org:| Profile setting | Meaning |
|---|---|
customer_model | account_contact, person_account, or custom_object. |
customer_object | Object that represents the customer, such as Account, PersonAccount, or Customer__c. |
contact_object | Object that represents people, usually Contact. |
case_object | Object that represents support work, usually Case. |
identity_fields | Fields used for lookup, such as Contact.Email, Account.Name, Account.Website, or external IDs. |
case_relationships | Relationships that connect cases to customers, such as Case.AccountId or Case.ContactId. |
read_filters | Default filters, such as excluding closed cases or limiting Knowledge articles to published versions. |
write_policy | Allowed write actions, such as internal case comments only. |
Why this scales
The agent contract stays stable while the Salesforce mapping changes per org. For example,find_customer can resolve different backend models:
| Org model | Backend mapping |
|---|---|
| B2B Service Cloud | Account plus related Contact and Case records. |
| B2C Service Cloud | Person Account records plus related cases. |
| Enterprise Service Cloud | Account, Contact, Entitlement, Asset, and Case. |
| Custom implementation | Customer__c, custom relationship fields, and custom support objects. |
Salesforce references
This architecture follows established Salesforce patterns rather than a single product-specific blueprint.| Reference | How it applies |
|---|---|
| Salesforce Customer 360 Data Model | Treats customer context as a harmonized model across objects, fields, metadata, and relationships. |
Salesforce REST sObject Describe | Supports metadata-driven object and field discovery before a profile is accepted. |
| Salesforce Well-Architected Secure | Supports least-privilege integration access and separate integration identities where service users are used. |
| Salesforce Integration Patterns | Supports authenticated API access over HTTPS and explicit integration design. |
| Salesforce Data Model Gallery | Keeps object and relationship design explicit when a Salesforce cloud or industry model uses specialized data structures. |
Safety model
Read tools can use broad Salesforce metadata and query capability, but write tools stay narrow. Veryfront treats Salesforce writes as explicit capability grants. A project can allowadd_case_comment without allowing generic record creation, updates, or deletes. SOQL execution is read-only, bounded, and validated before execution.
This keeps support automation useful while preventing agents from receiving unrestricted Salesforce mutation access.
Current status
The current Salesforce integration exposes Service Cloud and Sales Cloud tools plus metadata and SOQL fallback tools. The first default profile assumesAccount, Contact, Case, CaseComment, and KnowledgeArticleVersion.
The scalable production path is to make that profile explicit per connection or project, validate it with describe_object, and generate agent instructions from the validated profile.
Related
- Salesforce: Auth, scopes, credentials, and available tools.
- Connect an integration: Connect projects to external services.
- Integrations and OAuth: How integration auth models fit together.