# Integrating Convergence.ai with Salesforce

Convergence.ai builds agents that operate interfaces. If the system has an API, use the API. The failure is a click on a screen that changed.

**Published:** 2026-07-16
**Canonical:** https://synconai.com/integrating-convergence-with-salesforce
**Author:** SynconAI Architecture Team

## In short

Integrating Convergence.ai with Salesforce means naming the system that must change, the record the change must land on, and the failure when the agent clicks a screen that has changed. The acquisition completed on 11 June 2025. These agents operate interfaces. If the system has an API, use the API. Do not design screen-clicking as the default integration.

## Sources

- **Salesforce Signs Definitive Agreement to Acquire Convergence.ai** (retrieved 2025-06-11)
  https://www.salesforce.com/news/stories/salesforce-signs-definitive-agreement-to-acquire-convergence-ai/
  > Salesforce completed its acquisition of Convergence on June 11, 2025.

## What to take away

- The system is the one you are changing. If it has an API, the integration uses the API.
- The object is the record that must change. The failure is a click on a screen that changed.
- Do not design screen-clicking as the default. Salesforce completed the acquisition on 11 June 2025.
- A diagram of a cursor and a screenshot, with no record and no failure, is a poster.

## The guide

An architect draws a person-shaped agent, a screenshot, and a series of dots where a mouse would go. The dots are the design. Nobody has asked whether the system has an API. Nobody has named the record that should change if the dots miss. The drawing is a poster. An integration names the system, the object, and the failure when the call does not land. Convergence.ai builds agents that operate interfaces. That capability is real. It is not the default way to integrate. If there is an API, use the API. The failure of the click path is a click on a screen that changed.

Salesforce completed the acquisition on 11 June 2025. This page will not describe a button the announcement did not show. It will not name an API the source does not name. "The API, if the system has one" is the whole of the instruction. Your engineers know whether a given system has one. The diagram starts from their answer, not from a screenshot. The only sentence this page quotes from the announcement is the completion line. "Salesforce completed its acquisition of Convergence on June 11, 2025."

## The system is the one behind the screen

Every screen belongs to a system. The system might be Salesforce. It might be a tool you run beside it. The integration is with that system, not with the pixels. Ask one question first. Does this system expose an API you are allowed to call. If the answer is yes, the integration is the API. Screen-clicking is a fallback you must justify, not a starting style.

Write the justification if you truly have no API. The vendor does not offer one. The one they offer cannot do this action. Counsel has forbidden it. A missing login for a project account is not a justification. That is a provisioning task. Do the task. Then use the API.

An agent that operates an interface is still software with a user. Name the user. Name what that user may see. A user that can click anything an administrator can click will eventually click the wrong thing. Least privilege is the same rule you would apply to an API user. The presence of a mouse does not relax it.

[Convergence.ai and the interface quote](/convergence-ai-agentforce) is where you list the applications and the clicks that stay with a person. This page adds the order of design: API first. [What happened to Convergence.ai](/what-happened-to-convergence) dates the close. It does not draw a screen, and this page will not invent one either.

## The object is the record, not the click

The call lands when the record changes in the way you named. A field updated. A row created. A status moved. The click, if you had to click, is only a means. A means that does not change the record is a performance. Open the record after the run, as a user who does the job. If they cannot see the change, the agent did not integrate. It navigated.

Write the before and after. Before: this status. After: that status. One field, one record id. A script that "completes the screen" with no before and after will be accepted because the cursor stopped. Stopping is not landing.

If you use an API, the same before and after applies. The response code is not the landing. The record is the landing. Read it back. An API that returns success and writes nothing is the same failure as a click that hits a button which no longer saves.

Idempotency matters more when a screen is slow. The agent may click twice because the first click looked stuck. Two clicks can create two records. The API path has the same risk if you retry blindly. Name the key that makes a second attempt safe. If you cannot, do not automate the retry.

## The failure is a screen that changed

A click path records positions, labels, or a sequence of controls. A release moves the button. The label changes. A modal appears that the recording did not include. The agent clicks where the button was. Something else happens, or nothing happens. That is the failure: a click on a screen that changed.

You will not always know the screen changed. The agent's log may say the step completed because a control with a similar name accepted the click. The record will show a different field, or no field. This is why the test reads the record and not the log. The log describes the interface. The record describes the business.

Salesforce screens change with releases, with page layouts, and with a profile. A path recorded as an administrator will not see what a seller sees. A path recorded in a sandbox with different layouts will not survive production. If you must click, record the path against the profile and the layout you will run, and accept that a layout edit is a breaking change. Put that sentence in the runbook. A layout edit is now an integration release.

The API fails differently. A contract change is visible in a version or a fault you can alert on. A screen change is visible only when someone watches. Prefer the failure you can alert on. That preference is the reason the API is the default. Screen-clicking remains available for the system that truly has no API. It does not remain the pattern you copy onto systems that do.

## What the diagram has to show

