AppExchange Commercial Models: OEM, Free, and ISV Licensing

The AppExchange Partner Architecture: Understanding ISVForce and OEM Models

For independent software vendors (ISVs) and enterprise solution architects, distributing software on the Salesforce platform requires a deep alignment between technical architecture and commercial agreements. Salesforce offers two foundational partner distribution architectures: ISVforce and OEM Embedded (Original Equipment Manufacturer). Selecting the incorrect model during the design phase can lead to severe architectural friction, compliance infractions, and unsustainable margins. Understanding the precise capabilities and constraints of each model is a prerequisite for any enterprise solution deployment.

The ISVforce Model: Native Extension

The ISVforce model is engineered to deliver native extensions directly into a customer’s existing Salesforce environment. In this model, the customer has already procured core CRM licences—such as Sales Cloud, Service Cloud, or Salesforce Platform licences—directly from Salesforce. The partner’s application is packaged as a managed package and installed into this host organisation.

Commercially, the ISVforce model assumes a co-existence paradigm. The end-user utilises their pre-existing Salesforce user licence to access the standard platform capabilities, while the partner's managed package introduces custom metadata, Apex classes, custom objects, and Lightning components that enhance this baseline capability. The primary architectural benefit is the direct, unhindered access to the customer's standard CRM objects (such as Account, Contact, Lead, Opportunity, and Case) without additional compliance friction.

The OEM Embedded Model: Standalone Distribution

The OEM Embedded model allows a partner to distribute a complete, standalone solution that bundles the underlying Salesforce platform utility alongside the partner's proprietary intellectual property. In this scenario, the customer does not need to have a pre-existing commercial contract with Salesforce; the partner act as the sole commercial counterparty, selling a complete application powered by Salesforce technology.

Architecturally, OEM Embedded licences are built on top of the Salesforce Platform User Licence. The partner provisions the user licences directly to the customer as part of their bundle. However, because these user licences are platform-based, they are subject to strict functional constraints enforced by Salesforce's product terms. The most significant boundary is that OEM users are technically and commercially blocked from accessing standard CRM objects. Specifically, OEM licences do not grant access to:

• Lead
• Opportunity
• Campaign
• Forecast
• Case (standard customer service case tracking)

If an OEM application requires lead tracking, sales pipelines, or support ticketing, the solution architect must completely design and build custom schemas (e.g., a custom Custom_Opportunity__c object) and build custom logic to replicate these features. Attempting to bypass these object boundaries by writing custom integrations that expose standard objects to OEM users violates Salesforce’s "indirect access" policies and will fail commercial audits, leading to substantial back-licensing penalties.

ISVforce vs. OEM Embedded Architectural Comparison

The table below provides a comprehensive architectural and commercial breakdown of the two partner models:

Revenue Share Mechanics: Standard ISV Margins vs Custom OEM Terms

Entering the AppExchange ecosystem requires a thorough understanding of the financial obligations partners owe to Salesforce. Every paid transaction on the AppExchange is subject to a revenue-sharing agreement governed by the partner's AppExchange Partner Programme Agreement (SPPA). Architects and business leaders must model these costs over a multi-year horizon to ensure commercial viability.

Percent of Net Revenue (PNR) Mechanics

The standard commercial baseline for a paid AppExchange application is the Percent of Net Revenue (PNR) model. Under the standard SPPA, the revenue-share margin is typically 15% of the net revenue generated by the partner's application. For example, if a partner licenses their managed package to an enterprise customer for £100 per user per month, the partner must remit £15 per user per month to Salesforce.

Net revenue is calculated based on the actual price billed to the customer, net of any standard regional taxes. However, partners must be cautious: discounting the customer's subscription price reduces the partner's margin but does not exempt them from their percentage obligations. To prevent partners from selling licences at unsustainably low prices to bypass revenue shares, Salesforce enforces specific pricing parameters, particularly in the OEM Embedded space.

