Creator, Explorer and Viewer, embedded analytics, and the overlap with CRM Analytics. 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 seventeen, Tableau, and after last week this will feel like a holiday. We are counting people again. Three tiers, a large price gap between them, and a licence assignment that is entirely within your control, which makes this one of the few lines in the portfolio you can improve without negotiating anything at all. So today: the ladder and what genuinely separates the tiers, why estates drift upward, the embedded analytics question that named user pricing handles badly, and the overlap with CRM Analytics that most organisations are paying for without ever having decided to. Three knowledge checks. Let's begin.
Five objectives. First, place people on the ladder: Creator, Explorer and Viewer, and what genuinely separates one from the next. Second, spot role drift, because estates settle upward and the Creator count is almost always the wrong one. Third, answer the embedded question, since analytics shown to people who never open the tool needs a different treatment. Fourth, handle the overlap honestly, because Tableau and CRM Analytics do similar work and most estates pay for both. And fifth, run a role review, meaning usage per role twice a year, which is the cleanest reduction available anywhere in this portfolio.
So, three roles, one ladder. Creator builds data sources and workbooks, and it is the expensive tier and the smallest real population. Explorer works with what exists, filtering, editing and exploring, and it is where most analysts genuinely sit. Viewer reads and interacts with published content, and it is the largest population by far. And the gap between tiers is large, so a wrong assignment is expensive every single year it persists. Let me explain why this one is worth your attention even though it looks like housekeeping.
Guest analyst clip.
Nobody needs to negotiate anything to fix a licence assigned at the wrong tier. That is genuinely unusual. Everywhere else in this course the fix requires the other side to agree to something. Here it requires only that you look.
Right, what each role can actually do, and the boundary that matters. Creator: connect to new data, prepare it, author from scratch, publish. The test is whether they build new data sources, or only new charts from existing ones. Explorer: edit and create from published data, deep interaction, own content. The test is whether they change what is shown rather than just read it. Viewer: view, filter, subscribe, interact with published dashboards. The test is whether they consume and never author anything anybody else sees. And the crucial point is that the Creator boundary is about connecting and preparing data, not about building things, because a great many Creators in a typical estate author only from data somebody else prepared for them.
First knowledge check. An analyst builds dashboards every week from data sources the data team publishes. What tier? A, Creator, because they build dashboards. B, Explorer, because they author from published data rather than connecting new sources. C, Viewer, because the data is prepared for them. D, Creator, because they work with the tool every week. Pause here and pick an answer before you continue.
B. The line is data preparation and connection rather than authoring, and this is the single most valuable distinction in Tableau licensing, because it moves a large population down a tier. A and D are the intuitive answers and they are exactly how estates end up with three times the Creators they need: building things feels like creating, and frequent use feels like seniority. And C goes too far, because a Viewer cannot author at all, and downgrading a working analyst to Viewer breaks their job and gets the whole exercise discredited, usually permanently.
So why do estates settle at the top of the ladder. Nobody is refused an upgrade, because asking for Creator is easy and refusing it makes somebody look obstructive. The default was set early, so a pilot licensed everybody as Creator and the pattern outlived the pilot by years. Roles never come back down, because a project needed Creator for six weeks and the licence stayed for three years. Seniority gets confused with tier, so senior people are given Creator as a courtesy rather than because they connect data. And nobody measures, which is the one that ties it together, because the usage data that would settle every one of these arguments is sitting there unread. Now, the embedded question.
Guest analyst clip.
Analytics for people who never open the tool. So: dashboards inside another application, shown in a portal or a product, to people who would not recognise the tool by name. The population is different, being large, occasional and often external, which named user pricing fits badly. And there are dedicated models, embedded and usage based arrangements that exist and are not the default quote.
So ask before you build, because the licensing answer changes the design and rework here is expensive. And watch the external boundary in particular, since showing analytics to customers or partners is a different agreement from internal use, and that distinction has caught out organisations who thought they were simply adding a page.
Second knowledge check. You want to show three charts to twenty thousand customers inside your portal. What do you do first? A, buy twenty thousand Viewer licences. B, ask which embedded or usage based model applies before designing it. C, build it and license it once usage is known. D, export the charts as images on a schedule. Pause here before you continue.
B. Named user pricing was designed for a workforce and it fits an external audience badly, so the first move is finding out which arrangement covers this case, because the answer changes the architecture as well as the price. A prices the wrong model at the largest possible scale. C is how organisations end up negotiating after the build, with a live customer facing feature as the other side's leverage. And D is a genuinely reasonable answer for three static charts and worth pricing, and it stops being reasonable the moment anybody asks for a filter.
Which brings us to the overlap. Two answers to one question, both on your invoice. Both do analytics on Salesforce data, with different strengths and a large area where either would serve. They arrived separately, one through an acquisition and one through the platform, and neither replaced the other. Different buyers and different budgets, which is why nobody noticed until somebody read both order forms side by side. Adoption is usually lopsided, so in most estates one of them is genuinely used and the other is merely licensed. And you measure before you decide: active users, content created, content viewed. Let me be direct about how this conversation usually goes.
Guest analyst clip.
The data settles it quickly, which is the point. This is an argument that runs for years on preference and finishes in twenty minutes on evidence, provided somebody is willing to pull the numbers before the meeting rather than during it.
So how to run the consolidation question properly. Start from usage rather than preference, meaning which platform has real adoption measured over a quarter rather than asserted in a meeting. Separate the genuine strengths, because some workloads sit clearly with one tool and naming them is more useful than arguing in general terms. Cost the migration honestly, since rebuilding dashboards is real work and it usually exceeds one year of the saving. Then decide the direction: consolidate toward the one with adoption, over a term, rather than in a single release. Or keep both deliberately, because a decision to run two platforms is entirely defensible, while running two by accident is not.
Five failures. Everybody a Creator, the pilot default never corrected and multiplied across the whole estate. Dormant licences renewed, for people who left the team, the project or the organisation. Embedded discovered late, with an external audience designed in and licensed afterwards at named user rates. Two analytics platforms by accident, where nobody chose to run both and nobody has ever been asked to justify it. And reduction proposed without evidence, so a downgrade suggested on instinct, resisted successfully, and never raised again, which is worse than not proposing it at all.
Last knowledge check. What is the strongest basis for proposing a tier downgrade? A, the cost saving it would deliver. B, usage data showing the person has not used Creator capability in six months. C, a policy that only the data team may hold Creator licences. D, a benchmark of Creator ratios at comparable organisations. Pause here and pick an answer before you continue.
B. Individual evidence is the only argument that survives contact with the person holding the licence, because it is specific to them and it invites a factual correction rather than a defensive one. A is your motivation and it is not their problem, and leading with cost makes the conversation adversarial immediately. C works until the first credible exception and then collapses as a rule. And D is useful for sizing the prize and useless in the individual conversation, where nobody accepts that another organisation's ratio should govern their job. Let me describe the review itself.
Guest analyst clip.
Twice a year, and it is mostly arithmetic. Licences by tier: assigned against active, per tier, for the last ninety days. Creator capability actually used, meaning who connected or prepared data, and everybody else is an Explorer candidate. Dormant accounts, no sign in for a quarter, and check leavers and movers before anything else because that is the free reduction. Content ownership, so who owns published content, because that is where a downgrade needs care and where you will do damage if you are careless. And the proposal per person, named, with their own usage beside it, sent to their manager rather than announced to the organisation.
Three sentences. Tableau counts people in three tiers with a large gap between them, and the boundary that matters is data connection and preparation rather than authoring, which means a great many people licensed as Creators are genuinely Explorers and have been for years. Analytics shown to a large external or occasional audience does not fit named user pricing, so ask which embedded or usage based arrangement applies before the design is settled. And most estates run Tableau and CRM Analytics side by side without anybody having chosen to, so measure adoption on both, name the workloads that belong to each, and either consolidate over a term or decide deliberately to keep both.
Homework before session eighteen, about ninety minutes. One, export licences by tier, assigned and active, for Creator, Explorer and Viewer separately. Two, find who used Creator capability, meaning who connected to or prepared a data source in the last quarter, and compare that against the Creator licence count, because the gap is your business case. Three, list dormant accounts, no sign in for ninety days, cross checked against leavers. Four, check for an external audience, so any dashboard shown outside the organisation and how it is licensed today. And five, pull adoption for both platforms, same period, same measure, and write down which one is real.
Five guides, all on redresscompliance dot com. Tableau pricing twenty twenty six covers the three roles, what each costs and where the boundaries sit. Tableau Cloud enterprise negotiation sets out the levers available on an enterprise agreement. Tableau and MuleSoft licensing covers optimising both portfolio lines including the role mix. Salesforce CRM Analytics pricing is the other half of the overlap, priced and explained. And Salesforce licence optimization describes the review rhythm that keeps a role mix honest over time.
That is session seventeen. The thing to take away is that this is the rare line you can fix on your own: pull the usage, find who actually prepares data, and the Creator population will be smaller than the Creator licence count, probably by a lot. Next time, Slack: the tiers, Slack Connect, and whether the bundle is a saving or a commitment. See you then.