The Most Expensive Default in Salesforce Licensing

Large enterprises increasingly use Salesforce not just for CRM but as a platform to build custom applications. HR portals. IT ticketing systems. Operations workflows. Supply chain trackers. Broker management tools. Compliance dashboards. These applications run on Salesforce's Lightning Platform and serve users who never open an Opportunity record, never create a Lead, and never touch a Case. They interact exclusively with custom objects built by the organization's development team.

These users do not need Sales Cloud. They do not need Service Cloud. They need Salesforce Platform licenses, which cost a fraction of full CRM licenses and provide access to custom applications and a limited subset of standard objects (Accounts and Contacts for basic reference) without the CRM functionality those users will never use.

The problem is that most enterprises assign full CRM licenses to every Salesforce user by default. It happens because procurement buys what the sales team quoted. It happens because administrators assign what is available in the license pool. It happens because developers build applications using convenient standard objects (Case, Opportunity) without realizing that doing so triggers a requirement for higher-cost licenses. Over time, the organization accumulates hundreds or thousands of full-price CRM licenses assigned to users who only interact with custom applications.

A systematic license right-sizing exercise, identifying which users actually need CRM objects versus which users interact exclusively with custom applications, typically reveals that 30-50% of users can be moved to Platform licenses. At enterprise scale, this represents millions in annual savings. It is one of Salesforce's most under-utilized cost optimization levers, and it requires no reduction in functionality for the affected users because they were never using CRM functionality to begin with.

The Platform license is Salesforce's most under-utilized cost optimization lever. Many organizations default to full CRM licenses for every Salesforce user, even when the majority only interact with custom applications. A structured assessment typically reveals that 30-50% of users can be moved to Platform licenses without any reduction in the functionality they actually use. The savings are immediate and recurring. See our Salesforce License Optimization Service for a structured assessment approach.

Full CRM Licenses Versus Platform Licenses: What Actually Differs

Understanding what separates a full Sales or Service Cloud license from a Platform license is the foundation of every optimization decision that follows. The distinction is not about quality or reliability. Both license types run on the same infrastructure with the same uptime, the same security model, and the same development capabilities. The distinction is about which Salesforce objects and features the user can access.

A full Sales Cloud or Service Cloud license provides access to everything. All standard CRM objects: Leads, Opportunities, Cases, Campaigns, Forecasts, Quotes, and every other object Salesforce has built into its CRM platform. Plus all custom applications, custom objects, and AppExchange apps the organization has deployed. A full license is the most expensive per-user option because it provides the broadest access. It is the correct license for sales representatives who manage Opportunities, marketing teams who run Campaigns, and support agents who work Cases. It is the wrong license for a factory technician who logs maintenance requests through a custom object.

A Salesforce Platform license provides access to custom applications and a limited subset of standard objects. Platform users can use custom objects, custom tabs, custom applications, and AppExchange apps that do not require CRM functionality. They can see Accounts and Contacts for basic reference. They cannot access Leads, Opportunities, Cases, Campaigns, Forecasts, or any other standard CRM object. Salesforce offers two tiers. Platform Starter supports approximately 10 custom objects and basic features. Platform Plus supports approximately 110 custom objects and advanced capabilities including API access and more sophisticated automation. The cost difference between a Platform license and a full CRM license is substantial, often representing a savings of 50% or more per user.

The decision framework is straightforward. If a user's workflow requires access to standard CRM objects (Opportunities, Cases, Leads, Campaigns), they need a full license. If a user's workflow is entirely contained within custom objects and custom applications, they should be on a Platform license. If a user needs both, which is less common than most organizations assume, they need a full license. The critical discipline is making this assessment for every user rather than defaulting to the most expensive option.

Consider a global manufacturer that uses Salesforce for both sales CRM and a custom supply chain application. The sales staff need full Sales Cloud licenses because they manage Opportunities and Forecasts. The operations team accessing the supply chain app uses only custom objects. They never open an Opportunity record. Putting the operations team on Platform licenses rather than Sales Cloud licenses saves the company hundreds of thousands of dollars annually without removing a single capability those users actually need.

Building Internal Applications on Platform Licenses

Salesforce's Lightning Platform supports enterprise-grade custom application development well beyond CRM. Enterprises are building HR systems, finance tools, operational trackers, IT help desks, compliance management systems, and dozens of other internal applications on the platform. The key insight for CIOs is that every one of these applications can be designed so that its users operate on Platform licenses rather than full CRM licenses, as long as the application architecture avoids standard CRM objects.

