A useful Salesforce AI support integration gives the assistant access to approved knowledge, permits specific record changes and transfers unfinished work to the right person. Before connecting an AI platform to Service Cloud, define those three behaviors for one real support workflow.

This guide walks through the Salesforce side of an external AI integration: authentication, permissions, Case mapping, Salesforce Knowledge, routing, testing and rollout. The Salesforce instructions link to current platform documentation reviewed on September 6, 2026. The worked example is illustrative; validate it in your own sandbox and confirm which operations your selected connector supports.

If you are still choosing software, start with our comparison of AI customer support platforms for Salesforce. Use this guide to evaluate the implementation once you have a shortlist.

1. Choose the integration path and first workflow

Agree on where the customer conversation happens, where agents work and which system owns the customer record. An assistant answering on your website, a copilot inside Service Cloud and an agent built in Salesforce need different deployment designs.

The connection steps below focus on an external service. A vendor connector may provide some of these pieces for you. Have the implementation team show which parts it supplies and which remain your responsibility.

Write a one-page workflow contract. For example: answer an approved public account-access question, then create a support Case when the customer requests a person. Specify the allowed knowledge, permitted record changes, identity checks, escalation destination and owner of a failed request. Keep consequential account changes outside the initial pilot until their controls have been demonstrated.

2. Prepare the Salesforce org and integration identity

Start in a sandbox that represents the fields, validation rules and routing used in production. Confirm that the org has the API access and features your design needs. Salesforce Knowledge, routing features and integration-user entitlements depend on the actual edition, licenses and configuration.

Give the integration a dedicated identity so its access and activity can be managed separately. Where supported by your licenses, Salesforce documents the Salesforce Integration user license and the Minimum Access – API Only Integrations profile, with permission sets granting the required access. A permission set license makes permissions available; it does not automatically grant every object permission. See Salesforce’s integration-user setup guidance.

Create a field-level access plan before authorizing writes. Check record sharing as well as object and field permissions. Test the final configuration using the integration identity rather than an administrator account.

This is a starting design to adapt, not a universal permission set. Creating a support Case does not by itself justify permission to edit or delete customer accounts.

3. Configure the supported OAuth connection

For new custom integrations, use Salesforce’s External Client App approach. Salesforce restricted creation of Connected Apps in Spring ‘26 and recommends External Client Apps for new work; existing Connected Apps can continue operating. If your vendor supplies an app, follow its supported installation and authorization process. See the current Salesforce app guidance.

An unattended server integration can use the OAuth client credentials flow when the connector and org support that design. Salesforce’s documented configuration uses External Client Apps Manager, the app’s OAuth settings, client credentials enablement and the required integration-user policy. Use the exact settings approved for your app. Other connectors may require a different supported OAuth flow. See External Client App configuration.

• Use the correct domain. The client credentials flow uses the org’s My Domain URL, including the actual sandbox domain during testing. Its token request does not use the generic login.salesforce.com or test.salesforce.com hosts.

• Choose scopes deliberately. Configure the API scope and any other scopes the supported integration requires in the app. OAuth scope selection and the integration user’s data permissions are separate controls.

• Store credentials in a secret store. Keep secrets and tokens out of browser code, article examples, logs and support transcripts. Assign responsibility for rotation and revocation.

• Implement the right renewal behavior. Client credentials does not issue a refresh token. The integration obtains another access token through that flow; other OAuth flows have their own documented renewal behavior.

These details are documented in Salesforce’s client credentials flow. After authorization, test an allowed operation and a deliberately disallowed one before enabling customer traffic.

4. Map Case fields and choose the routing behavior

Use Salesforce’s Case describe metadata and your administrator’s configuration to identify field API names, required fields, picklists, record types and writability. A label shown in the console may differ from a field’s API name. A value such as New or Web must be valid for the target org and workflow.

Decide where the assistant stores a conversation reference, summary, escalation reason and attempted actions. Use agreed fields or supported linked records. Preserve human-authored notes and define who can change the Case status and owner.

Choose assignment behavior explicitly. Salesforce’s REST Sforce-Auto-Assign header defaults to true when omitted. For creation, use your tested assignment rules or a deliberate ownership design. For later updates, decide whether assignment rules should run again. Setting the header to false controls assignment rules for that request; other record-triggered automation can still run. See the assignment rule header documentation.

