Salesforce Platform License Limitations: Common Restrictions and How to Work Around Them

Salesforce Platform licenses are designed for internal users who need Salesforce-powered custom applications but do not require the full set of standard CRM capabilities available with a Salesforce user license.

That can make Platform licenses attractive for operational teams, back-office users, field teams, and employees working primarily with custom objects and processes. However, choosing a lower-cost license without understanding its entitlements can create problems later when users suddenly need Opportunities, Leads, forecasting, premium Service features, or other functionality outside the license.

This is why Salesforce Platform license limitations should be evaluated during solution architecture, not after an application has been built.

The goal is not simply to choose the least expensive license. It is to match each role with the objects, features, data, and processes that role actually needs.

What Is a Salesforce Platform License?

A Salesforce Platform license is an internal user license intended primarily for people who use custom applications built on the Salesforce Platform rather than the complete set of standard CRM functionality.

Salesforce describes Platform users as users who need custom apps but do not require full access to standard CRM objects. Platform users can access core capabilities including Accounts, Contacts, reports, dashboards, custom tabs, custom applications, and supported platform features. They are not entitled to certain standard CRM objects and apps such as Leads, Campaigns, Opportunities, and Forecasts.

Current Salesforce offerings include Platform Starter, Platform Plus, and Platform Login options. Salesforce’s current list pricing shows Platform Starter at $25 USD/user/month billed annually and Platform Plus at $100 USD/user/month billed annually. Starter supports up to 10 custom objects per license, while Plus supports up to 110.

The older Force.com name may still appear in legacy contracts, documentation, or orgs, but current Salesforce documentation uses Salesforce Platform and Lightning Platform terminology.

Typical Platform users include employees working in purpose-built operational apps. For example, warehouse processes, approvals, internal project tracking, field operations, or other custom workflows.

Platform licenses are for internal employees or contractors. Salesforce specifically states that Lightning Platform Starter, Plus, and Platform Login users can’t be used to perform internal or external customer service work as support agents without the required Service Cloud license.

Core Salesforce Platform License Limitations

The biggest limitation is that a Platform license is not a substitute for a full CRM license.

Salesforce Platform users aren’t entitled to key Sales Cloud objects such as:

• Leads
• Opportunities
• Campaigns
• Forecasting
• Orders
• Quotes
• Products and Price Books

However, some restrictions are more nuanced than a simple “standard objects are unavailable” rule.

Platform Starter and Plus users can work with Accounts, Contacts, Assets, Tasks, Events, reports, dashboards, custom objects, Files, Chatter, and several other platform features. Salesforce’s current licensing table also lists Case access for Lightning Platform licenses, but with an important condition: users performing customer-service work as support agents require the appropriate Service Cloud entitlement. In addition, Case availability can depend on the Service features provisioned in the org.

Reporting is available, but users can report only on data they are licensed and permitted to access. A Platform user who cannot access Opportunities cannot simply use a report to bypass that restriction.

API limits also differ by Platform SKU and edition rather than being universally “lower.” Salesforce currently documents:

• Platform Starter: 200 API calls per member per day for Enterprise or Unlimited Edition
• Platform Plus: 1,000 per member for Enterprise Edition
• Platform Plus: 5,000 per member for Unlimited Edition

These allocations contribute to the org-level API entitlement. API limits are monitored at the org level across a rolling period.

Premium products such as Revenue Cloud, advanced Sales Cloud capabilities, and other separately licensed Salesforce products are not automatically included merely because the user has a Platform license.

In short, Platform licenses provide substantial application-building capabilities, but they do not remove the entitlement boundaries associated with Salesforce’s CRM products.

Common Scenarios Where Platform License Limitations Cause Problems

License issues usually appear when the user’s real job function does not match the license selected.

A common example is assigning Platform licenses to sales representatives to reduce license cost, then discovering that those users need Opportunities, Leads, forecasting, quotes, or other core sales functionality. These are exactly the areas the Platform license is not designed to replace.

Service scenarios can create similar confusion. Salesforce currently permits certain Case access with Lightning Platform licenses under specified conditions, but a user functioning as a support agent still requires the relevant Service Cloud license.

Reporting can also expose gaps. A Platform user may be able to build reports on custom objects, Accounts, and Contacts, but not combine that data freely with restricted objects such as Opportunities.