An IT help desk built on custom objects avoids Service Cloud licensing entirely. Rather than using Salesforce's standard Case object, which requires a Service Cloud license, the development team creates a custom IT_Request__c object with the same fields and workflow automation. All employees accessing the help desk use Platform licenses. Only the IT administrators who also need access to CRM data get full licenses. The cost savings compared to buying Service Cloud licenses for every employee in the company are substantial.

An HR onboarding portal built on custom objects avoids CRM licensing for HR staff and managers. Custom objects for Employee_Record__c, Onboarding_Task__c, Training_Module__c, and Performance_Review__c handle the data model. HR staff and managers use Platform Plus licenses, which support the complex data model with up to 110 custom objects. The application runs on the same reliable Salesforce infrastructure as any CRM deployment, but at a fraction of the per-user cost.

Operations workflows for manufacturing, logistics, and field service follow the same pattern. Maintenance schedules, equipment tracking, approval workflows, and quality inspections built on custom objects can run on Platform Starter licenses, which are the least expensive option, for plant employees and field technicians who need basic access to straightforward workflows.

The savings are quantifiable. Five hundred users on Platform licenses versus Sales Cloud licenses can mean saving hundreds of thousands of dollars annually. The tradeoff is that Platform users do not get CRM reports or analytics by default. The custom application must provide its own reporting through custom reports, dashboards, or alternative analytics tools. For most internal applications, this is a trivial design requirement that pays for itself many times over in license cost reduction.

The architecture decision that determines license cost must be made at design time, not after deployment. Once a custom application is built using standard CRM objects (Case, Opportunity, Lead), migrating to custom objects retroactively is expensive and disruptive. Every new Salesforce application should include a licensing impact checkpoint during the architecture review: "Are we using any standard object that will require a higher license for target users?" If the answer is yes, the team should evaluate whether a custom object can serve the same purpose. This single practice, embedded into the development process, prevents license creep before it starts.

Need Help Optimizing Your Salesforce License Mix?

Our Salesforce license optimization service identifies which users can move from full CRM to Platform licenses, quantifies the savings, and helps you negotiate blended license models with Salesforce. We typically find that 30-50% of users are over-licensed. Independent, data-driven, vendor-neutral.

Book a Confidential Call →

OEM Licensing: When You Are Delivering Salesforce to External Users

The licensing calculus changes fundamentally when the Salesforce application is not for internal employees but for external users. Customers, partners, dealerships, clinics, franchisees, or any external party who needs access to an application your organization has built on Salesforce. For these scenarios, Salesforce offers two primary models: OEM (Original Equipment Manufacturer) Embedded licensing and Experience Cloud portal licensing. Understanding when to use which model is one of the more consequential licensing decisions a CIO can make.

OEM licensing is for organizations acting as ISVs or delivering standalone software products built on Salesforce. Under an OEM arrangement, the organization bundles Salesforce's platform technology into its application and offers it to external parties. End-users do not need their own Salesforce subscriptions. They may not even realize Salesforce is the underlying platform. Each client gets a separate Salesforce org with custom objects only. Each org requires one or two full admin licenses for setup and maintenance. All other users operate on OEM Platform licenses for the custom application only.

The key constraint is that OEM applications cannot expose standard CRM objects or replicate full Salesforce CRM functionality. The application must be entirely self-contained on custom objects. This is a design requirement, not a limitation. For organizations delivering standalone products, whether a dealer management platform, a clinical trial management system, or a franchise operations tool, the OEM model provides the cost structure of Platform licensing with the distribution model of a SaaS product. The organization bundles Salesforce licensing costs into its service fees to clients, controls the user experience completely, and avoids the per-user cost structure that would make external deployment prohibitively expensive.

Consider a large automotive company that develops a dealer management platform connecting independent dealerships. Instead of requiring each dealership to buy its own Salesforce subscription, the company enters an OEM agreement. Each dealership gets a Salesforce-based portal built entirely on custom objects for inventory, orders, and training. Dealer personnel use OEM Platform licenses. The automotive company bundles the licensing cost into its service fee. This accelerates time to market while keeping licensing costs manageable at scale.

Before choosing OEM, assess whether an Experience Cloud portal could serve the same purpose. Experience Cloud (formerly Community Cloud) is simpler to set up for customer or partner access to your existing Salesforce data. OEM is the better choice when delivering a standalone product, when separate orgs per client are required, or when end-users should not need their own Salesforce subscription. The decision between OEM and Experience Cloud should be made early in the planning process because it affects architecture, cost structure, and contract terms.

OEM deals are complex. The organization should engage Salesforce's ISV/OEM program early to negotiate license terms, minimum commitments, and compliance requirements. OEM agreements often include usage thresholds or tiered pricing. Monitor external user counts and org counts against contract terms. If the user base grows faster than projected, renegotiate before overages trigger penalty pricing.

Experience Cloud Portal Licensing: Login-Based Versus Named User

Experience Cloud enables web portals where external users, whether customers, partners, distributors, or franchisees, log in for specific actions: submitting support cases, collaborating on opportunities, accessing knowledge articles, updating account information. The licensing model for these external users differs from internal licensing and offers two distinct pricing approaches, each optimized for a different usage pattern.

Named User (Member-Based) licensing charges a fixed price per external user regardless of how often they log in. A named user license costs the same whether the user logs in every day or once a year. This model works best for smaller, predictable communities where users engage frequently. A software firm running a partner portal for 40 certified resellers who register leads and track opportunities daily benefits from named licenses because the per-user cost is predictable, there are no login caps, and the community size is stable enough to budget accurately.

Login-Based licensing charges per actual login consumed from a purchased monthly pool. Each user consumes one login per day they access the portal. If a user does not log in, no login is consumed. This model works best for large, fluctuating user bases with sporadic engagement. A consumer retail company offering a portal for millions of end customers to register products and request support benefits from login-based licensing because most customers log in once or twice per year. Paying per actual login rather than per registered user reduces costs dramatically when the ratio of registered users to active users is high.

The choice between models depends entirely on the ratio of total users to active users. If most registered users are active most of the time, named licensing provides cost certainty and simplicity. If the community is large but engagement is sporadic, login-based licensing ensures you only pay for activity. If the organization is uncertain about usage patterns, starting with login-based licensing with a conservative pool is the lower-risk approach because it is easier to scale up than to scale down from committed named licenses.

There is a third consideration that CIOs often miss. Customer Community licenses and Partner Community licenses are not interchangeable. Customer Community licenses (including Customer Community Plus) restrict access to specific objects suitable for support cases, knowledge articles, and account information. Partner Community licenses give business partners access to CRM data like Opportunities and Leads for co-selling. Using a cheaper Customer Community license for a scenario that requires partner-level access to Opportunities violates Salesforce's terms. The data exposed through the portal determines which license type is required, regardless of which model is cheaper.

Mix models when it makes sense. Salesforce allows mixing license types in certain configurations. A large portal might use login-based licensing for thousands of infrequent customer users and named licenses for a smaller group of power users or partner users who access the portal daily. The combination optimizes cost across different engagement patterns within the same portal deployment.

Design Experience Cloud portals with licensing economics in mind. Provide rich self-service information publicly, such as FAQs and knowledge articles, without requiring login. This preserves login credits for high-value interactions that justify the cost: submitting cases, accessing sensitive account data, registering deals. Every interaction that can be served without a login is an interaction that does not consume a license. Portal architecture and licensing strategy should be designed together, not independently.

Architecture Best Practices: How Application Design Determines License Cost

How an organization architects its Salesforce solutions directly determines licensing costs. This is not a procurement concern or a finance concern. It is an engineering concern that procurement and finance benefit from enormously when it is handled correctly. The critical goal is to avoid "license creep," the pattern where application design inadvertently forces higher-cost licensing for users who do not need it.

Use custom objects instead of restricted standard objects. This is the single most impactful architecture decision for license cost. Create a custom Ticket__c object instead of using the standard Case object. Create a custom Policy_Deal__c instead of the standard Opportunity object. Platform users can fully use applications built on custom objects. The moment an application references a standard CRM object, every user of that application needs a full CRM license. A large insurance company built a broker management application and intentionally avoided the standard Opportunity object for policy sales, creating a custom Policy_Deal__c instead. This design decision allowed hundreds of account managers to use Platform licenses. Only the smaller team needing cross-selling CRM data got full Sales Cloud licenses. Estimated result: 40% savings on license costs for that application.

Limit cross-over between custom applications and CRM data. Custom applications that link to Accounts and Contacts are fine because Platform users can see those objects. But the moment an application requires access to Opportunities, Leads, Cases, or Campaigns, the license requirement escalates. Architects should treat any reference to a restricted standard object as a red flag that triggers a design review. Either rethink the data model with custom objects or accept that the specific users who need the cross-over will require full licenses while keeping the broader user base on Platform.

Monitor custom object limits and plan accordingly. Platform Starter supports approximately 10 custom objects. Platform Plus supports approximately 110. An application that needs 50 custom objects cannot run on Platform Starter. SAM and development teams need to collaborate on which tier matches the application's data model. In some cases, functionality can be spread across child objects rather than top-level objects to stay within limits. In other cases, Platform Plus is simply the correct tier and still represents substantial savings over full CRM licenses.

Plan for storage and API limits at the Platform tier. Platform licenses include lower data storage and API call allocations than full CRM licenses. Applications with large data volumes or heavy API integration may hit these limits. The solution is to archive older data, purchase additional storage (which is cheaper than upgrading the entire user base to a higher edition), or use middleware for API-intensive integrations. Do not upgrade hundreds of users from Platform to full CRM licenses because the application needs more storage. Buy the storage separately. The math is not close.

Enforce compliance through profiles and permission sets, not user discipline. Salesforce compliance audits can penalize the organization if a Platform user accesses a restricted object via API or any other means. Design the system to enforce license boundaries technically. Use profiles and permission sets to prevent Platform users from accessing disallowed objects. Do not rely on training or user discipline alone. A single API call that touches an Opportunity from a Platform user's context creates a compliance violation that Salesforce can identify and enforce.

Document which objects and features map to which license types. Maintain a mapping document that lists every custom application, the objects it uses, and the corresponding license type required. This documentation serves three purposes. It prevents developers from inadvertently introducing restricted objects into Platform-licensed applications. It provides evidence during Salesforce compliance reviews that the organization's license assignments are deliberate and correct. And it gives the procurement team the data they need to negotiate the right license mix at renewal.

Compliance enforcement is not optional. Salesforce can and does audit whether Platform users are accessing restricted objects. A Platform user who touches an Opportunity record, even through an API integration the user does not directly control, represents a compliance violation. The organization can be required to upgrade that user (and potentially all similarly situated users) to full CRM licenses retroactively. Technical enforcement through profiles and permission sets is the only reliable way to prevent this. Organizational processes and user training are supplementary, not primary controls.

Negotiating Blended License Models at Enterprise Scale

Understanding the license types is the first step. Negotiating the right commercial terms for a blended model is where the savings are realized. Salesforce's standard sales process defaults to full CRM licenses because they generate the most revenue per user. Achieving an optimal Platform-to-CRM license mix requires proactive negotiation with data to support the proposed allocation.

In enterprise agreements, negotiate bulk Platform license bundles alongside CRM licenses. Salesforce and independent advisors can structure deals with discounted Platform bundles. This is especially effective when rolling out large-scale custom applications where hundreds or thousands of users need Platform access. Volume pricing for Platform licenses can reduce the per-user cost further below the already-lower list price.

Build the business case with quantified savings. When pitching new Salesforce-based internal applications to stakeholders, demonstrate that the application can be delivered at half the licensing cost of a CRM module by using Platform licenses. This is not a theoretical exercise. It is a calculation based on the number of users, the license type required by the application's architecture, and the price difference between Platform and full CRM licenses. Finance approves projects more readily when the licensing cost is demonstrably minimized.

Plan for growth with volume pricing committed in advance. If a custom application's user base is expected to grow (an HR application rolling out company-wide, for example), engage Salesforce early about volume pricing for Platform licenses. Large enterprises can negotiate enterprise license agreements with blocks of Platform users at favorable rates, locking in pricing before the user base expands to its projected size.

Include Experience Cloud and OEM licenses in the enterprise negotiation. External portal licenses, login pools, and OEM arrangements should be negotiated as part of the broader Salesforce contract, not as separate transactions. Bundling internal and external licensing into a single negotiation gives the organization leverage to negotiate better rates across the entire Salesforce relationship. Large enterprises can secure significantly better rates for high-volume community users or login pools when they are part of a comprehensive deal.

Implement governance to review and adjust the license mix regularly. License right-sizing is not a one-time exercise. User roles change. Applications evolve. New custom applications are deployed while others are retired. Governance should include annual audits aligned with contract renewals: check whether Platform users have started needing CRM features (upgrade them) or whether full-license users never touch CRM objects (downgrade them). Use Salesforce login data and usage analytics to make these decisions with evidence rather than assumptions.

Stay informed on licensing policy changes. Salesforce licensing evolves constantly. New license types appear. Products are renamed. Object limits change. What was true about Platform license capabilities last year may not be true next year. Maintaining a relationship with an independent Salesforce licensing advisor ensures the organization's license strategy reflects current terms rather than outdated assumptions.