If an existing autolaunched Flow is the approved boundary for a business action, Salesforce supports invoking its active version through REST. Retrieve the action’s metadata and use its actual API name and input variables. Have the administrator verify its execution context and required permissions. A successful OAuth connection does not establish that a particular vendor connector can invoke that Flow. See starting a Flow through REST.

5. Connect Salesforce Knowledge with its access rules intact

Define which articles the assistant may use before importing content. A customer-facing assistant and an internal copilot can have different audiences. An article being published, or readable by the integration user, does not establish that every customer may see it.

Salesforce’s Knowledge Articles List resource returns online article summaries visible to the API user. It supports an explicit channel, language and pagination; article detail URLs provide the corresponding content. For a public-channel example, the request can use /services/data/vXX.X/support/knowledgeArticles?channel=Pkb with Accept-Language: en-US. Select a supported API version and a language enabled in your org, and follow the returned pagination and detail links. See Knowledge Articles List.

For a custom Lightning Knowledge query, explicitly select the publication state your retrieval policy allows, such as PublishStatus = 'Online'. Store the stable article identity together with the version, language and source URL. Inspect your actual article schema rather than assuming every org has a universal body field. Salesforce documents these distinctions in its article lifecycle guidance.

Your sync contract should cover new articles, changed versions, translations, archived content, deletions and revoked access. Test how a withdrawn article disappears from the assistant’s answers and agree on the acceptable propagation time. A periodic reconciliation against the authorized source set helps detect documents missed by an incremental feed.

Verify the org’s sharing model. Lightning Knowledge can use standard sharing or data-category-based access; categories are not always the mechanism controlling record access. Preserve the relevant audience restrictions in the assistant’s retrieval layer. See Salesforce Knowledge sharing. For tools that help maintain the source material, see our AI knowledge-base software guide.

6. Work through a Case handoff example

Consider a customer who has followed approved account-recovery instructions and asks for a human. The assistant should record the work already attempted, create or locate the appropriate Case and give the customer an accurate next step.

The following is an illustrative Salesforce REST exchange, not a tested deployment or a specification of Fini’s connector. Replace the placeholders with the verified org URL and selected API version. Use synthetic customer data in your sandbox.

1. Inspect the Case schema. Request GET /services/data/vXX.X/sobjects/Case/describe using the integration identity. Use describe metadata to inspect fields and writability, then confirm required inputs, validation rules and record-type-specific picklist values with the administrator.

2. Create the Case. Send POST /services/data/vXX.X/sobjects/Case to the authenticated org’s instance URL. Use the bearer access token, JSON content type and an explicit assignment-rule header. The table below illustrates the body fields.

3. Keep the returned record ID. Associate it with a stable conversation/action reference in your integration’s delivery record.

4. Read the resulting Case. Retrieve GET /services/data/vXX.X/sobjects/Case/{case_id}. Check its CaseNumber, Status and OwnerId. If routing or writeback uses asynchronous automation, verify that process has completed before treating the immediate response as the final outcome.

5. Check the agent experience. Confirm that the responsible team can see the Case, understand the request and continue from the recorded context. Verify the customer receives the correct acknowledgement.

Include additional required fields from your org. Add a ContactId only after verifying the customer’s authorized record mapping. For later writeback, PATCH /services/data/vXX.X/sobjects/Case/{case_id} updates the intended writable fields; recheck the resulting record and routing. The Salesforce REST API Developer Guide documents record creation, retrieval and updates.

A Case queue can own the work. A live transfer additionally depends on the configured conversation channel, routing and agent availability. If Omni-Channel is part of your design, verify its service-channel, routing, presence and capacity configuration. Test after-hours and full-capacity behavior as well as an available-agent scenario. See Salesforce queue setup.

7. Handle failed requests and duplicate delivery

Give every attempted action a stable reference and record its outcome outside the conversation text. A timeout can leave the sender uncertain even when Salesforce created the Case. Reconcile the original attempt before sending another create request.

