What each edition includes, and the features that quietly require the next tier. 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 six, and module two opens on the biggest line in most Salesforce estates. Sales Cloud. Module one gave you the landscape, the paper, the edition ladder, the licence types and the baseline. Now we start going product by product, and we start here because for most organisations this is where the majority of the seats and the majority of the money sit. Today: the three quite different products bundled into that one line, what an edition step actually buys, the requests that look like configuration and turn out to be purchases, and why the licence should follow the work rather than the org chart. Three knowledge checks. Let's begin.
Five objectives. First, separate the three products, because record keeping, automation and intelligence arrive as one line and behave completely differently. Second, say what an edition step actually buys, which is mostly automation depth and configurability. Third, recognise the quiet boundaries, meaning requests that look like an afternoon of admin work and turn out to be a purchase. Fourth, question the org chart, because the licence should follow the work somebody does rather than the department they sit in. And fifth, build the role map, which is the artefact that stops the drift restarting the moment you have finished cleaning it up.
So, three products in one line. Records: accounts, contacts, opportunities, pipeline, which every edition has. Automation: how much process the system enforces rather than merely records, which is where the editions genuinely differ. Intelligence: forecasting depth, analytics and the AI layer, which is where the money has moved in the last few years. And the fixes are different, because automation is an edition question while intelligence is increasingly an add-on question. Let me lay that out, because naming the layer changes what you should buy.
Guest analyst clip.
Add-ons can be bought for the people who need them. That distinction is the useful one to carry into any upgrade conversation, and it is a genuinely reasonable question to ask a sales director, because they usually know exactly which of the three they are frustrated by.
Right, what the edition step actually changes. Process automation goes from basic rules and simple flows to real depth, complexity, and the enforcement of an actual sales method. Configurability goes from standard structures to more objects, record types and profile control. Forecasting goes from straightforward pipeline views to hierarchies, overlays, multiple currencies and richer models. Territory and approvals go from simple assignment and routing to territory management and multi step approval structures. And integration goes from limited API access to full API access, which is very often the real reason an organisation moves. Notice how many of those rows are about the platform behaving like enterprise software rather than about new sales features. That is the honest description of the step, and it is worth being honest about it, because it is also a legitimate thing to need.
First knowledge check. A sales director asks for better AI forecasting. What is the first question? A, which edition includes it. B, whether it is available as an add-on, and how many people need it. C, what the discount would be on the upgrade. D, whether the current forecast is accurate. Pause here and pick an answer before you continue.
B. The intelligence layer is where add-ons are most likely to exist, and buying capability for the sales leadership who actually need it beats moving every seat in the organisation. A jumps to the most expensive route before checking the cheaper ones, which is session three's mistake wearing a different hat. C negotiates a change that may not be necessary at all. And D is a genuinely good question about whether the requirement is real, and it lands much better after you know what the options cost, because asked first it just sounds like obstruction.
So, the quiet boundaries, five of them. Sophisticated approval routing, multi step and conditional with delegation, which sounds like admin work and sits above a boundary. Territory management, which arrives whenever the sales organisation restructures, so roughly every other year. Richer forecasting, meaning overlays, multiple currencies and a hierarchy that matches how the business actually runs. Full API access, usually discovered by an integration project rather than by the sales team, and frequently the real driver behind an upgrade. And more record types and objects, which is the ceiling nobody notices until an implementation partner hits it in the middle of a build.
Now, how the request actually reaches you. The business asks for a capability, in good faith, describing an outcome rather than a product tier. An administrator investigates and discovers, correctly, that it needs the tier above or a separate product. A business case gets written, with a date, a sponsor and an expectation. Licensing hears last, at which point saying anything other than yes reads as blocking the business. So the intervention is not to say no more often, it is to change when you hear. Let me be specific about that.
Guest analyst clip.
Tell me that day, not when the business case is written. That single request, sent once to your administrators, is the cheapest control in this session, and administrators generally like it, because it moves the licensing conversation off their desk and onto yours.
Second knowledge check. What is the cheapest intervention in this whole pattern? A, negotiating a better rate for edition upgrades in advance. B, being told the day an administrator discovers a request needs a higher tier. C, requiring finance approval for all upgrades. D, reviewing edition usage annually. Pause here before you continue.
B. Early notice is free, and it is the only intervention that arrives while the alternatives are still cheap to explore, which is the entire difference between choosing a route and ratifying one. A prices a decision rather than examining it. C adds an approver at the end of the process who receives exactly the same momentum everybody else did, and who is now the person blocking the business. And D finds out a year later, which helps the next case and does nothing for this one. The ask is one sentence long and costs nothing at all.
So let us question the org chart. Account executives own opportunities and move them through stages, and they clearly need Sales Cloud. Sales operations build reports, manage data and run the process, which is often a different and cheaper answer. Sales support handle quotes and administration, worth testing against Platform before assuming. Managers who mainly read dashboards are frequently over-licensed by default. And the marketing adjacent group look at pipeline and never touch it, so they almost never need what they have been given. Let me put the question directly, because almost nobody asks it.
Guest analyst clip.
I have never known it not to find anything. And the reason to do it with sales operations rather than alone is not just accuracy. It is that a recommendation carrying their name lands completely differently with the sales leadership than one carrying only yours.
A word on the add-on layer, because it is where capability gets bought per person. Engagement and productivity tooling, so cadences and sequences, which the people who prospect need and everybody with a seat does not. Analytics, assigned per user, so the people building analysis pay for it while the audience does not. Quoting and revenue tooling, needed by the deal desk and a subset of sellers rather than by the whole organisation. AI capability, increasingly the route into the intelligence layer, priced per user or per consumption. And all of it is reclaimable, because assignments are visible in the org, so an unused add-on shows up in the same export as everything else in session four.
Five failures. The department gets one licence type, so everybody in sales gets what the sellers get because that is what sales gets. Intelligence bought as an edition, when the capability was available as an add-on for the twelve people who actually wanted it. Licensing told last, so the only remaining question is the discount on a decision already made. Add-ons assigned and forgotten, provisioned for a pilot, never withdrawn, and renewed every year since. And no role map, so every new starter is a fresh judgement call and the drift restarts immediately after you finish cleaning it up.
Last knowledge check. What stops the estate drifting back after a cleanup? A, a policy document on licence assignment. B, a role map that tells provisioning what each job title gets. C, quarterly reviews. D, restricting who can create users. Pause here and pick an answer before you continue.
B. Drift happens at provisioning time, one user at a time, so the fix has to live at provisioning time and it has to make the right answer the easy answer. A is read once and remembered by nobody at the moment of decision. C detects drift after it has happened, which is necessary and is not prevention. And D creates a queue and an irritated administrator, while the person in the queue still has to guess. The map removes the guess, which is exactly why it works. Let me describe it.
Guest analyst clip.
The moment you have finished cleaning it up. So, the map. One row per job title, as the business names it, so people recognise themselves in it. How many hold it, which doubles as the org wide arithmetic for any future request from that group. What they do in Salesforce, one sentence, written with somebody from sales operations who actually knows. The licence and add-ons that role should carry, which is the column provisioning reads. And reviewed with the quarterly export, because roles change and a map that ages quietly is worse than no map at all, since people will trust it.
Three sentences. Sales Cloud arrives as one line and contains three quite different products, and since record keeping is a solved problem, an upgrade request is really about automation depth, which is an edition question, or about the intelligence layer, which is increasingly an add-on question. The expensive boundaries are the quiet ones, because approval routing, territory management, richer forecasting and full API access all look like configuration and are purchases, and by the time licensing hears about one there is usually a business case with a date on it. And the licence should follow the work rather than the org chart, with the role map as the artefact that makes it stick, because drift happens one user at a time at provisioning and that is where the fix has to live. Next session, Service Cloud.
Homework before session seven, about two hours and mostly one conversation. One, list the roles in your sales organisation by job title with a headcount against each, which is twenty minutes from an HR export. Two, sit with sales operations for an hour and write one sentence per role describing what they actually do in Salesforce. Three, mark the ones you would test, meaning any role whose sentence does not include working opportunities or cases. Four, list the assigned add-ons by role, and ask whether the pilot each one came from ever actually finished. And five, send one email to your administrators asking to be told the day a request turns out to need a higher tier. One sentence, and it is the highest return message you will send this quarter.
Five guides, all on redresscompliance dot com. Salesforce Sales Cloud licensing covers what each edition includes and where the upsell boundaries sit, which is the reference version of today. Salesforce editions compared prices the tier boundaries with the org wide arithmetic. Salesforce licence types explained is for deciding what each role in the map should carry. The Salesforce negotiation guide covers handling an upgrade commercially once the requirement is genuinely real. And the Salesforce licensing assessment page describes what an independent review covers.
That is session six. The thing to take away is that one order form line hides three products, the expensive requests look like configuration, and a role map beats a policy every time because it works at the moment somebody is actually deciding. Next time, Service Cloud: agents and supervisors, Digital Engagement, and the channel add-ons that arrive separately. See you then.