Automation requires similar care. A Flow, Apex process, or custom component can technically participate in a larger process involving several objects, but automation should not be designed as a mechanism for bypassing user-license entitlements.

Integrations can fail for the same reason. If a third-party application expects the logged-in user to read or update Opportunities, assigning that user a Platform license does not create Opportunity entitlement.

Another common mistake is using Platform licenses for external partners or customers. Salesforce provides dedicated Experience Cloud licenses including Customer Community, Customer Community Plus, Partner Community, External Apps, and other options—specifically for authenticated external users.

How to Work Around Salesforce Platform License Limitations

Salesforce Platform license limits can often be addressed through better architecture and license segmentation. But a workaround should never be used simply to circumvent Salesforce product entitlements.

The right approach depends on what the user is actually trying to accomplish.

1. Use Custom Objects to Mirror Standard Object Data

Custom objects are one of the strongest capabilities of Platform licenses. For genuinely custom operational processes, organizations can create purpose-built objects instead of forcing users into standard CRM objects that don’t match their job.

For example, an operations team might need a custom fulfillment or installation record related to customer information but not need to manage the underlying Opportunity.

However, organizations should be careful with “mirroring” restricted CRM objects purely to avoid buying the corresponding license. Salesforce describes Platform licenses as being for custom apps rather than full CRM functionality, and license entitlements still apply regardless of the technical design.

If information is synchronized from Opportunities, Cases, or another restricted object into a custom operational model, confirm that the resulting use complies with your Salesforce order form and licensing terms.

Custom duplication also introduces:

• Synchronization complexity
• Duplicate data
• Latency
• Additional automation
• Reporting complexity
• Long-term maintenance

Use custom objects because the business process is genuinely custom not simply to recreate Sales Cloud under another object name.

2. Leverage Sharing Rules and Permission Sets

Permission sets and sharing rules solve permission problems, not license entitlement problems. Permission sets can grant capabilities that the underlying user license supports. Permission Set Licenses can also add separately purchased capabilities where Salesforce makes them available.

Sharing rules determine which records a user can see after that user already has access to the object.

For example, you can control which Accounts or custom records a Platform user sees through the Salesforce sharing model. But a permission set cannot give a Platform user Opportunity access if the user license itself doesn’t provide Opportunity entitlement.

Think of the layers in this order: License entitlement → Object/field permission → Record-level sharing

A lower layer cannot override a restriction imposed by the layer above it.

3. Build Custom Apps to Replace Standard App Functionality

Platform licenses are specifically designed for custom applications. Rather than trying to make every user work inside Sales or Service Cloud, organizations can create focused operational applications using:

• Custom objects
• Lightning App Builder
• Lightning Web Components
• Flow Builder
• Apex where necessary
• Reports and dashboards

For example, a manufacturing operations team could use a custom production or delivery-management app while sales representatives continue managing Opportunities using full Salesforce licenses.

Salesforce currently provides Platform Starter users with 10 custom objects and Platform Plus users with 110 custom objects, alongside process automation, AppExchange, and other platform capabilities. Again, the objective should be to build a genuinely distinct operational application not recreate restricted CRM products solely to avoid licensing them.

4. Use Experience Cloud for External Users

External partners, vendors, and customers generally should not be modeled as internal Platform users. Salesforce provides Experience Cloud licenses specifically for authenticated external access.

Current options include:

• Customer Community
• Customer Community Plus
• Partner Community
• External Apps
• Channel Account
• External Identity

Each provides different object, sharing, and feature entitlements. For example, Partner Community is designed for richer partner collaboration, while Customer Community licenses are aimed at customer-facing experiences.

Do not assume every Experience Cloud license provides access to Leads, Opportunities, or Cases. Object availability varies by license.

The correct approach is to map the external user’s use case - customer self-service, partner selling, vendor collaboration, and so on,to the appropriate Experience Cloud entitlement.

5. Use MuleSoft or Integration Tools to Surface Data Without Direct Object Access

Integration can help Platform users work with information that lives outside Salesforce. Salesforce Connect external objects, MuleSoft APIs, embedded applications, and other integration patterns can make external business data available inside a custom Salesforce experience.

This is particularly useful when Salesforce is not the system of record.

For example, a warehouse employee could see shipment status from an ERP inside a custom Salesforce application without copying the entire ERP dataset into Salesforce.

Integration should not, however, be used as a licensing bypass for Salesforce objects the user is not entitled to access. Surfacing Opportunity information through a custom API or embedded component does not automatically change the user’s Salesforce licensing rights.

Use integration architecture to connect systems and expose appropriately licensed information not to circumvent the underlying license model.

6. Upgrade Selectively - License Mix Strategy

In many organizations, the simplest solution is a mixed-license model. Start by grouping users according to what they actually do.

For example:

Platform users

• Custom operational apps
• Internal approvals
• Custom data entry
• Account and Contact-related processes
• Internal workflows

Full Sales users

• Leads
• Opportunities
• Pipeline
• Forecasting
• Advanced sales functionality

Service users

• Customer service operations
• Case management as support agents
• Service-specific functionality

Experience Cloud users

• Customers
• Partners
• Other authenticated external users

This prevents organizations from paying for full CRM capabilities for every internal user while ensuring that power users receive the functionality their roles require.

License optimization works best when it is based on job functions and feature requirements not simply headcount.

Salesforce Platform License vs. Full Salesforce License: Quick Comparison

Salesforce Platform pricing currently starts at $25 USD/user/month for Platform Starter, while Platform Plus is $100 USD/user/month, both billed annually. Salesforce Sales Cloud Enterprise is currently listed at $175 USD/user/month. Pricing varies by product, geography, contract, and edition and is subject to change.

A price comparison should also consider Salesforce’s Starter Suite, which is a separate SMB-oriented CRM offering currently listed at $25 USD/user/month and includes Lead, Account, Contact, and Opportunity management. It should not be confused with Platform Starter simply because the list price is similar.

The decision therefore should be based on capabilities, not license name or price alone.

Best Practices When Architecting for Platform License Users

Start by documenting what each user actually needs to do before assigning licenses.

Create a simple role-to-entitlement matrix covering:

• Objects
• CRUD requirements
• Apps
• Reports
• Automation
• Integrations
• API needs
• External vs. internal access
• Premium Salesforce features

Design Platform applications around those entitlements from the beginning. Retrofitting a custom application after discovering that hundreds of users cannot access a required CRM object can be expensive. Keep license documentation alongside your solution architecture so administrators understand why each group received a particular license.

For license monitoring, use Salesforce’s Company Information page to review purchased, used, and remaining user licenses. Salesforce also supports reporting on user license assignments through a custom report type.

Do not use the License Management App as a general customer-org license monitoring tool. Salesforce’s License Management App is intended for AppExchange developers and publishers to manage licenses for installed managed packages.

Finally, review assignments periodically. Job responsibilities change, and a Platform user who originally needed only an internal application may later take on a sales, service, or integration role requiring a different entitlement.

How Softsquare Helps Businesses Navigate Salesforce License Complexity

Salesforce licensing decisions can directly affect architecture, user experience, implementation cost, and long-term maintainability.

Softsquare helps organizations evaluate Salesforce licenses alongside their actual business processes rather than treating licensing as a purchasing exercise separate from solution design.

This can include:

• User-role and license assessment
• Platform vs. full CRM license analysis
• Object and feature entitlement mapping
• Custom application architecture
• Experience Cloud license planning
• Integration-user strategy
• Platform Starter vs. Platform Plus assessment
• Mixed-license architecture
• Permission and sharing design
• License utilization reviews

The objective is to find the right balance between functionality and cost without designing solutions that depend on unsupported or questionable license workarounds.

Conclusion

Salesforce Platform licenses can be a strong option for organizations with large groups of internal users working primarily in custom applications. But they come with clear boundaries.

Platform users do not receive the complete Sales Cloud or Service Cloud feature set, and permissions, sharing rules, automation, or integrations cannot simply override restrictions imposed by the user license.

The most effective strategy is therefore not to ask, “How can we make every user work with a cheaper license?”

Instead, ask, “What does each user actually need to do?”

From there, organizations can combine Platform, full CRM, Service, Experience Cloud, and other licenses where appropriate while designing custom apps around genuine operational requirements.

That approach delivers more sustainable cost optimization and avoids discovering critical license restrictions after the architecture has already been built.