System: the application, and whether it has an API. Object: the record and the field. Failure: a click on a screen that changed, if and only if you are not using an API. If you are using an API, the failure to draw is a write that does not show on the record. You may not invent the API's name. You may not paste a screenshot as the specification. You may not add a price or a cap.

| Name on the diagram | What you write | A poster instead |
| --- | --- | --- |
| System | The application, and API or no API | A screenshot with dots |
| Object | The record and the field that must change | The cursor stopped |
| Failure | A click on a screen that changed, or a write the record does not show | A demo video |
| Default | API when one exists. Clicking is the exception | Clicking drawn first |
| Out of diagram | Invented API name, connector brand, price, cap | A logo on the mouse |

Read the first box. If it is a picture of a screen, start again. If it is a system with a yes or no beside "API", you can continue.

## What you refuse to invent

An API name that sounds plausible will send a developer to the wrong document. Say "the API this system documents" or "no API, and here is who confirmed that". Confirmation is an email from the owner of that system, not a guess from a workshop.

A connector name is the same temptation. Convergence.ai is not, on this page, a connector brand you can drop between two logos. It is a capability to operate an interface when you have already decided the API does not exist. Draw that decision. Do not draw a branded pipe.

A current screen is the thing that will change. Using it as the contract guarantees the failure. Describe the record. Let the screen be an implementation detail with a known expiry.

No price and no daily cap. How many runs a day you allow is an operational limit you set, because a clicking agent can do harm quickly. Set it as your control. Do not attribute it to the announcement.

Keep a person on irreversible steps. Sending a customer email, moving money, deleting a record. The agent may prepare the change. A person confirms it until you have evidence the path is dull. Dull means the record matched the before and after for a period you choose. A week of watched runs is a reasonable start. It is your choice, not a figure from the source.

## How you test that the call landed

Pick one action. Prefer the API version of that action even if a demo showed clicks. Call it. Read the record. Change nothing else. Then change the screen on purpose in a sandbox: rename the button, or move it. If your design uses the API, the test should still pass. If your design uses clicks, the test should fail safely. Safe means the record did not take a wrong update. A click that updates the wrong field is a failed safety test. Stop.

If you have no API, run the click path as the user it will use in production, on the layout that user has. Then have an admin edit the layout the way an admin will edit it next month. Confirm the run stops and tells a person. A run that continues after the layout edit is the failure, live.

Do not accept a video as the test result. A video shows a screen that existed during the recording. The record, queried after the run, is the result.

::: warn
A click on a screen that changed is the failure. If the system has an API, use the API. Do not design screen-clicking as the default integration. Do not invent an API name, a connector, a price, or a current screen as the contract.
:::

Add a second action only after the first reads back correctly, including the day the screen moves. A library of click recordings is a library of future failures. A short list of API calls, each tied to a field, is an integration you can keep.

A partner who opens with a tour of clicks has skipped the question. Ask whether the system has an API. If they do not know, the design has not started. The implementation page can price the applications and the human steps. This page only fixes the order: API, then record, and a click only when the API is truly absent.

## When a click is the only path

If the system owner has confirmed there is no API, write that confirmation down and keep the click path short. One screen. One action. One record. The agent signs in as the user you named. It does not wander into setup, reports, or a second application because a menu looked related. A second application is a second system, and it gets its own question about an API.

Record the labels you depend on, not a pixel position. A label still breaks when the wording changes, and that break is the failure you want: visible, and safe. A pixel position breaks when the window is a different size, and it may click something live. Prefer the break you can explain. After a break, a person finishes the action. The agent does not guess the new label.

Schedule a check on the week of a release for that system. Someone watches one run. They read the record. They sign that the screen still matches the path. If nobody is available that week, the path stays off. An unattended click path over a release weekend is how the wrong field changes while the log says complete.

Salesforce is the usual system that already has an API. Do not click through a record page to update a field you can set directly. The screen will change with a layout or a permission. The field update will not. Reserve the interface agent for the system that truly has nothing else. That restraint is the integration. A catalogue of recordings is not.


## Questions

### What system does a Convergence.ai Salesforce integration have to name?

The application you need to change, and whether it has an API you are allowed to call. The acquisition completed on 11 June 2025. Convergence.ai builds agents that operate interfaces. That fact does not make clicking the default.

### What should the integration land on?

The record and the field you named, read back after the run. A cursor that stopped, a video, or a success message is not the landing. If the record is unchanged, the call did not land.

### What fails when the agent clicks a screen that changed?

The control moved, the label changed, or a layout differs by profile. The click hits the wrong thing or nothing. The record then shows the wrong update or no update. Prefer an API so a screen release is not a breaking change. Use clicks only when there is no API.

### Does this page name the API or a connector?

No. The cited page does not name an API, a connector, a current screen, a price, or a daily cap. Say whether an API exists, in the words of the system owner. Do not coin a name to fill the box.

### Where should we read scope and ownership for Convergence.ai?

List the applications and the steps that stay with a person on the implementation page. Read the completion date and ownership on the what-happened page. This page is the design order: API first, record as proof, click only as the exception.

---

SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Agentforce consulting (https://synconai.com/salesforce-agentforce-consulting).