Skip to main content
The Salesforce integration uses a hybrid model: stable agent-facing tools for common CRM and support work, plus generic Salesforce primitives for discovery and custom orgs. Salesforce orgs model customers differently. A B2B org often uses 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.

​
Why Veryfront sits between agents and Salesforce

There are three useful ways to connect agents to Salesforce: Veryfront keeps Salesforce API access underneath the integration, then exposes a governed tool contract above it. Agents see customer, case, account, contact, lead, opportunity, and knowledge capabilities. The project config decides which tools are visible, which Salesforce objects are allowed, whether expert SOQL is available, and how the connected org maps to Veryfront concepts. This gives teams the flexibility of Salesforce APIs without making raw Salesforce schema access the default agent interface.

​
Agent-facing tools

Agents call tools named after work, not Salesforce storage details: These tools give agents a consistent vocabulary across projects. The agent asks for customer context, cases, or support notes. Veryfront translates that intent into the Salesforce objects and fields configured for the connected org.

​
Generic Salesforce tools

The integration also exposes generic tools for expert and fallback paths: Generic tools are necessary because no fixed product catalog can cover every Salesforce implementation. They let consultants and admins inspect the org, validate mappings, and handle custom objects without adding a new Veryfront tool for every Salesforce object. The generic tools are intentionally not the primary production interface. Use them for discovery, validation, and consultant/admin workflows. Ordinary support agents should use curated tools such as find_customer, list_cases, and add_case_comment.

​
Customer model

customer is a Veryfront semantic concept, not a native Salesforce object. The default Service Cloud profile maps customer context to: That default works for a common B2B Service Cloud demo and for many account-based support orgs. Production deployments need a validated profile when the org uses Person Accounts, custom customer objects, account hierarchies, entitlements, assets, subscriptions, or custom support objects.

​
Project configuration

Salesforce project configuration is an optional governance layer. When the project has no Salesforce config, or when config is {}, the integration keeps the default compatibility behavior. Existing projects keep working after connecting Salesforce. When the project saves Salesforce config, Veryfront applies the saved governance fields. New Studio saves use the object-first shape; older allowedSObjects, allowExpertSoql, and maxQueryRows configs are still accepted during migration. For the Service Cloud support demo, allow Account, Contact, Case, CaseComment, and KnowledgeArticleVersion, keep expert SOQL disabled, and set capabilities.maxQueryRows to 100.

​
Salesforce profile

A Salesforce profile defines how Veryfront maps semantic tools to one Salesforce org: The current product stores these mappings and enforces object and tool policy. Metadata validation with Salesforce describe_object should be added before using advanced custom mappings in high-assurance production deployments, so invalid objects, missing fields, and inaccessible relationships become configuration errors instead of agent runtime surprises.

​
Why this scales

The agent contract stays stable while the Salesforce mapping changes per org. For example, find_customer can resolve different backend models: This separates agent behavior from Salesforce schema variance. Agents learn one stable set of tools. Admins and consultants adapt the Salesforce profile to the customer’s org.

​
Salesforce references

This architecture follows established Salesforce patterns rather than a single product-specific blueprint. Veryfront uses these practices to keep the Salesforce integration portable. The profile records how a specific org models customer context, while Salesforce permissions and metadata decide what the connected user can actually read or write.

​
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 allow add_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.

​
Competitive gaps to close

The current architecture is strong for governed Service Cloud and CRM agents because the agent contract is stable, project-scoped, and configurable. To be stronger than a direct Salesforce MCP or API-only integration, the product should continue closing these gaps:

​
Current status

The current Salesforce integration exposes Service Cloud and Sales Cloud tools plus metadata and SOQL fallback tools. Studio now lets admins configure object access, expert SOQL, row limits, and concept mappings without relying on a fixed preset list. The remaining scalable production hardening path is to validate custom mappings with describe_object, generate agent instructions from the validated profile, and make connection mode, audit, and write approval behavior visible in the product.