Every LMS vendor now says it “integrates with Salesforce.” Almost none of them run inside it. The difference sounds like vocabulary until the first quarter of production, when it turns into sync failures, duplicate users and a reporting gap nobody owns.
This article is part of the complete guide to running an LMS inside Salesforce; its cost annex is the itemized bill of syncing.
“Integrated” means two systems agreeing to disagree
An integrated LMS keeps its own database of users, its own permission model and its own definition of a completion. A connector then reconciles that database with yours, on a schedule. The connector is the product you actually operate, and it is the part no vendor demos.
Three failure modes follow, and they are not edge cases:
- Identity drift. A user is deactivated in Salesforce on Friday and keeps learner access until the next sync. Your offboarding process is now only as good as a cron job.
- Permission divergence. Sharing rules, role hierarchy and field-level security exist on one side only. The LMS re-implements a simplified copy, and the copy is always the weaker one.
- Reporting that stops at the border. You can report on completions, and you can report on pipeline, but joining the two means an export, a spreadsheet and a person.
What changes when a completion is a Salesforce record
A native LMS ships as a managed package. Courses, enrollments, attempts and certifications are custom objects in your org. That single architectural fact removes most of the operating cost, because everything Salesforce already does starts working on learning data with no extra build.
- Reports and dashboards, including joined reports that put completions next to won opportunities.
- Flows that enroll a user when a stage, a role or a product changes, built by your admin, not by an integrator.
- Sharing rules and profiles that govern who sees which course, with no second access matrix to maintain.
- Experience Cloud for partners and customers, on the licenses you already own.
How those records get written at runtime is covered in the SCORM in Salesforce guide, and what your admins can build on top of them, from day-one onboarding paths to completion-driven certification updates, has its own guides. The point here is simpler: all of it exists because the data is in the org.
The line item nobody puts in the business case
Compare two three-year plans for a 500-learner deployment. The license prices can be identical; the difference sits entirely in the work around them.
Integrated LMS, cost beyond licenses
| Integration build (middleware, mapping, testing) | 1 – 3 months |
| Connector licensing & maintenance | annual |
| Re-testing after each Salesforce release | 3× / year |
| Second security review & DPA | per vendor |
| Manual reporting to join learning and CRM | ongoing |
| Native equivalent | none of the above |
None of these lines appear on a pricing page, and all of them appear on your team’s calendar.
Native vs integrated, at a glance
Every argument in this article reduces to one architectural difference, and it shows up on every row of a comparison:
| Integrated LMS | Native LMS | |
|---|---|---|
| Learning data | In the vendor’s cloud; synced copies in your org | Records in your org; the report reads the original |
| User directory | A second store, reconciled by a connector | Your existing Users and Contacts |
| Permissions | A simplified re-implementation | The sharing rules and profiles you already run |
| Automation | Webhooks, middleware, API calls | Flow on training records |
| Reporting | Exports, spreadsheets, BI joins | Standard reports and dashboards, joined with CRM data |
| Partners & customers | A separate learner portal | Experience Cloud, on the org you already run |
| When the connector fails | Sync gaps, stale data, a debugging project | There is no connector |
Why buyers actually choose native: two patterns from real evaluations
The architecture argument stays abstract until you hear how it sounds inside a real selection process. Two motivations come back, almost word for word, in the evaluations we see.
“Our people are already in Salesforce, and we are not duplicating them.” The audiences to train, employees, customers, partners, already exist as Users and Contacts, with roles, permissions and history. Standing up a second user store just to deliver training is the part these teams refuse before the demo even starts. And the pattern holds when the employee master lives elsewhere: one organization ran its HR data in SAP SuccessFactors, but opening an HR suite to customers and resellers was never on the table. Salesforce was where those external audiences already had an access path, so Salesforce is where their learning went.
“We have our own learning workflows, and our own Salesforce architects.” Mature teams don’t want a vendor’s idea of a training process; their learning logic follows their business processes. What they ask for is the ability to implement those workflows themselves, on the platform their architects already master: Flows on training records, custom objects, their own reports. An external LMS offers them a proprietary rule engine to learn instead. A native one hands their team the same tools they use for everything else, and gets out of the way.
Three questions that separate native from integrated
Ask any vendor these, in writing, before the demo:
- Where does a completion live? If the answer is “in our platform, then synced”, it is integrated.
- Can a standard Salesforce report read it with no connector running? Native data survives the connector being switched off, because there is none.
- Which personal learner data leaves the org? For a managed package the answer is none, which is what a Swiss or German procurement team is actually asking.
If you’re formalizing the evaluation, our LMS RFP kit expands these three into 47 written questions, with the vendor answers that should reassure you and the ones that should worry you.
Native is a constraint, and that is the point
Running inside Salesforce means inheriting its limits as well as its strengths. In exchange you inherit its security model, its audit trail, its release process and its reporting engine, none of which you have to rebuild or defend to a security committee.
For teams already standardized on Salesforce, that trade is rarely close.
FAQ
What does “Salesforce-native LMS” actually mean?
It means the LMS ships as a managed package installed in your org: courses, enrollments, completions and certifications are Salesforce objects and records, and no learner data lives on the vendor’s servers. If any part of the learner database sits outside your org and gets synchronized in, the product is integrated, not native, whatever the marketing says.
Does an integrated LMS sync users with Salesforce?
Yes, and that sync is the core of the operating cost: a connector maps your Users and Contacts to the LMS’s own user store on a schedule. Identity drift between the two directories, deactivated users keeping access until the next run, is the most common failure mode, and it’s your admin who owns it.
Can you report on external LMS data inside Salesforce?
Only on the copy the connector pushed in, as of its last successful run. Joining that copy to pipeline or cases works until the sync breaks or lags, and someone has to notice. With native records there is no copy: standard reports and dashboards read the original, and training progress sits next to revenue without an export.
Is every LMS on the AppExchange native?
No. The AppExchange lists both managed packages that run in your org and connector apps that link to an external platform. The listing badge doesn’t settle the question; where the learner data lives does. The three questions above, asked in writing, settle it quickly.
See it in your own org
Thirty minutes on your use case, in a live Salesforce environment. No connector to install.
Book a demoAbout the author. Brice Mbouani is the founder of Daniwoo and a Salesforce engineer. He designed and built the native learning platform described in this article, which runs in production Salesforce orgs at organizations including ENG Group. The evaluation patterns recounted here are from his own conversations with buyers.
