Full CRM, Platform, Identity, Experience Cloud, and the permission set layer beneath them. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 4 times in the session the frame splits and a senior licensing analyst gives the view from inside real SAP negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back. Session four, and today is the part of Salesforce cost that is entirely inside your own control. Last time we did editions, which are visible, debated and expensive. Today is the ladder underneath them, the licence type on every individual user, which is invisible, undebated and also expensive. Full CRM, Platform, Identity, the Experience Cloud family and the free tiers, where the boundaries sit, the one Platform mistake that turns a saving into a contractual problem, and a quarterly review that takes an afternoon and reliably finds money. Three knowledge checks. Let's begin.
Five objectives. First, see the second ladder, because editions get debated while licence types default silently to the most expensive option. Second, name every type you will meet: full CRM, Platform, Identity, the Experience Cloud family and the free tiers. Third, place the Platform boundary precisely, since that line is what you are paying the difference for. Fourth, do the Experience Cloud arithmetic, which comes down to a single number almost nobody asks for at design time. And fifth, run the quarterly review: four piles, one afternoon, done before the renewal rather than after it.
So, the second ladder, four things. There is no approval needed, because issuing the most expensive seat requires nobody's sign off and always works first time. There is no audit, so over-licensing is invisible to the vendor: it costs you rather than exposing you, which means nothing external will ever prompt a correction. It accretes, so three years of sensible individual decisions produce a population nobody actually chose. And it is cheap to fix, because the correction is a downgrade at renewal rather than a negotiation or a project. Let me describe how this actually happens, because it is nobody's fault in particular.
Guest analyst clip.
It is simply money leaving quietly. And I want to underline the point about no audit, because it cuts both ways. It means this is not a risk you need to lose sleep over. It also means nothing will ever force you to look, so if you do not schedule the review, it does not happen.
Right, the catalog. Five families, and each one answers a question. Full CRM is for sales and service work, so opportunities, leads, cases and forecasts, and the test is whether this person works deals or cases. Platform is for custom applications plus the core objects, and the test is whether they need your apps but not sales and service. Identity is single sign on rather than application work, so the test is whether they only need to authenticate. Experience Cloud is for people outside your company, customers and partners, where the test is whether they are external and how often they log in. And the free tiers cover collaboration and limited read access. The right question is never which licence is standard here. It is what is the least expensive type that lets this person do their actual job.
First knowledge check. A finance analyst opens Salesforce twice a week to read three dashboards. What should they hold? A, a full CRM licence, since they need real data. B, the cheapest type that permits reading those reports, usually Platform or lower. C, no licence, they should be sent exports. D, an Experience Cloud login. Pause here and pick an answer before you continue.
B. Access to real data is not the same thing as needing sales and service functionality, and reading dashboards is exactly the use case the cheaper types exist for. A is the default that creates most of the waste in this session, and it gets chosen because it is quick rather than because it is right. C solves a licensing problem by creating a data governance one, which is a poor trade and usually ends with spreadsheets in email. And D is for people outside your organisation, and an employee is not that.
So where exactly is the boundary? Platform gets your custom apps, which for many internal users is the entire reason they log in. Plus the core objects: accounts, contacts, reports and dashboards, which is enough for most internal process work. What it does not get is the sales objects, so opportunities, leads, forecasts and campaigns sit on the other side of the line. And it does not get the service objects, so cases and the service console belong to the Service Cloud side and are licensed accordingly. That line is the product. The price difference between the types is the price of that functionality, which is exactly why what happens next matters.
Five points on Platform. It is ideal for internal process users: operations, finance, the HR adjacent teams working in apps you built rather than in the sales pipeline. Check the object limits, because Platform tiers cap how many custom objects a user can reach, so size it against the apps they actually use. Do not rebuild the excluded objects. Technically fine is not the test, because the platform will happily let you build it and the licence terms are what decide whether you may. And write the rule down for your architects. Let me be precise about this, because it is where good engineering creates a bad position.
Guest analyst clip.
Get that right and Platform is excellent value. And notice that this is the same shape as the restricted use trap in the IBM course, if you took that one. Somebody sees spare capability, uses it sensibly, and the licence says that particular use is the thing you have not bought.
Second knowledge check. Platform users need opportunity data. An admin builds a custom object that mirrors it and syncs the records across. What is your position? A, fine, custom objects are what Platform licences are for. B, fine, provided the data is read only. C, this delivers the functionality the licence excludes, so it is a contractual problem. D, fine, since no additional licences were purchased. Pause here before you continue.
C. The distinction between the licence types is the functionality, not the technical mechanism used to deliver it, and rebuilding an excluded object to serve users who are not licensed for it is precisely the pattern the terms are written to prevent. A is true of genuine custom applications and not of clones of excluded objects. B invents a read only exemption that the licence does not contain. And D confuses cost with entitlement: nothing was bought, and that is exactly the issue.
Now Experience Cloud, which is an arithmetic problem. Member based charges per named external user per month, whether they log in or not, which suits daily users. Login based consumes a pool, so you buy logins and spend them as people actually sign in, which suits occasional users. The deciding number is login frequency, so ask the product owner at design time and then check it against reality after one quarter. Partner portals lean member based, because dealers working daily will exhaust a login pool faster than seats would have cost. And customer portals lean login based, because people checking an order twice a year should not be carried as named members all year. Let me work through how this fails.
Guest analyst clip.
Because their estimate will be wrong. That is not a criticism of product owners, it is just what happens with usage forecasts. The discipline is not getting the estimate right, it is checking it after a quarter and being willing to change the model at the next renewal.
One more layer, beneath the licence type. Feature licences switch capability on, granted on top of a user licence, often included in quantity and often completely forgotten about. Permission set licences add products, so analytics, engagement tooling, field service and AI capability, assigned per user rather than org wide. This layer is the alternative to a tier change, which is where session three's four routes actually live: buy the capability for the people who need it. They are countable, because assignments are visible in the org, so unused ones are findable and reclaimable. And review them alongside the licences, because an unused permission set licence is shelfware with the same annual cost as any other line.
Five failures. The default is the expensive one, because provisioning copies the last user's profile and the last user was a salesperson. Integrations on human seats, holding full CRM licences for years and invisible because nobody logs in as them. Excluded objects rebuilt, so a well built custom clone delivering exactly what the cheaper licence excludes. The wrong Experience Cloud model, designed for occasional users and licensed per member, or the reverse, and found out at the worst possible moment. And never reviewed, so the population drifts upward for years and is renewed at whatever it has drifted to.
Last knowledge check. When should licence type corrections be made? A, whenever they are noticed, mid term. B, before the renewal, so the corrected count is the base the renewal prices. C, at the renewal meeting itself, as a negotiating lever. D, after the renewal, once the new term is agreed. Pause here and pick an answer before you continue.
B. Quantities are set at renewal and rarely reduce mid term, so a correction made afterwards is one you pay for anyway until the next cycle. A is right in spirit, and the commercial effect usually cannot land until the term ends, though doing the work early is exactly what makes B possible. C arrives too late to be verified and reads as a bargaining tactic rather than a fact. And D is the most common pattern and the most expensive, because it locks the inflated base in for another term. Let me describe the review that produces the corrected number.
Guest analyst clip.
Four piles, one afternoon, four times a year. So to lay that out properly. Pull the list: every user with licence type, profile and last login date, which is one export. Pile one, dormant: no login in ninety days, so leavers, movers and long absences, all sitting at full price. Pile two, over-licensed: full CRM seats whose real usage is reading, which is a Platform or an Identity conversation. Pile three, not people: integrations and service accounts, where the question is the minimum type that does the job. And pile four, correct, which is usually the majority and is worth saying out loud, because a review that only reports errors gets read as an accusation and stops being welcome.
Three sentences. Salesforce has a second, invisible ladder beneath the editions, and because issuing the most expensive licence type needs no approval and always works, estates drift upward through years of individually sensible decisions that nobody ever made deliberately. Platform is the largest saving available and it carries one rule that matters: the boundary is the sales and service functionality, so rebuilding an excluded object to serve users who are not licensed for it delivers exactly what the cheaper licence excludes. And Experience Cloud is an arithmetic problem decided by login frequency, while every one of these corrections belongs before the renewal, because the base you renew on is what every future increase multiplies. Next session, the entitlement baseline.
Homework before session five, about two hours, and this one usually finds money. One, run the four pile review once: licence type, profile, last login, and count each pile and write the numbers down. Two, price pile one, so dormant users times your per user rate times twelve, which is the annual figure and it is the one to show your manager. Three, find your integration accounts, list them by name and note what licence type each one holds today. Four, check your Experience Cloud model, member or login based, and what your actual login frequency has been this year. And five, list the assigned permission set licences and how many of each are genuinely being used.
Five guides, all on redresscompliance dot com. Salesforce licence types explained compares full CRM, Platform, Identity and the Experience Cloud family, which is the reference version of today. Salesforce Platform licensing covers what Platform includes, the limits, and where misuse begins. Salesforce Experience Cloud licensing works the member against login arithmetic properly. Salesforce licensing explained puts editions, licence types and add-ons in one document. And the Salesforce licensing assessment page describes what an independent review of an estate covers.
That is session four. The thing to take away is that the licence type ladder is invisible, it only ever drifts upward, nobody outside your organisation will ever make you look at it, and an afternoon a quarter fixes it. Next time, the entitlement baseline: what the order forms say, what the org actually contains, and the gap between the two. See you then.