A deliberately configured external ID field can support an upsert design. It must be part of your schema and uniqueness policy; Salesforce does not automatically create a conversation-ID field for this workflow. Also protect downstream automation: repeating a field update can repeat a Flow or trigger side effect. These are design considerations in Salesforce’s integration patterns.

Monitor actual org consumption through Sforce-Limit-Info and the REST limits resource. Salesforce can enforce limits with HTTP 403 and REQUEST_LIMIT_EXCEEDED; a retry policy that recognizes only HTTP 429 will miss this case. Use bounded delayed retries for suitable transient failures. See Salesforce API limits and monitoring.

8. Validate the workflow and release a bounded pilot

Define acceptance criteria with the support owner and Salesforce administrator before evaluating the result. The following checklist is a proposed test plan.

• An approved question receives an answer supported by the current source.

• Missing or conflicting information produces the agreed escalation.

• An unauthorized account lookup and an internal-only article remain inaccessible.

• A new Case contains the required context and reaches the intended owner.

• A later update preserves human notes and follows the chosen assignment behavior.

• Duplicate delivery and an uncertain write outcome do not produce unintended repeat work.

• Article withdrawal, expired credentials, validation failures and API pressure follow the recovery plan.

• After-hours handoff gives the customer an accurate acknowledgement and retains ownership.

Start with one channel or intent, a named operator and a way to pause new AI writes. Review answer correctness, Case creation and update success, handoff completeness, repeat contacts, failed actions and API consumption. Check actual records and customer outcomes alongside HTTP success codes.

Document recovery before launch. Pausing the integration or revoking a token does not undo Cases already created or actions already completed. Keep a change journal, reconcile pending work and use deliberate corrective actions where necessary. For cross-system actions, Salesforce discusses this distinction in its agentic integration patterns.

Evaluating a Fini integration with Salesforce

Fini lists Salesforce in its integration catalog and describes OAuth connectivity on its implementation overview. Confirm the supported Salesforce edition, authentication flow, objects and fields, knowledge sources, writeback behavior and handoff destination with the implementation team. Use the sandbox checks above to verify the proposed configuration.

Bring a sample Case, the approved knowledge sources, required field mappings and your acceptance checklist to a Fini implementation discussion. Ask for responsibilities, milestones, licensing and usage assumptions, and ongoing monitoring requirements. Define the launch date around those deliverables and a successful pilot.

Frequently asked questions

Do I need an External Client App for a Salesforce AI integration?

For a new custom inbound integration, Salesforce recommends External Client Apps. A vendor connector may provide its own supported app and authorization process. Existing Connected Apps can continue operating, so confirm the integration’s actual requirements before creating a replacement.

Which Salesforce permissions should the AI integration have?

Grant the integration identity only the object, field and record access required for its approved workflows. Evaluate Case creation and selected updates separately from Contact, Account and Knowledge access. Test with that identity and the org’s sharing rules rather than assuming administrator access represents the production configuration.

Can an AI integration update custom objects or run Salesforce Flows?

Salesforce provides APIs for permitted record operations and invoking active autolaunched Flows. Your connector must support the required operation, and the user and Flow configuration must allow it. Verify the actual object, fields, Flow inputs and execution context in a representative sandbox.

How do we keep internal Knowledge articles out of customer answers?

Define the assistant’s audience and select authorized publication states, channels, languages and records. Preserve the applicable sharing restrictions after export, and test an internal-only article with a customer request. Include revocation and withdrawal in the synchronization checks.

Does creating a Case transfer a conversation to a live agent?

A created Case records work. A live transfer also requires the configured conversation channel, routing and an available recipient. Verify both the agent’s experience and the customer’s acknowledgement, including after-hours and capacity-limited scenarios.

What should happen if Salesforce times out after a Case request?

Record the uncertain outcome and reconcile the original action before retrying a create request. Use a stable action reference and retain returned Salesforce IDs. Configure duplicate protection and downstream automation deliberately so repeated delivery does not repeat the business action.

How long does a Salesforce AI support integration take?

The timeline depends on org access, the selected connector, data readiness, custom fields, routing and acceptance tests. Separate authorization, configuration, sandbox validation and pilot release into milestones with named owners. A successful connection alone does not establish production readiness.