Salesforce OEM

In the Salesforce ecosystem, OEM (Original Equipment Manufacturer) is the business model through which an ISV (independent software vendor) embeds the platform inside its own product and resells it as a solution under its own brand, even to customers that never bought Salesforce. It is formally known as Lightning Platform Embedded or OEM Embedded.

The analogy is the same as in the hardware industry: the software that comes preinstalled on a camera or a computer is "OEM" because the manufacturer integrates it and sells it under its brand. In Salesforce, an ISV with an OEM contract embeds platform licenses in its application, so the end customer runs the product without buying Salesforce separately and, often, without knowing the platform is running underneath.

It is a model designed for those who build products on the platform, not for those who only use it. That is why it comes up often in the architecture and licensing conversations that precede any Salesforce development project: it defines who you can sell to, which objects are available and how revenue is shared.

How the OEM model works

An ISV with an OEM contract embeds Salesforce platform licenses inside its application, so the end customer uses the product without buying Salesforce separately and often without knowing there is Salesforce underneath. Four pieces define the model:

• Embedded license: the ISV includes the platform license inside its product.
• Sales scope: it can sell to new customers, even outside the Salesforce ecosystem.
• Revenue share: the ISV pays Salesforce a percentage of what it sells. In OEM Embedded, since the platform license is included, Salesforce has a higher cost and sets pricing guidelines for those licenses (Trailhead); the details are agreed within the partner program.
• No core CRM objects: OEM apps do not access standard objects such as Leads, Opportunities or Cases; they are built on custom objects.

Why it matters to a company in Latin America

For a company evaluating a solution built on Salesforce, understanding the OEM model clarifies what it is buying: an application with the robustness, security and infrastructure of the platform underneath, but with the ISV's brand, pricing and support. It is not a minor detail when auditing risk, because scalability and security controls are Salesforce's, while the roadmap and customer service depend on the product vendor. A firsthand angle: EGA Futura, the company Vantegrate grew out of, operates under an OEM contract with Salesforce, providing orgs with its ERP already installed.

OEM vs ISVforce

Both are paths within the AppExchange partner program, but they target different audiences:

The point people confuse most: in OEM the customer does not buy Salesforce separately and sometimes does not even know it runs underneath, while in ISVforce the app extends an org the customer already has. The Security Review is mandatory in both models, so choosing OEM does not avoid it.

In practice

A business management software company in Buenos Aires that wants to sell its ERP to SMBs that have never used Salesforce can sign an OEM contract: it embeds the platform inside its product, and the customer installs the ERP, receives an org with the application already set up and runs on Salesforce infrastructure without buying licenses separately. For that customer it is "that company's ERP"; the platform runs underneath, with its security and scalability. That ability to build your own product on Salesforce is the territory of Salesforce development.

Common mistakes

• Confusing OEM with ISVforce: the target audience, object access and revenue share all change.
• Assuming an OEM app uses the standard CRM objects: it does not; it relies on custom objects.
• Believing the end customer buys Salesforce separately: in OEM the license is embedded.
• Thinking the OEM model skips the Security Review: it does not.