OEM Embedded Floor Pricing and Custom Terms

Under the OEM Embedded model, Salesforce does not merely charge a simple percentage of the partner's sale price. Because Salesforce is providing the underlying platform infrastructure (including database capacity, security layers, compute resources, and upgrades), they enforce a "Floor Price" per user per month. This floor represents the absolute minimum amount the partner must pay to Salesforce for every provisioned user, regardless of the discount given to the customer.

For instance, a standard OEM contract might specify a PNR of 15% with a floor price of £8 per user per month. Consider the commercial impact of this floor under two pricing scenarios:

1. Scenario A (Standard Pricing): The partner sells the application at £80 per user per month. The 15% PNR equates to £12. Since £12 is higher than the £8 floor, the partner remits £12 to Salesforce and retains £68. The effective margin is 85%.
2. Scenario B (Aggressive Discounting): The partner discounts the application to £30 per user per month to secure a strategic enterprise deal. The 15% PNR would equate to £4.50. However, because this is below the £8 floor, the partner must pay the full £8 floor price to Salesforce. The partner retains only £22. The effective revenue-share margin rises from 15% to 26.7%, severely compressing the partner's net margin.

Multi-Year Revenue Share Model

Below is a commercial simulation displaying the multi-year impact of a contract with a PNR of 15% and a £10 floor price, assuming an initial enterprise deal of 1,500 seats scaling over three years at different price points:

Licensing Enforcements: Managing Installs via the License Management Application (LMA)

To enforce commercial agreements and control software delivery, AppExchange partners must utilise Salesforce's standard tool: the License Management Application (LMA). The LMA is installed in the partner’s License Management Organisation (LMO), which is typically their primary business environment. It acts as the absolute source of truth for all installations, version distributions, and licence states.

The LMA Schema and Data Model

When a subscriber installs a managed package from the AppExchange, a secure handshake occurs between the subscriber's environment and the partner's LMO. This handshake automatically instantiates and updates specific custom records in the partner's database. Understanding this schema is essential for automating user provisionings and tracking licence lifecycles:

• sfLma__Package__c: Represents the partner’s actual application. It stores the metadata associated with the package, including the unique Package ID and the developer namespace prefix.
• sfLma__Package_Version__c: Represents a specific release version of the package. It contains metadata such as the version number (e.g., 2.4.0), security review status, release date, and whether the package version is Beta or Released.
• sfLma__License__c: The central operational object. Every installation in a subscriber org generates an active sfLma__License__c record in the partner’s LMO. It tracks the subscriber’s Org ID, expiration date, number of licensed seats (or site-wide indicator), status (Trial, Active, Suspended, Expired), and installation source.

Seat-Based vs. Site-Based Enforcement Mechanics

When designing a managed package, partners must choose how to enforce licences in the customer’s environment. This choice determines how the platform handles licence assignment:

1. Seat-Based Licensing (Per-User): The LMA licence record specifies a discrete number of allowed users (e.g., 50 seats). In the subscriber org, the administrator must go to Setup > Installed Packages, select the package, and click Manage Licenses to explicitly allocate a licence to a specific active user. If the administrator attempts to assign a 51st user, the Salesforce platform UI blocks the action, returning an insufficient licence error. Behind the scenes, the platform stores these allocations in the standard UserPackageLicense object.
2. Site-Based Licensing (Org-Wide): The LMA licence record is marked as site-wide. In this model, the "Manage Licenses" link is suppressed in the subscriber's Setup menu. The platform automatically authorises every active user in the subscriber's organisation to access the packaged components. Enforcement of specific user permissions is left entirely to the partner's custom code, such as inspecting custom permission sets or custom settings at runtime.

LMA Integration & Apex Automation

To deliver modern SaaS experiences, partners integrate custom Apex logic in their LMO to respond immediately when a customer installs a trial or purchases a licence. Below is a production-ready Apex handler framework designed to run on the creation of a sfLma__License__c record, auto-provisioning off-platform sandbox integrations or generating welcome notifications:

