Platform licensing is the lever most CIOs underuse. It moves internal custom app users to a far cheaper seat. This playbook covers what it covers, when it wins, and how it is policed.
Salesforce Platform licensing is the lever most CIOs underuse. It moves internal users who never touch CRM objects to a far cheaper seat. This playbook covers what Platform covers, when it wins, and how Salesforce polices it.
Salesforce sells CRM seats by default, and most quotes assume every internal user needs one. That assumption is expensive. A large share of internal users only ever touch custom apps built on the platform, never the Sales or Service data model.
For those users, a Platform license delivers the same work at a fraction of the cost. The catch is governance. Salesforce protects CRM revenue by limiting which standard objects a Platform seat may touch.
A Platform license grants access to custom objects, custom apps, and a small set of core standard objects like Accounts and Contacts. It excludes the Sales and Service objects that define full CRM.
Platform seats include custom objects and a handful of foundational standard objects. They exclude Leads, Opportunities, Cases, and the rest of the CRM data model. The current split is published on the Salesforce Platform pricing page, and the per type object access is set out in the available license types documentation.
Platform wins whenever a user does real work in a custom app and never needs CRM objects. The test is behavioral, not organizational. It depends on what the user opens, not which team they sit on. The Salesforce Platform overview describes the custom app surface these seats unlock.
When Platform beats a full CRM seat
| User type | Touches CRM objects | Right seat | Typical saving |
|---|---|---|---|
| Custom app operator | No | Platform | 60 to 80 percent |
| Sales rep | Yes, daily | Full CRM | None, needs CRM |
| Support agent | Yes, Cases | Full CRM or Service | None, needs CRM |
| Read mostly internal user | Rarely | Light or restricted | High |
Salesforce protects CRM revenue by enforcing what a Platform seat may access. Cross the line into restricted standard objects and the account team treats it as under licensing.
The common trigger is a custom app that quietly references a restricted standard object. A report, a lookup, or a flow that touches Opportunities can reclassify the user as needing a full CRM seat. Permission set behavior is documented in the Salesforce permission sets documentation.
The common advice is to avoid Platform licenses because the compliance risk is not worth the saving. We disagree. In our engagement experience the risk is real but entirely manageable with a clean object map, and the saving is too large to leave on the table. Moving qualified users to Platform cut their per seat cost by 60 to 80 percent in the estates we reviewed. The buyer side move is to map app object access first, license to that map, govern changes through a review gate, and document the boundary so an account team has nothing to challenge. Govern the risk, do not surrender the saving.
Four moves turn Platform from a theoretical saving into a governed program. They start with discovery and end with a control gate.
The strongest defense in a licensing conversation is a written map of what each Platform app accesses. It converts a vague compliance debate into a documented position the account team cannot easily dispute.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Platform licensing is not a loophole. It is the seat Salesforce built for users who never touch CRM. The only discipline it demands is knowing what your apps actually access.
White Paper · Salesforce
Salesforce Platform CIO Playbook
How CIOs govern Salesforce Platform across clouds, custom apps, and integrations. Read it free.
A Platform license runs custom apps and a small set of core objects at a fraction of a full CRM seat. It excludes Sales and Service objects like Leads, Opportunities, and Cases.
Moving a qualified user from a full CRM seat to Platform commonly cuts that user cost by 60 to 80 percent. The saving applies only to users who never need CRM objects.
Internal users who work only in custom apps fit Platform. Operations, HR, and field staff using bespoke tools rarely touch CRM objects and are the clearest candidates.
Salesforce limits which standard objects a Platform seat may access. A custom app that references a restricted object like Opportunities can reclassify the user as needing a full CRM seat. Permission set behavior is documented in the Salesforce permission sets documentation.
The common trigger is object creep. A report, lookup, or flow inside a Platform app that touches a restricted CRM object is the usual cause. Audit object references before any move.
Light and restricted users are low cost variants for large internal populations that need read mostly access. They extend the Platform economics to users who rarely create or edit records.
The compliance risk is real but manageable. With a documented object map and a change gate, the boundary is defensible. The saving is large enough that governing the risk beats avoiding it.
Map every custom app and the objects it references. The object map is the precondition for any reclassification and the strongest evidence in a licensing conversation with the account team.
The discount audit, the uplift cap language, the reduction rights clause, the co term reset, and the population split model that beats the bundled upsell.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
Platform licensing is not a loophole. It is the seat Salesforce built for users who never touch CRM. The only discipline it demands is knowing what your apps actually access.
