Starter, Professional, Enterprise, Unlimited, and what crossing a boundary costs. 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 three, and today is the edition ladder, which is the largest single lever on your Salesforce unit cost. I want to be fair to Salesforce about this from the start: the ladder is well designed commercial engineering, it is not hidden, and there is nothing improper about it. It simply works extremely well against buyers who do not do one piece of arithmetic. So today: what each step actually buys, how gating works, the arithmetic almost nobody performs in the room, the four routes available before you agree a tier, and a half hour review that changes the outcome. Three knowledge checks. Let's begin.
Five objectives. First, read the ladder as a design, because the boundaries sit exactly where a growing customer will need to cross them. Second, say what each step actually buys, since Professional to Enterprise is architectural while Enterprise to Unlimited is a bundle question, and those deserve different conversations. Third, do the org wide arithmetic, meaning the number the request arrives with and the number nobody calculates. Fourth, know the four alternatives: an add-on, a permission set licence, a separate org, or not this year. And fifth, run the edition gate, which is four questions and half an hour, held before anybody contacts Salesforce.
So, the ladder. Starter is for small teams and simple use, and the step up arrives quickly once processes get real. Professional is a capable application, where the ceiling tends to be automation depth and integration. Enterprise is the platform step: you build on it, you integrate properly, you automate seriously. Unlimited bundles scale, limits, sandboxes and support, which is a different kind of decision entirely. And above those sit the AI tiers, which are a third kind again and are best assessed as consumption commitments rather than feature bundles. Let me talk about what kind of object this ladder actually is.
Guest analyst clip.
It is just the right question to ask about a bundle. And that distinction, between an architectural step and a bundle, is the most useful thing in today's session, because the two are sold the same way and they are worth completely different amounts of your negotiating energy.
Right, three boundaries and three different questions. Starter to Professional gives you a real application, so pipeline, process and reporting, and the question is whether the business is genuinely outgrowing simple or just untidy, because tidiness is cheaper. Professional to Enterprise brings automation depth, configurability and proper API and integration access, and the question is whether this is architectural and whether it applies beyond one team. Enterprise to Unlimited brings higher limits, sandboxes, support and bundled extras, and the question is what is actually in the bundle and what those pieces would cost separately. And into the AI tiers you get AI capability plus consumption entitlements, where the question is whether you can forecast the consumption and who will own it. First two, usually genuine capability decisions. The third one is a bundle, and bundles deserve the question every bundle deserves.
First knowledge check. Which edition boundary is most often a bundle question rather than a capability one? A, Starter to Professional. B, Professional to Enterprise. C, Enterprise to Unlimited. D, they are all capability decisions. Pause here and pick an answer before you continue.
C. Unlimited is largely about scale, limits, sandboxes, support and bundled extras rather than a capability you cannot obtain any other way, which makes it exactly the kind of decision where pricing the components separately is worth an afternoon. A is usually a genuine outgrowing of a simple tool. B is the architectural step, where the platform becomes something you build on rather than something you use. And D is the comfortable answer that skips the analysis, and a bundle sold as a capability step is the most expensive item on that list.
So how does gating actually work? Five points. The boundaries follow the growth path, so the next capability a maturing customer needs sits on the other side of the next step, never two steps away. The request comes from inside your own organisation, because a team with a genuine problem finds a feature and the business case writes itself before licensing hears about it. The step feels proportionate: one tier, a familiar product, a demo that works, and nothing about it feels like a seven figure decision. Pricing is per user and org wide, which is the mechanic that converts a team's requirement into an estate's cost. And none of this is dishonest. It is good commercial engineering, and it works best on buyers who do not do the arithmetic.
Which brings us to the arithmetic. Two numbers, and only one of them arrives with the request. The number in the request is the people who need it times the difference, and it sounds like a departmental decision. The number that gets invoiced is every user in the org times the difference times twelve, every year. The ratio between them is your user count, so on a two thousand user estate with sixty requesters the second number is over thirty times the first. Sometimes it is still right, and if the capability changes how the whole business sells then you should buy it. But write both numbers down, on the same page, before the conversation. Let me work a real example.
Guest analyst clip.
The second one never gets calculated at all. That is the whole failure, and notice how ordinary it is. Nobody hid anything. The request was honest, the need was real, and the arithmetic simply was not performed by anybody whose job it was to perform it.
Second knowledge check, and it is that arithmetic. Two thousand users. Sixty need a capability one tier up. The tier difference is sixty dollars per user per month. What is the annual cost? A, about forty three thousand, for the sixty people who need it. B, about one point four four million, because editions apply to every user in the org. C, about a hundred and twenty thousand, once volume discounting is applied. D, nothing extra, if the org is already on an enterprise agreement. Pause here before you continue.
B. Two thousand times sixty times twelve is one million four hundred and forty thousand a year, every year, for a capability sixty people asked for. A is the number the request arrives with, which is the same arithmetic performed on the wrong population. C assumes discounting turns a thirty times multiple into a small one, and it does not. D is worth checking and is rarely true, because an enterprise agreement fixes rates and terms rather than making tier changes free. And the point is not that the answer is no. It is that nobody can judge it until both numbers are written down.
So what do you reach for instead? Four routes. An add-on, because many capabilities that gate an edition are also sold separately, and buying for sixty beats upgrading two thousand. A permission set licence, which is Salesforce's own mechanism for granting specific capability to specific users on top of their base licence. A separate org, which carries real integration cost and is occasionally still cheapest for a genuinely distinct business unit. And not this year, which gets dismissed too quickly and is how you tell a requirement from a preference. Price all four, then choose, because a decision made against four costed options is a decision rather than a reaction. Let me go through those properly.
Guest analyst clip.
Watching what happens to the enthusiasm. That sounds cynical and it is not meant to be. Genuine requirements survive the org wide number perfectly well, and it is useful for everybody, including the requesting team, to find out which kind they are holding before a contract gets signed.
A word on the AI tiers, because we will do them properly in module three. They bundle capability and consumption, which means the price you see is partly a seat and partly an entitlement to consume. The consumption is the variable, so the question is whether you can forecast it rather than whether the features are impressive, and they are impressive. Adoption decides the value, because an AI tier bought ahead of a use case is the most expensive kind of shelfware given that it is priced per seat. Ask what happens at the ceiling: what the included volume is, what overage costs, and whether unused entitlement carries. And then module three gives Data Cloud credits and Agentforce conversations three sessions of their own.
Five failures. The departmental number, where a request is priced for the team that made it and approved before anybody multiplied by the user count. The bundle bought as a capability, so Unlimited agreed for one component nobody costed separately. No add-on check, meaning an org wide upgrade for something that was available as a permission set licence all along. Upgrade first and adoption later, where the tier arrives, the project slips, and the capability is paid for and unused for two years. And never revisited, so a tier chosen for a reason that expired gets carried forward at every renewal because nobody asks why it is there.
Last knowledge check. What is the most useful control on edition changes? A, a policy that edition upgrades need CFO approval. B, a short review that prices four routes and the org wide number before Salesforce is contacted. C, an annual edition audit. D, negotiating a better upgrade rate in advance. Pause here and pick an answer before you continue.
B. The review works because it happens before a position has been taken, and because it produces a better structure rather than a refusal. A adds an approver who receives the same incomplete numbers everybody else got, only later in the process. C finds the decision a year after it was made, which is useful for next time and no use at all for this one. And D reduces the price of a change that may not be necessary, which is the wrong order and also the most common one. Let me describe the review, because it is genuinely small.
Guest analyst clip.
After the order form has been signed. So, the gate, four questions. What is the requirement, stated as a business outcome rather than a feature name, by the person who wants it. How many people need it, counted rather than estimated, because that number and your user count set the entire decision. What do the four routes cost, add-on, permission set licence, separate org or wait, with the org wide arithmetic written out in full. And what happens if we do nothing this year, which is not obstruction, it is how a requirement is told apart from a preference. Then decide, and record the reasoning, so that the next renewal knows why this tier exists. That last part matters more than it sounds, because it is the question almost nobody can answer today.
Three sentences. The edition ladder is a well engineered pricing mechanism whose boundaries sit exactly where a growing customer will need to cross them, so the capability you need is always one tier away and the upgrade always feels proportionate to the team requesting it. Editions price per user across the whole org, which means the number in the request and the number on the invoice differ by your user count, and on an ordinary estate that is a multiple of thirty or more. And before agreeing a tier there are four routes worth pricing, an add-on, a permission set licence, a separate org, or waiting, with the control being a half hour review held before anybody contacts Salesforce. Next session, licence types.
Homework before session four, about an hour, and one of these usually pays for itself. One, write down each org's edition, and the year it was chosen if anybody can find out. Two, ask why for the largest one: which requirement drove it, and does that requirement still exist. Three, do the arithmetic once, your user count times a plausible tier difference times twelve, and keep that number in your head for the rest of the course. Four, find one gated request, something a team asked for that needed a higher tier, and price the four routes on one page. And five, draft the gate, the four questions on one page, and agree with your manager who runs the review.
Five guides, all on redresscompliance dot com. Salesforce editions compared covers where the boundaries sit and what crossing one actually costs, which is the reference version of today. Salesforce licensing explained puts editions, licence types and add-ons in one document. Salesforce Sales Cloud licensing goes into what each edition includes and where the upsell boundaries sit, which is session six. The Salesforce negotiation guide covers how an edition change is best handled commercially. And the Salesforce licensing assessment page describes what an independent review of an estate covers.
That is session three. The thing to take away is that the ladder is designed, the arithmetic is thirty times bigger than the request that arrives on your desk, and half an hour of review before anybody contacts Salesforce changes the outcome more than any negotiation afterwards. Next time, licence types: full CRM, Platform, Identity, Experience Cloud, and the layer of features and permission sets underneath them. See you then.