Member based against login based, guest access, and the arithmetic that decides which. 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 nine, Experience Cloud, and this one is different from everything else in the course so far. Every other session has said the same thing in different words: measure what you have, then act on it. Today you cannot, because the population you are licensing does not exist yet. These are customers and partners who have not registered, using a portal that has not launched, at a frequency nobody knows. So the discipline changes. Today: the two models and the single equation that chooses between them, guest access and the money people waste by ignoring it, the capability question that comes before the volume one, and a ninety day check that makes the whole thing safe. Three knowledge checks. Let's begin.
Five objectives. First, size something that does not exist yet, which needs a different discipline from the rest of this course. Second, work the crossover, because one equation in logins per user per month decides member based against login based. Third, use guest access properly, since a public page consumes no user licence and a surprising amount of portal work is genuinely public. Fourth, ask the second question: not just how many and how often, but what these people actually need to be able to do. And fifth, run the ninety day check, which is three numbers and one hour, and it is what makes the original guess safe.
So, sizing what does not exist. Four things frame it. Unknown size, because two thousand registrations or twenty thousand are both plausible at design time. Unknown habit, and login frequency is precisely the number that decides the model. So you pick for error, choosing the model that behaves reasonably when the forecast is wrong in either direction. And then you measure, ninety days after go live, replacing the guess with three real numbers. Let me explain why this changes how you should think about it.
Guest analyst clip.
And knowing in advance which direction hurts more. That last part is the useful bit. Being over-licensed costs money and is fixable at renewal. Being under-licensed on a login pool means an emergency purchase during your busiest week, which costs money and leverage.
Right, the models, and what each one charges for. Member based charges for each named external user, monthly, used or not, and it suits populations who log in often and predictably. Login based charges for a pool of logins consumed as people sign in, and it suits large populations who visit occasionally. Guest charges nothing per user, because public pages need no licence, and it suits anything that does not require identifying the person. And there are employee style users, meaning your own staff administering or moderating the portal, who are licensed as internal users. The models are not better or worse than one another. They are bets on how often people show up, and that bet is worth calculating rather than assuming.
First knowledge check. Which number decides member based against login based? A, the size of the external population. B, logins per user per month. C, the number of pages in the portal. D, whether the users are customers or partners. Pause here and pick an answer before you continue.
B. Population size appears on both sides of the comparison and largely cancels out, so it scales the bill without deciding the model, while frequency is what actually tips it. A is the number everybody quotes, and it answers a different question. C has no bearing on licensing at all. And D is a genuinely good proxy, because partners log in often and customers rarely, but it is a proxy rather than the mechanism, so use it to form a hypothesis and then do the arithmetic.
So here is the arithmetic, and it fits on a napkin. Member cost is population times the member rate, per month, whether or not anybody arrives. Login cost is population times logins per user per month, times the login rate. Set those two equal, population cancels, and you are left with a crossover expressed in logins per user per month. Below it, login based wins, because occasional visitors should not be carried as named members all year. Above it, member based wins, because frequent users will burn through a pool faster than seats would have cost. Let me work it through properly with the shape of the numbers.
Guest analyst clip.
The model plus a right to switch at renewal. So, two worked cases and one warning. A customer portal where people check an order or a statement a few times a year sits far below the crossover, so login based. A partner portal with dealers working daily sits far above it, so member based, comfortably. The middle is the risk, because anything near the crossover can flip with a small behaviour change or a new feature. So negotiate a switch right, and check the assumption, because the estimate came from a product owner who has never run this portal before and is not being pessimistic on purpose.
And that switch right is worth asking for even when you are confident, because it costs the account team very little and it removes the entire category of being locked into the wrong model for three years.
Second knowledge check. A requirement is to publish product documentation for anybody who visits. What is the cheapest correct answer? A, login based licences, since usage will be occasional. B, guest access on a public page, which consumes no user licence. C, member based licences with self registration. D, a separate public website outside Salesforce. Pause here before you continue.
B. If the requirement does not need to identify the person, it does not need a user licence, and a surprising share of what portals are asked to do is genuinely public. A and C both license anonymous readers, which is the most common overspend in this whole area, and it happens because the project was framed as building a portal rather than as publishing information. And D is a real option that is a much bigger decision than the requirement warrants, since you then maintain the same content in two places forever.
Which brings me to two errors that run in opposite directions. Over-licensing the public, so paying per user for people who never needed to identify themselves. And under-specifying the private, meaning assuming all external users are the same when the tiers differ in what they may do. Customer style access covers seeing your own records, raising and tracking requests, reading knowledge, and that is usually enough. Partner style access covers owning records, working opportunities, managing other users in their own company, which is a different tier. Let me put both errors together, because they are two halves of the same mistake.
Guest analyst clip.
Get the second one wrong and the first one does not matter. Which is worth remembering, because the volume question is the one that gets asked in the room and the capability question is the one that decides whether the design works at all.
So let me lay out the capability ladder, from cheapest to most expensive. Read only, meaning documentation, status and published knowledge, which is frequently a guest case and frequently mis-specified as a licensed one. See their own data, so orders, cases and statements, which is the classic customer portal and the cheaper tier. Transact, meaning raising requests, submitting forms and updating their own records, which is still customer style in most designs. Work your records, so opportunities, leads and shared pipeline, which is partner style and priced accordingly. And delegate administration, managing users inside their own organisation, which is usually the top of the external range. Place your population on that ladder before anybody discusses volume.
Five failures. The model chosen by habit, so whatever the last portal used, applied to a population with completely different behaviour. Public content licensed, where anonymous readers are paid for per user because nobody asked whether identity was needed. The forecast never revisited, so a guess made at design time is still the basis of the contract three years later. Login pools that run dry, discovered in the busiest month, which is the worst possible moment to buy more. And dormant members carried, meaning named external users who registered once, never returned, and renew every single year.
Last knowledge check. Ninety days after launch, what should you do? A, nothing, the contract is fixed for the term. B, pull registrations, active users and logins per user, and compare against the assumption. C, ask the product owner whether adoption feels good. D, wait until renewal, when the data will be more complete. Pause here and pick an answer before you continue.
B. The contract is fixed and your options are not, because knowing in month four whether you were high or low decides whether you plan a reduction, negotiate a model switch, or arrange headroom before a pool runs dry. A confuses a fixed commitment with a fixed position. C collects an impression when the actual data takes an hour to pull. And D is the most common answer and it removes the lead time that makes any of this actionable, which is the same mistake as discovering a notice date late. Let me describe the check itself.
Guest analyst clip.
Ninety days, three numbers, one hour. So to be concrete. Registered users: how many external accounts exist, compared against the population you licensed for. Active users: how many logged in at all, and the gap between that and registered is your dormant population, which is worth knowing because it renews. Logins per active user, which is the number that validates or overturns your model choice. Write the comparison down, assumption against reality, so the next portal your organisation builds is sized from evidence rather than optimism. And then act on the direction: too high means a reduction to plan for, too low means headroom to negotiate now rather than during the peak.
Three sentences. External licensing is the one place in this course where you cannot measure what you have, because you are sizing a population that does not exist yet, so the skill is choosing a model that behaves reasonably when the forecast is wrong and correcting it quickly. The choice between member based and login based comes down to a single crossover in logins per user per month, where population largely cancels, and the dangerous cases are the ones near the line, which is why a right to switch model at renewal is worth more than a better guess. And guest access consumes no user licence while a surprising amount of portal work is genuinely public, the private half needs the capability question answered before the volume one, and ninety days after launch three numbers replace the guess. Next session closes module two.
Homework before session ten, about ninety minutes. One, list your external communities, what each one is for, and which licensing model it runs on today. Two, calculate one crossover using your own member rate and login rate, solved for logins per user per month, and keep that number because it is reusable. Three, pull actual login frequency for your largest portal and see which side of the crossover you are on. Four, count dormant members, meaning registered but never returned, because that population renews every year unless somebody removes it. And five, find one guest candidate: content sitting behind a login today that does not need to identify the reader at all.
Five guides, all on redresscompliance dot com. Salesforce Experience Cloud licensing covers member based against login based, the tiers and the arithmetic worked out, which is the reference version of today. Salesforce licence types explained shows where the external types sit in the full catalog. The Salesforce negotiation guide covers switch rights, headroom and reduction rights at renewal. Salesforce licensing explained puts editions, licence types and add-ons in one place. And the Salesforce licensing assessment page describes what an independent review of an estate covers.
That is session nine. The thing to take away is that you are licensing people you have never met, so pick the model that survives being wrong, use guest access wherever identity is not needed, and put a ninety day check in the diary on launch day. Next time, module two closes with limits as commercial levers: API calls, storage, sandboxes, and what an overage actually costs. See you then.