When they genuinely work, the object limits that size them, and the misuse that creates exposure. 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 eight, Platform licences, and I will say plainly that this is the highest value session in module two. Session four introduced the licence type ladder and drew the Platform boundary. Today we go properly into it, because for most organisations this is the largest saving available anywhere in the estate, it needs no negotiation with Salesforce at all, and the reason it goes unclaimed is not that anybody made a bad decision. Today: the right question to ask, who the candidates are, how the tiers are actually sized, the three ways this gets misused, and how to migrate a population without breaking somebody's job. Three knowledge checks. Let's begin.
Five objectives. First, ask the right question, which is not what Platform includes but what your users actually do all day. Second, identify the candidate population: people working in applications your own team built who never touch a deal or a case. Third, size against the object limits, because the tier boundary is a count of custom objects and that is what decides whether it fits. Fourth, recognise all three misuses, two of which are honest mistakes and one of which is a control problem rather than a licensing one. And fifth, migrate a group properly, in five steps, landing at a renewal so the saving is actually real.
So, the right question. Four things frame it. Custom apps: onboarding, compliance, asset registers, request queues, all things your team built. Never deals, because these users would genuinely not notice if the sales objects vanished overnight. Same licence, and yet almost all of them hold what an account executive holds. And unowned work, because finding out takes a week of unglamorous review that nobody's job description covers. Let me explain why comparing feature lists is the wrong starting point.
Guest analyst clip.
On a population of a few hundred it is a very large number. And notice the last point in that: the reason this persists is not ignorance, it is that the work has no owner. Which means the fix is not education, it is somebody being given the week.
Right, five populations worth testing first. Internal process users, so operations, facilities and compliance, working entirely in apps your team built. Approvers, which is people who open Salesforce to approve something and then leave, and that is a very common and very expensive group because approval is such a small slice of work. Data and admin staff maintaining records in custom objects rather than working the pipeline. Read only management, the dashboard consumers, though do check whether those dashboards sit on excluded objects, because that changes the answer. And integration accounts, which are not people at all and rarely need anything close to a full CRM seat.
First knowledge check. Which group is the strongest Platform candidate? A, sales managers who review pipeline dashboards weekly. B, compliance staff working entirely in a custom app your team built. C, service agents handling a small case volume. D, partners who need occasional access from outside the company. Pause here and pick an answer before you continue.
B. Custom applications are exactly what Platform is for, and a population that never needs the sales or service objects is the clean case. A is tempting and needs a check, because pipeline dashboards are built on opportunity data, which is an excluded object, so that one turns on the detail. C fails on grounds that have nothing to do with volume: handling cases at all is service work. And D is external, so it belongs to the Experience Cloud family we cover next session rather than to Platform.
Now the tiers, and what actually separates them. Custom objects: how many the user can reach, and this is the single most important sizing question you will ask. Standard objects like accounts, contacts, reports and dashboards are included, which is why most internal applications still work. Excluded objects, so opportunities, leads, cases and forecasts, which is the boundary you are paying the difference for. Tabs, meaning how many custom tabs are available, which is rarely binding and occasionally the thing that trips a rollout. And automation and API, which follow the org edition rather than the user licence, so a Platform user in an Enterprise org is not crippled. Notice that the sizing question is a count rather than a feature comparison, and that is the practical difference between a successful migration and a failed one.
So, sizing before you move. Count the group's objects rather than the org's, because the org total is usually alarming and completely irrelevant to this decision. Comfortably inside the tier is a yes, and headroom matters because applications grow after you stop looking at them. Close to the boundary is a warning. Far outside is useful information rather than a failure. And record the footprint, so the next similar group takes an afternoon rather than a week. Let me explain why the object count is the number that decides everything.
Guest analyst clip.
You have saved yourself a failed migration. Which is a real outcome worth counting. A group you correctly decide not to move is a good result from this exercise, not a wasted week, and it is worth framing it that way when you report back.
Second knowledge check. Platform users receive opportunity data through a report rather than a record page. Does the mechanism matter? A, yes, reports are a different feature from record access. B, no, the question is what functionality the user receives. C, yes, provided the report is read only. D, only if the report is scheduled and emailed. Pause here before you continue.
B. Licence boundaries are drawn around functionality rather than around the mechanism used to deliver it, which is exactly the same principle as the custom object clone from session four. A, C and D each propose that a technical route around the boundary changes the position, and each is the kind of reasoning that produces a finding rather than a defence. And there is an honest consequence worth stating: if a Platform population genuinely needs opportunity reporting, then they may not be Platform users at all, and it is much better to learn that before the migration than after it.
So, three ways this goes wrong. The clone, which is a custom object mirroring an excluded one with data synced across, well intentioned and still delivering the excluded functionality. The report route, where excluded object data reaches Platform users through reports on the theory that the mechanism matters. And shared logins, one licence used by several people, which is not an optimisation and is not primarily a licensing issue at all. The first two are honest and get fixed with a rule at design time. The third is different. Let me be precise about all three.
Guest analyst clip.
Fix it as a control issue rather than as a licensing one, and fix it quickly. And I would add that raising it that way is also more effective. A security and audit finding gets sponsorship and a deadline. A licensing observation gets added to a backlog.
A little more on shared logins, because it is worth understanding why it is a separate category. Most agreements prohibit it outright, since named user licensing means one credential and one human, and that is the model you bought. It destroys your audit trail, because every action is attributed to an account rather than a person, which matters far beyond licensing. It is a security exposure, since shared credentials cannot be revoked cleanly when one of those people leaves. And it usually starts small, as a temporary arrangement during a busy period that quietly became the way that team works, which is why nobody involved thinks of themselves as doing anything wrong.
Five failures. Migrating on a survey, which means asking people what they use, and they will tell you what they remember rather than what the admin view shows. Ignoring headroom, sizing to today's object count with no allowance for the application growing. Moving everybody at once, so one visible breakage becomes the story and the next migration never gets approved. Downgrading mid term, when the entitlement is already paid for, so the saving does not land until the renewal. And no design rule afterwards, so six months later somebody builds the clone in good faith and quietly undoes the entire exercise.
Last knowledge check. When should a Platform downgrade take effect for the saving to be real? A, immediately, so the entitlement is freed. B, at the renewal, since the current term is already paid for. C, at the end of the financial year. D, as soon as the pilot group confirms nothing broke. Pause here and pick an answer before you continue.
B. Subscription quantities are committed for the term, so a mid term downgrade frees an entitlement you are still paying for and changes nothing on the invoice until the renewal reprices the base. A is worth doing operationally and it is not where the money appears. C is your calendar rather than the contract's. And D confuses the technical decision with the commercial one, when in fact both matter: do the work early, land it at the renewal. That timing is exactly why the reduction right from session two is worth negotiating. Let me describe how to run the migration itself.
Guest analyst clip.
Makes the next one much harder to get approved. So, five steps. Pick one group, the most obviously suitable one, and prove the method before you scale it. List objects and features from the admin view, meaning observed usage rather than a survey. Test with volunteers, a handful of people over a fortnight, and ask them directly what broke rather than waiting for tickets. Land it at the renewal, so the commercial saving is real rather than an unused entitlement sitting in the org. And write down the footprint, because the next similar group then becomes an afternoon instead of a week, and that is how this scales from one saving into a routine.
Three sentences. The useful Platform question is not what the licence includes but what a population actually does all day, because most estates carry a sizeable group working entirely in applications the organisation built itself while holding the same licence as an account executive. The tier boundary is a count of custom objects rather than a feature comparison, so sizing means counting what that group's application touches, with headroom, and discovering early when the cheaper licence was never the right answer. And two of the three misuses are honest mistakes fixed by a design rule, while shared logins are a control and audit failure that should be raised as such, and the saving only lands when the change takes effect at a renewal. Next session, Experience Cloud.
Homework before session nine, about three hours, and I would argue this is the highest value homework in the whole course. One, name three candidate groups, meaning populations working mainly in custom apps, with a headcount against each. Two, count the objects for one of them, from the admin view, because that is the number that decides whether this works. Three, price the move: headcount times the difference between the licence types times twelve. Four, check for shared logins by looking for accounts with implausible login patterns, and raise anything you find as a control issue rather than a cost one. And five, draft the design rule, one sentence for your architects: Platform users get custom apps, not rebuilds of excluded objects.
Five guides, all on redresscompliance dot com. Salesforce Platform licensing covers what Platform includes, the tiers and limits, and where misuse begins, which is the reference version of today. Salesforce licence types explained is the full catalog, for placing each population correctly. Salesforce licensing explained puts editions, licence types and add-ons in one document. Salesforce renewal preparation covers landing a downgrade at the moment the base is repriced. And the Salesforce licensing assessment page describes what an independent review of an estate covers.
That is session eight. The thing to take away is that the biggest saving in your estate needs no negotiation, it needs one person with a week and an admin export, the sizing question is a count of objects, and the change has to land at a renewal to be worth anything. Next time, Experience Cloud: member based against login based, guest access, and the arithmetic that decides which model you want. See you then.