trigger LicenseAutomationTrigger on sfLma__License__c (after insert, after update) {
    List<sfLma__License__c> newLicenses = new List<sfLma__License__c>();
    
    for (sfLma__License__c lic : Trigger.new) {
        // Only trigger automation on newly active customer production environments
        if (lic.sfLma__Status__c == 'Active' && 
            (Trigger.isInsert || Trigger.oldMap.get(lic.Id).sfLma__Status__c != 'Active')) {
            newLicenses.add(lic);
        }
    }
    
    if (!newLicenses.isEmpty()) {
        LicenseProvisioningService.processActiveLicenses(newLicenses);
    }
}

public class LicenseProvisioningService {
    @future(callout=true)
    public static void processActiveLicenses(List<Id> licenseIds) {
        // Query fully populated license fields
        List<sfLma__License__c> activeLicenses = [
            SELECT Id, sfLma__Subscriber_Org_ID__c, sfLma__Seats__c, 
                   sfLma__Expiration__c, sfLma__Package_Version__r.sfLma__Version__c
            FROM sfLma__License__c 
            WHERE Id IN :licenseIds
        ];
        
        for (sfLma__License__c lic : activeLicenses) {
            try {
                // Call external provisioning API to create account tenant
                Http http = new Http();
                HttpRequest request = new HttpRequest();
                request.setEndpoint('https://api.partnerportal.com/v1/tenant/provision');
                request.setMethod('POST');
                request.setHeader('Content-Type', 'application/json');
                
                String payload = JSON.serialize(new Map<String, Object>{
                    'subscriberOrgId' => lic.sfLma__Subscriber_Org_ID__c,
                    'allocatedSeats' => lic.sfLma__Seats__c,
                    'expiryDate' => lic.sfLma__Expiration__c,
                    'installedVersion' => lic.sfLma__Package_Version__r.sfLma__Version__c
                });
                
                request.setBody(payload);
                HttpResponse response = http.send(request);
                
                if (response.getStatusCode() != 200) {
                    System.debug(LoggingLevel.ERROR, 'API Provisioning Failed for Org: ' + lic.sfLma__Subscriber_Org_ID__c);
                }
            } catch (Exception ex) {
                System.debug(LoggingLevel.ERROR, 'Exception in license provisioning: ' + ex.getMessage());
            }
        }
    }
}

The Commercial Impact of Integrating Free vs Paid Packages

Enterprise IT architectures often view "Free" AppExchange packages as an easy way to speed up delivery. However, solution architects must recognise that there is no such thing as a free lunch in a multi-tenant cloud environment. Free applications can introduce silent, significant commercial and operational overheads that can exceed the cost of paid alternatives.

Data Storage Exhaustion Costs

Salesforce allocates a baseline of data storage to every customer org (typically 10 GB for Enterprise/Unlimited, plus 20 MB per user licence). When a partner distributes a free application (for example, a logging utility, email tracker, or data synchronisation engine), that application often creates custom object records for every event or transaction it handles.

If a free application writes 500,000 logging records to a custom object per month, and each record consumes the standard 2 KB database allocation, this consumes 1 GB of database storage. Over a twelve-month period, this single free utility will consume 12 GB. Once an org exceeds its data storage limit, Salesforce blocks new record creation. To remediate this, the customer must purchase additional storage blocks, which are priced commercially at approximately £120 to £250 per GB per month. A free utility can quickly cost an organisation thousands of pounds in core storage add-ons.

API Call Limits and Off-Platform Syncs

Many "free" applications are actually front-end agents that connect to external, third-party software platforms. While the AppExchange package itself is listed as free, the overall solution requires an API-driven data integration to sync records off-platform.

Every inbound API call consumes the customer org's daily API limit (governed by the org's licence tier). If the free package processes massive batches of records via external callouts or syncs, it can easily exhaust the customer's daily API allocation. When an organisation exceeds its API limits, business-critical integrations (like ERP syncs or website forms) fail immediately. Resolving an API bottleneck typically requires upgrading core licences or purchasing custom API add-on packs from Salesforce, adding unexpected operational and commercial costs.

The Risk of Unmanaged Free Packages

Free applications are frequently delivered as unmanaged packages. While this allows the subscriber to view and customise the source code directly, it introduces severe architectural and governance risks:

• No Upgrade Path: Once an unmanaged package is installed, it is completely severed from the developer's source repository. The customer cannot receive automatic bug patches, security updates, or feature enhancements. To upgrade, the administrator must completely uninstall the existing package (losing all historical data stored in its objects) and install the new version.
• Technical Debt Ownership: The moment you install an unmanaged package, your development team becomes the sole owner of the code. If a future Salesforce platform upgrade (such as an API retirement or a mandatory security update) breaks the unmanaged code, your internal team must debug and patch it. This can consume high-value development hours that should be spent on strategic business delivery.

Governance Playbook: Reviewing Third-Party Package Dependencies and Commercial Risk

To safeguard enterprise environments from security vulnerabilities, platform instability, and unexpected licensing costs, the Center of Excellence (CoE) must establish a strict governance playbook for all third-party package installations. Administrators and solution architects should enforce a multi-stage review before any package—free or paid—is allowed in a sandbox or production environment.

The Package Governance Framework

The governance framework must address three primary dimensions: **Security Compliance**, **Metadata Consumption**, and **Commercial Dependencies**.

1. Salesforce Security Review Validation: Ensure that the managed package has passed the official Salesforce Security Review. Certified managed packages that have successfully passed the security review are granted specific platform exemptions in the subscriber org. Most importantly, their custom objects, custom tabs, and active flows do not count against the subscriber's hard limits (e.g., the limit of 2,000 custom objects per org in Enterprise and Unlimited editions). Uncertified managed packages or unmanaged packages count directly against these limits, which can block future internal custom developments.
2. Transient Dependency Mapping: Review the package metadata to identify any hidden dependencies on other AppExchange packages or external services. Some free packages require the installation of paid packages to function, or they make callouts to unverified third-party domains that do not comply with the organisation's data privacy policies.
3. Namespace Limit Tracking: Monitor namespace isolation to ensure that package installations do not create governor limit bottlenecks. Managed packages execute Apex code within their own namespace limits (e.g., they receive a separate transaction limit for SOQL queries), but they share the overall CPU time limit and heap size limits during execution. An unoptimised managed package trigger can cause your standard processes to fail with LimitException errors.

Programmatic Package Inventory and Metadata Audit

To maintain absolute visibility, platform architects should run programmatic audits to inventory all installed managed packages and assess their impact on the org's metadata limits. Below is a SOQL query designed to execute against the Tooling API to extract a comprehensive inventory of installed subscriber packages, namespaces, and validation states:

-- Query the Tooling API to extract all installed package details
SELECT Id, SubscriberPackageId, SubscriberPackage.Name, 
       SubscriberPackage.NamespacePrefix, MinVersionNumber, 
       MaxVersionNumber, IsOrgDependent
FROM InstalledSubscriberPackage

To identify the volume of custom objects introduced by specific namespace prefixes (which helps verify if a package is consuming core metadata limits), run the following query against the Tooling API:

-- Query the Tooling API to count custom objects allocated to a specific managed namespace
SELECT Id, DeveloperName, NamespacePrefix, SharingModel 
FROM CustomObject 
WHERE NamespacePrefix = 'sfLma' 
   OR NamespacePrefix = 'YOUR_APP_NAMESPACE'

Architectural Licensing Audit Checklist

The Center of Excellence should mandate that the following checklist is completed and signed off by the Lead Salesforce Architect prior to package procurement: