CIO Playbook for Salesforce Platform and Custom Apps Licensing Strategy

CIO Playbook for Salesforce Platform and Custom Apps Licensing Strategy

Large enterprises are increasingly leveraging Salesforce not just for CRM but as a platform to build custom applications. As a CIO, structuring the right licensing strategy for these non-CRM use cases is critical to optimize costs and remain compliant.

Salesforce offers a variety of user license types – from full Sales and Service Cloud licenses to lighter Platform and OEM options, each with different capabilities and price points.

This playbook provides a chapter-by-chapter guide to help you navigate Salesforce licensing for custom applications. We compare full vs. platform licenses, explore when to use Platform licenses for internal apps, discuss OEM licensing for external and embedded apps, examine Experience Cloud portal licensing (login-based vs. named user), and outline best practices for designing apps to avoid unnecessary full CRM licenses.

Throughout, you’ll find enterprise use cases, cost considerations, and “Recommendations for CIOs” to inform a practical, Gartner-style licensing strategy.

Salesforce Full User Licenses vs. Platform Licenses – Understanding the Differences

Detailed Explanation:

Salesforce’s core CRM licenses (often known as Sales Cloud or Service Cloud user licenses) provide full access to CRM functionality, whereas Salesforce Platform licenses offer a more limited, cost-effective option for users who don’t need standard CRM features.

A full Sales/Service Cloud license (sometimes just called a “Salesforce” license) includes all standard objects like Leads, Opportunities, Cases, Campaigns, etc., as well as custom applications.

In contrast, a Salesforce Platform license (formerly known as a Force license, now sometimes split into Platform Starter and Platform Plus tiers) grants access primarily to custom apps and a subset of standard objects, generally including Accounts and Contacts for basic reference.

Platform users cannot use core CRM modules, such as managing sales pipelines or support cases, by default. Because of this limited scope, Platform licenses are priced significantly lower than full Salesforce user licenses.

Features and Cost Implications: 

Full Salesforce user licenses are ideal for employees in roles that require end-to-end CRM capabilities (e.g., sales reps managing opportunities and support agents handling cases). They come with higher costs but unlock all CRM features.

Platform licenses are intended for internal users who use Salesforce as a development platform or for departmental applications that do not require CRM data beyond accounts and contacts.

The cost difference can be substantial – for instance, an Enterprise Sales Cloud license might cost several times more per user than a Platform license. Salesforce now offers Platform Starter, which allows up to approximately 10 custom objects and basic features, and Platform Plus, which supports up to approximately 110 custom objects and more advanced capabilities, to fit different needs. The table below highlights key differences:

Enterprise Use Case Example:

A global manufacturer uses Salesforce for both sales CRM and a custom supply chain app. Sales staff have full Sales Cloud licenses, allowing them to use opportunities and forecasts.

Meanwhile, the operations team accessing the supply chain custom app uses Salesforce Platform licenses, as they only use custom objects and do not need to incur the cost of full CRM licenses. This dual-license strategy saves costs by right-sizing licenses to user needs.

Recommendations for CIOs:

• Match License to User Needs: Categorize your Salesforce users. Those in purely custom or back-office applications should be considered for Platform licenses, reserving full Sales/Service Cloud licenses only for roles that genuinely need CRM functionality.
• Leverage Tiered Platform Options: Evaluate Salesforce Platform Starter vs. Platform Plus. Starter might suffice for small apps with limited custom objects, whereas Plus supports larger apps. Choose the tier that fits your use case to avoid overpaying for the capacity you don’t need.
• Monitor and Adjust: Implement governance to review license assignments on a regular basis. If users with full licenses are only using custom app features, downgrade them to Platform licenses at contract renewal. Conversely, if some Platform users start needing CRM features, plan to upgrade those specific users. This ensures an optimal mix over time.
• Negotiation Strategy: In enterprise agreements, negotiate for a blended licensing model (e.g., a bulk of Platform licenses alongside CRM licenses). Salesforce and independent advisors, such as third-party licensing consultants, can often structure deals that include discounted Platform license bundles, which is especially useful when rolling out large-scale custom apps.

When to Use Salesforce Platform Licenses for Non-CRM Apps (Internal Use Cases)

Detailed Explanation: Salesforce isn’t just a CRM system – it’s also a powerful application development platform (the Lightning Platform). Many enterprises build non-CRM custom applications on Salesforce, ranging from HR and finance systems to operational tracking tools.

In these scenarios, Salesforce Platform user licenses are typically the best choice for internal users of those apps. Platform licenses allow employees to log in to Salesforce and use custom objects, custom tabs, and AppExchange apps developed for specific business processes, without paying for CRM functionality they won’t use.

Using Platform licenses for non-CRM apps can drastically reduce licensing costs for large user bases (often 50% or more savings per user compared to full licenses) while still benefiting from Salesforce’s scalability, security, and integration capabilities.

Enterprise Use Case Examples:

Organizations across industries leverage Platform licenses for a variety of internal applications:

• Employee Help Desk: A tech company builds an IT ticketing and employee help desk app on Salesforce. Employees submit and track IT support requests through a custom Case object (not to be confused with Salesforce’s standard “Case” – here, it’s a custom object like IT_Request__c). Since employees using this app don’t need Salesforce’s Service Cloud case management features beyond this custom app, they are all given Platform licenses. Only the IT administrators who also use CRM data might have full licenses. This approach avoids buying costly Service Cloud licenses for every employee.
• HR and Onboarding App: A large bank creates a custom HR portal on Salesforce for managing employee onboarding, training enrollments, and performance reviews. All HR staff and managers using this system have Platform Plus licenses, which handle the complex custom data models (dozens of custom objects for HR processes) but exclude sales features. The company can roll the app out to hundreds of managers without the CRM license price tag.
• Operations Workflow: A manufacturing enterprise develops a workflow app to manage maintenance schedules and approvals for its factory equipment. This app is entirely built on custom objects and logic. Plant employees and maintenance technicians use Platform Starter licenses to interact with the app, as they do not require access to CRM objects. The cost is a fraction of what it would be to give each user a full Salesforce license, yet the app benefits from running on the reliable Salesforce platform.

Visual Guide – Picking the Right License for Internal Apps:

• If the user’s role is CRM-centric (sales, support, or marketing): Use full Sales or Service Cloud licenses for those users.
• If the user’s role is using a custom-built app with no reliance on standard CRM objects, the Platform license is appropriate.
• Mixed roles: Some roles might need both a custom app and CRM access. In such cases, consider whether two licenses (one full, one platform) or just a full license with permission sets is more cost-effective, or if the role can be split (some users on full, some on platform). For example, a manager may need CRM data (full license), but their team members only use the custom app (platform licenses).

Cost Implication:

By using Platform licenses for non-CRM users, enterprises ensure they are not overspending on unused CRM functionality. For instance, 500 users on a platform license versus on a Sales Cloud license could mean saving hundreds of thousands of dollars annually.

However, CIOs should also consider any functionality trade-offs – for example, platform users won’t get CRM reports or analytics by default, so ensure the custom app provides the needed reporting through custom reports or an alternative.

Recommendations for CIOs:

• Institutionalize’ License Right-Sizing”: For every new internal Salesforce application, decide upfront which users truly need a full Salesforce license. Encourage architects to design solutions with Platform licenses in mind for general users. This policy avoids the default of assigning costly full licenses to everyone by habit.
• Build a Business Case for Platform Use: Quantify the cost savings of using Platform licenses when pitching new Salesforce-based solutions to internal stakeholders. Demonstrating that an internal app can be delivered on Salesforce at, say, half the licensing cost of a CRM module helps get buy-in from finance and stakeholders.
• Plan for Growth: If your custom app’s user base is expected to grow (e.g., rolling out an HR app company-wide), engage with Salesforce early about volume pricing for Platform licenses. Large enterprises may negotiate enterprise license agreements that include blocks of platform users at favourable rates.
• Train Admins and Developers: Ensure your Salesforce admins and developers understand the differences in capabilities between license types. They should know, for example, not to inadvertently use a standard CRM object in a custom app meant for Platform users. Empower them to utilize custom objects and AppExchange components that work within Platform license constraints.
• Review Periodically: As business processes evolve, periodically review whether any platform users now require CRM functionality. If so, upgrade a subset to full licenses as needed. Conversely, check if any full license users in non-CRM roles could be downgraded. This dynamic management maximizes ROI on Salesforce spend.

Salesforce OEM Licensing for External or Embedded Applications

Detailed Explanation:

Sometimes, an enterprise develops a custom application on Salesforce that is intended for both internal use and external users, or as a product offering. In these cases, Salesforce offers an OEM (Original Equipment Manufacturer) licensing model – also known as Salesforce OEM Embedded licensing.

Under an OEM arrangement, you essentially bundle Salesforce’s platform technology into your application, which you offer to external parties. The external end-users typically do not need to purchase Salesforce licenses themselves; instead, your organization (as the solution provider) obtains a special license from Salesforce that allows you to create separate Salesforce instances for your app and grant access to your end-users.

OEM licenses are Salesforce Platform user licenses (with the same limitations – no CRM objects beyond accounts/contacts) combined with rights to use your specific managed package or custom app.

This means OEM users get a tailored version of Salesforce, specifically designed for the embedded app’s functionality. They cannot see or use standard Salesforce CRM features, ensuring your application stands alone.

When to Consider OEM Licensing:

OEM is most suitable if your organization acts as an ISV (Independent Software Vendor) or offers a software service built on Salesforce to external customers. For example, if a healthcare company builds a patient management system on Salesforce and wants to sell it to clinics, an OEM model could provide each clinic with access to the app (running on Salesforce behind the scenes) without requiring those clinics to have their own Salesforce subscription.

OEM embedded apps are often delivered as completely branded solutions where the end-user might not even realize Salesforce is the underlying platform. This model contrasts with the typical AppExchange app (ISVforce model), where customers install an app into their existing Salesforce org – with OEM, the app can be sold to clients who have no Salesforce at all.

Enterprise Use Case Example:

A large automotive company develops a dealer management platform on Salesforce to connect its independent dealerships. Instead of requiring each dealership to buy Salesforce licenses, the company enters an OEM agreement with Salesforce. They provide a Salesforce-based portal for each dealership, complete with 100% custom objects and pages for inventory, orders, and training.

Under the hood, each dealership’s org includes a couple of full Salesforce admin licenses (for system admins). However, all dealer personnel are on OEM Salesforce Platform licenses that only allow access to the custom dealer app.

The automotive company bundles these costs into its service fee to the dealerships. This strategy accelerates time to market, leveraging Salesforce’s robust platform, while predictably controlling licensing costs.

Key Considerations and Cost Implications: OEM licensing requires a contract and partnership with Salesforce. Pricing is typically negotiated based on the volume of users or transactions expected. Often, the provider (your company) pays Salesforce a platform license fee (possibly discounted at scale) for each end-user, and you may add your margin when charging your customers.

Because OEM users can’t use Salesforce’s standard CRM modules, you must ensure your app is fully self-contained. Salesforce will also enforce that you’re not duplicating native CRM functionality in a way that circumvents their licensing (for example, you cannot use an OEM app to essentially provide a full sales automation system – that would require Sales Cloud licenses).

The OEM approach can be cost-effective if you have a large external user base, but the overhead of managing separate orgs and supporting those users is a factor to consider.

Recommendations for CIOs:

• Evaluate OEM vs. Alternatives: Before opting for OEM, assess if an Experience Cloud portal (see next chapter) could meet your needs for external users. Experience Cloud is simpler to set up for customer/partner access to your Salesforce data. OEM is better suited if you are delivering a standalone product or need a separate organization per client.
• Engage Salesforce Early: If OEM seems viable, involve Salesforce’s ISV/OEM program representatives early. These deals can be complex – you’ll need to negotiate license terms and minimum commitments and ensure compliance with Salesforce’s OEM rules. Early engagement helps align your app’s design with what the OEM license permits.
• Design for No-CRM: Ensure your development team knows that an OEM app cannot expose standard CRM objects or replicate full Salesforce functionality. Plan your data model to rely on custom objects exclusively, except for accounts and contacts, which can be used for basic reference data if needed. This avoids any compliance issues and keeps the licensing clean.
• Plan for Administration: Remember that each OEM org will generally require at least one full Salesforce admin user for setup and maintenance. Account for the cost of a few full licenses for admin purposes in your financial models, even if the majority of users are on the OEM platform licenses.
• Consider Third-Party Advice: If negotiating an OEM arrangement feels daunting, consider consulting with third-party Salesforce licensing advisors or experienced legal counsel who specialize in Salesforce contracts. Firms like Redress Compliance or others with Salesforce licensing expertise can offer independent guidance on structuring OEM deals, ensuring you maximize value while meeting contractual obligations.
• Monitor Usage and Costs: Once your OEM offering is live, continue to monitor the number of external users and organizations against your Salesforce contract terms. OEM agreements often have usage thresholds or tiered pricing. Keeping a close eye ensures you can renegotiate terms or adjust pricing to your customers if your user base grows faster than expected.

Leveraging Experience Cloud for Customer and Partner Portals (Login-Based vs. Named User Licensing)

Detailed Explanation:

For many CIOs, the primary way to extend Salesforce to external stakeholders, such as customers or business partners, is through Salesforce Experience Cloud (formerly known as Community Cloud). Experience Cloud allows you to create web portals or community sites on Salesforce, where external users can log in to perform specific actions, such as customers logging cases or partners collaborating on opportunities.

Licensing for Experience Cloud works differently from internal licenses. It offers community user licenses that are typically cheaper and have a limited scope. External users can only see the data you share with them, and they cannot access internal CRM features beyond what the portal exposes. Two main pricing models exist for these external user licenses:

• Named User (aka Member-Based) licensing: You pay a set price for each external user who will have access, regardless of how often they log in.
• Login-Based licensing: You purchase a bulk number of logins (access sessions) per month, and any user in that category consumes one login each day they log in. This model charges based on usage rather than a flat per-user fee.

Both models can be applied to various types of community licenses, including Customer Community, Customer Community Plus, Partner Community, and newer External Apps licenses. The key is to choose the model that aligns with your user community’s usage patterns and your budget.

Customer vs. Partner Communities:

Salesforce offers different license types depending on the portal audience. Customer Community licenses (and the higher-tier Customer Community Plus) are geared toward customers who might, for example, create support cases, view knowledge articles, or update their account info. These typically restrict access to only specific objects, such as Cases, Knowledge, or custom objects, rather than core CRM objects like opportunities.

Partner Community licenses are for business partners, such as resellers and distributors, who often need access to more CRM data, including working on Opportunities, Leads, or collaborating on Accounts they co-manage. Partner licenses are pricier but allow these extra objects. Both customer and partner licenses can be offered as named or login-based. Salesforce’s pricing structure may vary by edition and volume.

Login-Based vs. Named:

How to Decide: The difference between login-based and named pricing is crucial for cost optimization:

• If you have a large pool of occasional users, login-based licensing can be far more cost-effective. For example, imagine 10,000 customers might use your support portal, but on any given day, only a few hundred log in. With login-based licensing, you can purchase, for example, 500 logins per month rather than 10,000 user licenses. Each day a customer logs in counts against your pool; if a customer never logs in during a month, you don’t pay for them that month. This model scales well for communities where engagement is unpredictable or infrequent.
• If you have a defined group of frequent users, named licenses are simpler and potentially cheaper. For instance, if you have 50 partner users who log in almost daily to manage leads and deals, assigning each a named Partner Community license at a fixed monthly rate might be less expensive than tracking hundreds of logins. Also, named users get continuous access without worry of hitting a login cap.

Illustrative Comparison:

Recommendations for CIOs:

• Analyze Your User Community: Collaborate with your business units to project the number of external users who will access the portal and how frequently. If uncertain, consider starting with login-based licensing with a conservative login pool, as it’s easier to scale up if engagement grows. For a stable, known community, such as a set list of partners or B2B customers, compare the costs of both models at expected usage levels to see which one yields better value.
• Mix Models (If Needed): Salesforce allows mixing license types in certain cases. You might use login-based licensing for a large group of infrequent customer users and named licenses for a subset of power users or partner users. Tailor the combination to optimize cost.
• Monitor Usage Patterns: If you opt for login-based, implement monitoring to track how many logins are used each month. Set alerts for approaching thresholds so you can purchase additional login capacity in advance or take action, such as encouraging users to spread out their access, if possible. Regularly review whether the chosen model still makes sense. For example, if a subset of users starts logging in very frequently, you might consider converting them to named licenses to save money.
• Plan Portal Design with Licensing in Mind: From a design perspective, you can influence usage. For instance, provide rich self-service information publicly (without a login) when appropriate, such as FAQ knowledge articles, so that casual users don’t need to log in to get basic information, preserving your login credits for more essential interactions. Conversely, ensure that high-value interactions that require login are worth the cost (e.g., submitting a case or accessing sensitive account data).
• Include External Licenses in Negotiations: Just as with internal licenses, negotiate your Experience Cloud licenses as part of your Salesforce contract. Large enterprises can often secure better rates for high volumes of community users or logins. Make sure you understand Salesforce’s bundling options – for instance, “External App” licenses might offer higher login volumes if you have millions of users. Engage Salesforce or an advisor to structure a cost-effective deal for your external user population.
• Security and Compliance: Although not directly about licensing costs, remember that opening up Salesforce via Experience Cloud introduces external access. Ensure you have the right license type (customer vs partner) for the data you’re exposing – e.g., don’t try to use a cheaper Customer Community license for a scenario that requires partner-level access to opportunities, as that could violate terms. Keep external data segregated appropriately and use Salesforce’s sharing model to limit what external users see.

Best Practices to Avoid Unnecessary Full CRM Licenses in Custom App Design

Detailed Explanation:

The way you design and architect your Salesforce-based solutions can greatly impact what licenses you need. A critical best practice is to avoid “license creep” – inadvertently building a solution that forces you into higher-cost licensing for users who don’t truly need it.

By thoughtfully using custom objects, permissions, and data separation, you can ensure that users of your custom apps remain eligible for lower-cost licenses, such as Platform or community licenses, instead of requiring an upgrade to full CRM licenses. Essentially, the goal is to design around the limitations of the cheaper licenses so that those limitations don’t become roadblocks for your business processes.

For example, suppose you are building an internal project management app on Salesforce. In that case, you might be tempted to use the standard “Opportunities” object to track projects (since it has some similar stages/fields). However, doing so would mean that any user of this app would need a Sales Cloud license, because Opportunities is a sales object.

Instead, creating a custom object “Project__c” to track projects would allow those users to utilize Platform licenses. The functionality can be replicated with custom fields and automation without incurring CRM licensing. Salesforce Platform licenses even allow Accounts and Contacts, so if your custom app needs to reference companies or people, you can often use Accounts/Contacts (which are permitted for Platform users) and still avoid using, say, the “Leads” object, which is not permitted.

Key Best Practices to Consider:

• Use Custom Objects in Place of Restricted Standard Objects: Generally, for any custom application, we prefer creating custom objects over repurposing standard CRM objects, unless those standard objects are accessible with the intended license. This ensures Platform users can fully use the app. For example, use a custom “Ticket__c” object for an IT ticketing app instead of the standard Case object, so that employees can all be on Platform licenses rather than needing Service Cloud licenses.
• Limit Cross-Over with CRM Data: Be intentional about how much your custom app intermingles with core CRM records. It’s fine for a custom app to link to an Account record (since Platform users can see Accounts), but if it starts requiring related Opportunities or Campaigns, that’s a red flag. In such cases, either rethink the design (maybe the app can have its own custom “Sales Deal” object) or prepare to license those specific users with full CRM licenses. Some companies choose a mix: for example, a sales manager with a full license can see both the CRM and the custom app, whereas a general employee can only see custom app data via a platform license and is restricted from accessing CRM objects.
• Leverage Permission Sets and Settings Wisely: Salesforce’s security model can help you avoid license pitfalls. For instance, you can assign permission sets to grant specific users access to certain objects. If only a handful of Platform users truly need to occasionally access a CRM object, consider giving them a specialized permission set and purchasing a feature license or two if Salesforce offers it (Salesforce, in some cases, allows add-on licenses for specific functionality). However, be very cautious – granting access to an object that a user’s license type doesn’t normally allow can lead to compliance issues. Always verify with Salesforce if a particular combination is permitted. Generally, keep Platform user profiles clean of any CRM-only permissions.
• Monitor Custom Object Limits: Ensure your app’s design stays within the limits of your chosen license tier (e.g., don’t design a solution that needs 50 custom objects if you plan to use Platform Starter, which allows 10). If you anticipate a very complex app, opt for Platform Plus licenses or even consider whether those users need an Enterprise CRM license for higher limits. Another tactic is to spread functionality across multiple apps or use child objects instead of too many top-level objects, especially when near the limit.
• Data Storage and Integration Considerations: Platform licenses often have lower included data storage and API call limits compared to full licenses or editions. If your custom app will store large volumes of records or integrate heavily with other systems, plan accordingly. You might archive older data off-platform or purchase extra storage rather than using a full license just for the higher default storage. Similarly, for heavy integrations, you can buy API call add-ons or use middleware to reduce direct Salesforce API usage, keeping within Platform limits. This way, you avoid having to upgrade the entire user base to a higher edition because of technical limits.
• Documentation and Compliance: Document which objects and features are used by each custom application and what license type corresponds to. This helps in audits or true-ups. For instance, if an auditor or Salesforce itself checks your usage, you can clearly show that “Object X is custom and used by Platform users, who do not access standard object Y.” Staying transparent and within agreed use rights prevents any licensing violation surprises.

Enterprise Use Case Example:

A large insurance company built a broker management app on the Salesforce Platform for internal account managers to track interactions with third-party brokers. They intentionally avoided using Salesforce’s standard Opportunity object for policy sales and created a custom “Policy_Deal__c” object instead.

This design decision allowed hundreds of account managers to use the system with Platform licenses. Only a smaller team that also needed Salesforce CRM for cross-selling was given full Sales Cloud licenses. By designing the data model upfront with licensing in mind, the company saved an estimated 40% on license costs for that application and stayed in compliance.

When new features are requested for the app, the architects first evaluate whether they can be implemented within the platform’s license constraints or if a license change is required, ensuring that the cost impact is considered in their technical decisions.

Recommendations for CIOs:

• Embed Licensing into Architecture Reviews: Make it standard practice that any Salesforce solution design is reviewed for licensing impact. Your architecture review board or IT governance team should include a checkpoint: “Are we using any feature that will require a higher license for our target users?” This way, design alternatives can be considered early.
• Educate Business and Dev Teams: Often, business users or even developers may not realize that using a seemingly convenient standard Salesforce feature can trigger licensing needs. Educate stakeholders that “not all Salesforce features are equal” in terms of cost. For example, explain that while Salesforce has a Case object out of the box, using it for an internal process will require Service Cloud licenses. Offering this context can help business units be open to custom solutions that save money.
• Mix License Types Strategically: Don’t be afraid to implement a dual-license model for an app if needed – for example, 90% of users on a platform and 10% on full licenses – to cover different levels of access. Salesforce licensing isn’t all or nothing; a tailored approach often yields the best balance of cost and functionality. Just manage it carefully to avoid confusion.
• Periodically Audit Usage: Over time, your users’ needs may change. Conduct periodic audits (maybe annually, aligned with contract renewals) of whether any Platform users have requested CRM features or if any full license users never use CRM. Use Salesforce’s usage data or even surveys. Reallocate licenses based on current needs. This ensures you’re not paying for unused capabilities or inadvertently limiting someone who now needs an upgrade.
• Stay informed about licensing policies: Salesforce licensing has nuances and is constantly evolving (new license types, renamed products, etc.). Maintain a relationship with your Salesforce account team or an independent advisor to stay updated on any changes that may affect your strategy. For example, if Salesforce introduces a new type of external license or changes the limits on Platform licenses, you’ll want to know how to adjust your plans. Gartner-like insight and third-party blogs (from firms like Redress Compliance) are good resources to track for any updates on licensing rules.
• Plan for Compliance: Lastly, ensure compliance by technically enforcing limitations. For instance, use profiles or permission sets so that Platform users cannot access disallowed objects – this prevents any accidental misuse. Salesforce’s compliance audits can penalize you if, say, a Platform user is found accessing an Opportunity via API or something that should be off-limits. Designing the system to enforce the boundaries is the safest approach.

Do you want to know more about our Salesforce Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit