You want to build an app. You have the vision and you have started mapping out the components, object model – and even the fields, data types, and the ‘look and feel’.
The Salesforce platform is growing year on year, making it an attractive option for app entrepreneurs. The AppExchange, Salesforce’s app marketplace, lists over 7000 apps and certified consulting organizations. In fact, 90% of Fortune 500 companies use an AppExchange product, and 91% of Salesforce customers have at least one install.
Salesforce’s annual Investor Relations deck predicts the potential growth (total addressable market) in different areas of their portfolio until 2026. To put this into perspective, by 2026, ecosystem revenues (i.e. earned by the partner ecosystem) are predicted to grow at least six times larger than Salesforce itself. In crude numbers, the ecosystem will earn $6.19 for every dollar Salesforce makes.
When we think of ‘apps on the Salesforce platform’, what comes to mind is a typical AppExchange install that works in conjunction with an existing Salesforce license the customer company had purchased. In other words, no license equals no ability to use the packaged app. However, you may not know that there is another model – or ‘flavor’ – of ISV relationship available, which allows you to also market and sell to non-Salesforce customers.
This guide dives into the differences between the two models of ISV relationships – OEM and ISVForce. It explains how the Salesforce OEM process works, including the license types, license provisioning, the License Management App (LMA), and many more.
Why Build Your App on the Salesforce Platform?
Salesforce is a great platform to build a business on. You’ll find there are features and technologies that partners need to build, distribute, sell, and support their solutions that you also can take advantage of. Here’s why you should build your app on the Salesforce platform:
- Salesforce provides out-of-the-box advanced capabilities, leading to rapid development. These include investment into modern tooling (e.g. SFDX, Flow, App Builder, and LWCs), so that Salesforce is in-line with modern web standards. In fact, Salesforce is contributing to the future of web development with their involvement with the ECMAScript technical committee [TC39]. An IDC report found that using Salesforce resulted in a 57% faster development lifecycle and a 545% five-year ROI.
- Salesforce offers complementary support. ISV Technology Advisors are dedicated to supporting partners through every stage, including workshops and go-to market plans.
- Trialforce: Give your customers access to trial your app, while you maintain visibility and control.
- License Management App (LMA): An interface to configure the seats/licenses for your application on your customer’s behalf.
- Subscriber Console: It offers ongoing support afterward, including logging into your customers’ orgs when permission is granted.
- The AppExchange: The app marketplace increases your app’s visibility among Salesforce customers.
ISV Partnerships: OEM vs. ISVForce
There are two models – or ‘flavors’ – of ISV relationships available to partners in order to distribute their apps (OEM and ISVForce).
- ISVForce: Allows partners to build packages on the Salesforce platform, which can be installed into Salesforce environments. These enhance existing processes, integrate with external systems, or deliver entirely new functionality natively on the platform.
- OEM: Works just like ISVForce (i.e. build packages on the Salesforce platform, etc.), except that OEM partners can also market and sell to non-Salesforce customers. In other words, they can deliver their application in combination with an embedded Salesforce license – regardless of whether their customer is an existing Salesforce customer.
| ISVForce | OEM | |
|---|---|---|
| Revenue share % with Salesforce | 15% of net revenue | 25% of net revenue |
| Dependency on customer Salesforce licenses (e.g. Sales Cloud, Financial Services Cloud) | Dependency on Salesforce licenses (i.e. having the listed licenses is a prerequisite for using the app). | No dependency on Salesforce licenses (i.e. not a prerequisite for the partner’s customer). |
| Powered by which licenses? | The customer’s existing Salesforce licenses. | Embedded platform licenses provided by the ISV. Grants access to the following platform objects & capabilities. |
Here is how the sales process differs from the customer’s perspective – whether they are an existing Salesforce customer, or are completely new to the Salesforce platform:
Salesforce OEM Partnership
As mentioned previously – when we think of ‘apps on the Salesforce platform’, what comes to mind is a typical AppExchange install that works in conjunction with an existing Salesforce license the customer company had purchased. Now, let’s dig deeper into understanding the broader opportunities that an OEM partnership can offer.
So what does OEM stand for? The answer is Original Equipment Manufacturers – which may sound strange when we consider that we’re referring to all cloud-based technology. However, it’s a general term, and in this context, it describes that the app is associated with a license supplied by the company that runs the infrastructure (i.e. the Salesforce platform – the ‘original equipment’).
OEM provisioning can be outlined as a five-step process:
1. Create a Trial Org.
Trialforce is the best way to give your customers access to trial your app while you maintain visibility and control. You can specify that the trial is active for a number of days and have the option to convert the trial to an active org at the end of the trial period by placing an order with Salesforce (see below). Trialforce also allows partners to pre-install and pre-configure orgs, saving considerable time when signing up a new customer!
2. Install OEM Package, if not using Trialforce.
3. Configure Seats.
Using the License Management App (LMA), configure the seats/licenses for your application on your customer’s behalf.
4. Create Order.
Using Channel Order Applications (COA) – explained later – the org goes from ‘Trial’ to ‘Active’. This provisions the licenses and allows Salesforce to invoice the partner for the percentage of net revenue (PNR) owed.
5. Handover Org to the Customer.
License Types
OEM partners are essentially resellers of Salesforce Platform licenses.
The most common license type you will come across is OEM Embedded (for internal users), which is a contractually restricted Enterprise Edition Platform license. Details on this license type can be found here.
License Provisioning
There are two steps to provisioning your customers’ access to your application – both are required to allow customer users to access your app UI. Here’s a breakdown of the License Management App (LMA) and Channel Order Applications (COA):
| Managed Package License | Salesforce License | |
|---|---|---|
| Also referred to as… | LMA-provisioned or package default. | COA-Provisioned |
| The meaning of the acronyms | The License Management App (LMA) allows you to configure the seats/license for your packaged application on your customer’s behalf. | Channel Order Application (COA) is what you submit to Salesforce in order for them to provision the underlying platform license/s – so that the customer can access their org. Salesforce assigns an order status to help the partner track the order’s progress; however, these are usually provisioned within 24 hours. COA also allows Salesforce to recognize the agreed percentage of net revenue (PNR) for your order and will invoice partners in accordance with COA submissions. |
License Management App (LMA)
The License Management App (LMA) allows you to configure the seats/license for your managed package on your customer’s behalf. Using LMA, you can:
- Add/Remove licenses.
- Suspend licenses (e.g. for billing issues if the customer withholds payment).
- Support your customers and log in as customer users through the LMA’s Subscriber Console. Logging in as customers via the subscriber console also gives ISVs access to the full stack trace for their managed applications – which is otherwise hidden from customers.
2GP vs. 1GP
Being aware of second-generation packaging (2GP) is very important for anybody who’s working for an ISV or in a product situation intended to go onto the AppExchange.
All net-new packages should be built using 2GP. Now, there are very few exceptions where a new package should be created as 1GP and not 2GP. For older 1GP packages – Salesforce plans to provide a migration process (forward-looking statement!).
2GP has a tighter integration with DevOps – and you should be striving towards better visibility of your development cycle.
Package Registration
Let’s move on to registering your managed package in the Partner Community. This is so you can define the default licensing configuration for your package. In order to do this, you’ll need
to:
- Log into the Partner Community and navigate to the Publishing tab and Organizations subtab.
- Click Connect Org to connect the org associated with your package/s to your Partner Community account.
- For second Generation Packages (2GP), enter the credentials for your Dev Hub environment. For first Generation Packages (1GP), enter the credentials for your packaging org.
You’ll see an entry in the table for your org, listing any associated packages and templates:
Now, with the package connected – it’s time to register the package and assign installation defaults:
- Navigate to the Packages subtab and click Register Package.
- Specify your preferences in the pop-up window. Remember, these preferences are specific to the managed package – not the customer’s environment.
- Default settings for a package can be set to alleviate the workload to administering access to your app. For OEM partners, it often makes sense to choose Active and Site-Wide, which means that every user in the org has access to the app (as opposed to defining access per seat). This is another way that makes selling to net-new Salesforce customers easier (if the customer won’t use other Salesforce or ISV products).
Trialforce
Leveraging Trialforce is optional – however, it is the best way to give your customers access to your app while you maintain visibility and control:
- Configure a Trialforce template.
- Partners need to submit their Trialforce templates for Security Review and be approved before they can be used to create orgs. The Security Review process is in place for all apps listed on AppExchange – and also applies to Trialforce templates (although the review process is faster than the one for an app).
- You have the option to convert the trial to an active org at the end of the trial period using the Channel Order App – which tells Salesforce that “this is an active customer”. So Salesforce removes trial licenses, adds the active production licenses, and switches the org from trial to active. This provides a great transition for OEM customers from trial to active use of their org and app!
Summary
This guide explores the different models of ISV relationships available for building and selling apps on the Salesforce platform. We explained how building an app on the Salesforce platform comes with numerous benefits, including advanced capabilities, complementary support, and access to AppExchange – a large marketplace for selling and promoting apps.
There are two ISV partnership models available – OEM and ISVForce – which have differences in terms of revenue share, dependency on Salesforce licenses, and licensing models. The five-step process explained how OEM provisioning works, enabling app builders to market and sell their apps to non-Salesforce customers.
Learn More
- Partner Program Policies
- SOAP API Developer Guide Manage Licenses
- Join the Salesforce Partner Program
- Build Your First AppExchange App Guide
- Developing a Killer AppExchange App: First Steps
- Getting An App Listed On The AppExchange