MoneyFlock may earn a commission if you subscribe to a Lovable Business plan through links in this article, at no extra cost to you. TJ Alam is a certified Lovable Expert.
On 15 September 2026, Lovable published an announcement with Salesforce on the cover. The headline promise is that the apps your team builds can read and write the records your company already keeps in Salesforce, and that they can run where the team already works. For anyone running a client book, a lending desk, a support queue or a revenue operation, that is a bigger claim than it first sounds.
It is also a claim worth reading carefully, because most of what the post describes is not one feature. It is four separate paths, shipped at four different times, with different plan requirements and very different data implications. This article separates them, dates each one, and works through the part that matters most for regulated teams: which version of the connection lets a colleague see a client record they should not see.
Every price and capability below was re-checked on 28 September 2026 against Lovable's own pages. Where a claim comes only from the announcement and is not yet in the documentation, this article says so.
What Lovable and Salesforce actually announced
The post is dated 15 September 2026 and sits under Announcements on Lovable's blog. It opens with a scale figure: more than 70 million projects created with Lovable since November 2024. The argument it makes is that many of those projects already sit next to a Salesforce org, and that until recently reaching into that org meant a ticket to IT or an outside consultant.
The hinge of the announcement is a Salesforce product, not a Lovable one. Headless 360 is Salesforce exposing its capabilities through APIs and MCP servers, with Salesforce identity, permissions and compliance still in charge. Lovable's part is to build against it.
Lan Roche, Head of Global Partnerships at Lovable, frames the boundary in the post in six words that should shape every build decision that follows: "Salesforce remains the system of record". Tyler Carlson, SVP and Head of Product for AgentExchange and Ecosystem at Salesforce, describes the same arrangement from the other side, as builders connecting experiences to Salesforce data and business context.
What is new, and what quietly is not
Three of the four paths in the announcement had already shipped, and the changelog dates them. That is not a criticism, but it changes how you should plan around them, because a feature that has been live for months is a safer bet than one announced last week.
| Path | What it does | First appeared | Status on 28 Sep 2026 |
|---|---|---|---|
| Salesforce app connector | Query and update Accounts, Contacts, Leads, Cases, Opportunities via SOQL and REST | 1 June 2026 changelog | Documented in full |
| Lovable in Slack | Mention @Lovable in a channel or DM to build and update apps | 26 August 2026 changelog | Documented, all plans since 1 Sep |
| Apps installed into Slack as agents | Publish your app into a Slack workspace as its own bot | 26 August 2026 changelog | Documented |
| Headless 360 and Publish to Salesforce | Apps that run inside the Salesforce org as a page | 15 September 2026 announcement | Announcement only, no docs page yet |
That last row is the finding a reader will not get from a no-code roundup. As of 28 September 2026, the phrases Headless 360 and Publish to Salesforce appear nowhere in Lovable's documentation index or its changelog, which is current to 25 September. The announcement says everything in it is available today. The documentation has not caught up, so treat the in-org publishing path as new and lightly evidenced, and the connector path as the mature one.
Lovable Salesforce integration, path by path
1. The app connector: the workhorse
This is the one with real documentation behind it. A workspace admin or owner connects a Salesforce org from the Connectors area, and from then on any project in that workspace can be linked to it. Apps can then run SOQL queries against standard objects, display and filter records, and create or update them through the Salesforce REST API.
Lovable's own worked examples give a fair picture of the intended scope: a support case dashboard grouped by priority, an account health tracker that counts contacts and open opportunities, a lead pipeline board by stage and owner, a searchable contact directory, a self-service case lookup portal, and a weekly closed-opportunity report by owner.
Read that list again with a finance hat on. Every one of those is a read-mostly reporting surface over records someone else owns. That is exactly the shape of tool a revenue operations or client-service team asks for and rarely gets prioritised, and it is the honest sweet spot here.
2. Lovable in Slack, and Slack Code
Mentioning the assistant in a Slack channel or a direct message lets someone describe the app they want in plain language, and the result comes back in the thread. Work started in Slack continues in Lovable under the same workspace permissions, and the messages draw on the workspace's credits, counted against the person who sent them. That last detail matters for budgeting: a busy channel is a spending surface.
Slack Code is the multi-person version. When more than one person needs to shape a build, it opens in a code channel so operations, finance and the person who asked can iterate on one shared version. The announcement credits Slack with building that surface to bring tools like Lovable in.
3. Agents your team installs into Slack
An app you built can be installed into a Slack workspace as its own bot, under its own name, without a Slack developer account or keys copied between the two systems. An admin authorises the workspace once. After that the app answers when mentioned, with whatever behaviour you gave it.
For a finance team the obvious use is an approval or lookup bot that answers in the channel where the work already happens. The obvious risk is the same one: a bot that can read client records sitting in a channel whose membership changes without anyone telling you.
4. Publish to Salesforce
This is the genuinely new capability and also the most limited. Choosing Publish to Salesforce when you connect builds the app to run inside your org as a page, reading live data as whoever opens it. The announcement is explicit that this covers read-only apps today, things like dashboards and pipeline views. Anything that writes back runs on Lovable through the connector instead.
If you are planning a build around this, plan for read-only and treat write-back in the org as a maybe. The distinction is in the announcement and nowhere else, so there is no documentation page to hold it to.
The distinction that decides whether this is safe for client records
Here is the part that a general technology blog will skip and a compliance reviewer will ask about first. Lovable has two different connector models, and choosing the wrong one is how a perfectly well-built app ends up showing every visitor the same person's book of business.
| Question | Standard app connector | App user connector |
|---|---|---|
| Whose Salesforce account | One account, connected once | Each end user's own account |
| Who authorises | You, or a workspace admin | Every user, the first time they use it |
| Data the app can see | That single account's data, shared by all visitors | Only the signed-in user's data, within the scopes they granted |
| Credentials | Stored once, reused for every request | Stored per user, isolated from each other |
| Right for | One company inbox, one shared warehouse query | Client records, per-user dashboards, anything with sharing rules |
The announcement's line that each person connects their own Salesforce account, so everyone sees only what your sharing rules allow, describes the second column. It is not the default you get by wiring up the standard connector and shipping.
The mechanics behind the per-user model are reassuring if you have to document them. You register one OAuth application with Salesforce, in this case an External Client App, and configure it once for the workspace. Each of your users then goes through Salesforce's own consent screen. Lovable stores their tokens encrypted in a connector gateway, and by its own documentation those tokens are not visible in project settings, not visible to workspace admins, and not visible to Lovable while it builds the app.
For a team that has to answer where client credentials live, that is a usable answer. It is also the reason to spend an hour on this choice rather than five minutes. If you want the wider picture on how Lovable handles financial data, the companion piece on row-level security and key handling covers the ground underneath this one.
What this costs, and who pays for what
There are two meters running, and only one of them is Lovable's.
Salesforce charges the API traffic, not Lovable
Lovable's connector page states it plainly: every API request made through the connector counts against your Salesforce org's API limits, and billing and quota are handled directly by Salesforce. A dashboard that refreshes aggressively for forty people is a Salesforce capacity question before it is a Lovable one. Budget it against the org's limits, and design the refresh interval on purpose rather than by default.
Lovable charges the building and the running
Plan prices were read logged out on 28 September 2026 and are unchanged from the readings taken through September. Free is $0. Pro starts at $25 a month for 100 monthly credits. Business starts at $50 a month for 100 monthly credits and climbs the same credit ladder to $4,300 at 10,000 credits. Enterprise is quoted as a platform fee.
Unlimited users are included on Pro, Business and Enterprise, which is unusual enough to be worth saying out loud: the cost driver is credits, not seats. For the standing explanation of how credits are consumed, the credits article in this series works through what an MVP actually costs.
What sits behind the Business plan
Three of the controls that make a Salesforce-backed app defensible are plan-dependent, and they all point the same way.
- Workspace identity reuse. For apps published to your workspace, Business and Enterprise plans let the app recognise the signed-in member directly, so you do not have to build and maintain your own sign-in layer just to tell users apart. On lower plans you add authentication yourself.
- Who may configure a connector. On Free and Pro, any workspace member with an editor role or higher can configure a connector client. On Business and Enterprise, admins and owners choose who can, per connector. For a CRM connection that is the difference between a control and a convention.
- Offline access defaults. On Free and Pro, offline access is always enabled. On Business and Enterprise it is off by default and you enable it deliberately under advanced settings. Note the one-way door: once the client is linked to a project you can no longer disable it, and unlinking from every project is the only way back.
Business also carries the team workspace, role-based access, internal publish, single sign-on and the security centre, which is the set most compliance reviews ask about. If you are weighing the jump, the pricing comparison and the team workspace walkthrough in this series both go deeper than a feature list.
If you want this configured properly the first time, you can start a Business plan through this link or ask a certified Lovable Expert to scope the connection and the permission model with you.
Setting up the connection, and the parts that trip people
The mechanics are ordinary OAuth, with a few Salesforce-specific traps.
- Salesforce no longer allows new Connected Apps. You create an External Client App instead. Existing connections built on a Connected App keep working and need no migration.
- The callback URL must match exactly. Lovable's connector documentation gives the current value, and it notes that setups created before 8 July 2026 may have copied an incorrect one from an earlier version of the page. If authorisation fails with a redirect error, check this first.
- Two OAuth scopes are required: managing user data via APIs, and performing requests at any time, which is the refresh token and offline access pair.
- The environment field is not cosmetic. Production covers production orgs and Developer Edition. Sandbox is only for a genuine test.salesforce.com sandbox. Picking the wrong one produces authentication failures that look like credential problems.
- A connection is private to its creator by default. Sharing it with the workspace is a deliberate step, and it is the step to document.
- You can hold several connections at once, which is how you keep a sandbox org and a production org separate rather than pointing one connection at whichever you are testing that week.
Limits worth knowing before you promise anything
Lovable lists the connector's limits on the same page, and two of them will decide whether a project is viable.
| Limit | What it means in practice |
|---|---|
| No Bulk API | Large migrations and nightly full-object syncs are out of scope. Query what a screen needs. |
| No Streaming API | No push updates. A live-feeling view is a polling view, and polling spends your org's API quota. |
| Orgs outside *.salesforce.com are unreachable | A custom-hosted or non-standard domain will not connect. |
| One connection equals one org | Projects linked to a connection all point at that same org. |
| Revocation is silent until it is not | If the External Client App is deleted or the authorising user's permissions change, calls fail until someone reconnects in Lovable. |
| Deleting a connection is permanent | It strips credentials from every linked project and features stop working until a new connection is added. |
The streaming limitation is the one to say out loud in a planning meeting. Teams ask for a live pipeline board and hear yes, then discover that live means a refresh timer, and that the refresh timer has a bill attached to the Salesforce org. Set that expectation in week one.
A realistic first build for a finance or client-facing team
If you want a project that proves the pattern without risking anything, the shape below works and stays inside every limit above.
- Pick a read-only view first. A renewals board, an open-cases queue by owner, or an account summary that stitches Salesforce fields to something Salesforce does not hold.
- Use the per-user connector, not the shared one, the moment the records belong to individual people rather than the company as a whole.
- Decide the refresh interval explicitly and write the number down, because that number is your API consumption.
- Keep the write path out of version one. Reading is reversible. Writing to a system of record is not.
- Publish internally first. On Business that means an internal publish inside the workspace, which keeps the app off the public web while it is being reviewed.
- Only then consider an agent in Slack, once you know exactly which records the app can reach and who is in the channel.
The same discipline applies to any connector you add next to it. The overview of Lovable connectors for a finance stack maps what else is available, and the agency piece covers running this pattern for clients rather than for your own team.
Where this leaves Salesforce
It is worth being blunt about the thing the announcement is careful to say and the coverage tends to lose. Nothing here replaces Salesforce. The records stay in the org, the sharing rules stay in the org, the identity stays in the org, and the audit trail stays in the org. What changes is who can build the twelfth view of that data, and how long it takes.
That is a real change, and it is a modest one. It moves a class of internal tool from a quarterly roadmap conversation to an afternoon. It does not move governance anywhere, and any pitch that suggests it does should be read sceptically. If you are still deciding whether the platform earns a place in your stack at all, the full review weighs it end to end, and the fintech comparison sets it against the alternatives.
For teams that decide it does earn a place, the plan that carries the governance controls described above is Business, and you can start one through the partner link. If you would rather have the connection, the permission model and the first dashboard scoped by someone who has shipped this pattern, TJ takes that work through the Lovable partner directory.
Frequently asked questions
Does the Lovable Salesforce integration work on the free plan?
The connector itself is available across plans, and on Free and Pro any member with an editor role or higher can configure a client. What Free and Pro do not give you is workspace identity reuse, per-connector control over who may configure connections, or the off-by-default offline access posture. For shared client records, those are the reasons teams move to Business.
Can an app built with Lovable write back to Salesforce?
Yes, through the connector, using the Salesforce REST API for creates and updates. The newer path that runs an app inside the Salesforce org as a page is read-only today, per the 15 September announcement. Write-back apps run on Lovable.
Do these API calls cost Lovable credits or Salesforce quota?
Both meters run. Building and running the app spends Lovable credits. Every API request to the org counts against your Salesforce API limits, billed and quota-managed by Salesforce directly.
Can each user see only their own Salesforce records?
Yes, if you use an app user connector so each person authorises with their own account. With a standard connector every visitor sees the one connected account's data. This is the single most important configuration decision in the whole integration.
Is Headless 360 documented anywhere?
Not as of 28 September 2026. It appears in the 15 September announcement on Lovable's blog and not in the documentation index or the changelog, which is current to 25 September. Salesforce's own material is the place to verify the Headless 360 side.
What happens if someone revokes the connection in Salesforce?
Calls fail. Deleting the External Client App, or a change to the authorising user's permissions, breaks the integration until someone reconnects it from the Lovable side.
References
- Lovable, Lovable + Salesforce announcement, published 15 September 2026, read 28 September 2026
- Lovable documentation, Connect your app to Salesforce, read 28 September 2026
- Lovable documentation, App user connectors, read 28 September 2026
- Lovable documentation, App and chat connectors, read 28 September 2026
- Lovable changelog, entries dated 23 February, 1 June, 13 July, 26 August, 1 September and 25 September 2026, read 28 September 2026
- Lovable pricing page, plan cards and credit ladders read logged out on 28 September 2026
About the Author
TJ Alam is a certified Lovable Expert (Website Builder track) and the founder of Digi Flock Enterprises. He built tjalam.com and cyberdance.in on Lovable and works with clients on internal tools, portals, dashboards and CRM-connected applications. You can find him on the Lovable partner directory.
MoneyFlock may earn a commission if you subscribe to a Lovable Business plan through links in this article, at no extra cost to you. TJ Alam is a certified Lovable Expert.