# Looker Knowledge Share — Speech Transcript & Q&A Prep
> Target: 30–45 min. Audience: Tableau-familiar, Looker-new. Goal: enable adoption.
> Tone: conversational, honest tradeoffs, pay off the governance-pain hook throughout.
—
## Slide 1 — Title (~30 sec)
“Thanks everyone for joining. Today I want to talk about Google Looker — but not as ‘here’s another BI tool.’ I want to show you a specific problem it solves really well for us: getting **trustworthy dashboards in front of external dealers**, embedded right inside paccar.net, with access control that basically runs itself once it’s set up. I’ll cover why we’d reach for Looker, when I’d still use Tableau instead, how you actually build a dashboard, how the access control works, and then I’ll demo a real one I built.”
—
## Slide 2 — Agenda (~30 sec)
“Quick roadmap. I’ll open with the problem that got us here, then the ‘why Looker,’ then a straight comparison with Tableau so you know when to pick which. Then, because most of you already know Tableau, I’ll map Looker’s concepts onto what you already know. We’ll walk the build steps, dig into access control — which is really the heart of this — do a live demo, and leave time for questions. Feel free to interrupt, but I’ll also pause for Q&A at the end.”
—
## Slide 3 — The Problem / Hook (~2.5 min)
“Let me start with the pain, because it’s probably familiar.We just build a dashboard, we don’t just report internally. We want to share analytics with **external dealers** — people outside PACCAR. Every time we do that, it becomes a bespoke access project: who can log in, what can they see, how do we make sure Dealer A can’t see Dealer B’s numbers. And that governance work tends to lean on a dedicated team to keep straight.
So the real question isn’t ‘can we make a nice chart.’ It’s: **’Can this dealer even see it?’** That’s a governance problem, not a charting problem. And that’s exactly where Looker earns its place.”
**Delivery note:** land the pull-quote slowly. This is the thread you pay off on every later slide.
—
## Slide 4 — Why Looker (~3 min)
“So why Looker specifically? Three things.
**First, governed metrics.** Looker has a modeling layer called LookML. Think of it as one central, version-controlled definition of every metric. Instead of each analyst re-implementing ‘net revenue’ inside their own workbook, it’s defined once and everyone queries that same definition. That’s how you kill the ‘which number is right’ problem — there’s only one number.
**Second, embedding to dealers.** Looker dashboards embed directly into paccar.net. So an external dealer doesn’t learn a new tool or get a separate login to some BI portal — they see the dashboard inside a platform they already use every day.
**Third — and this is the one I’d underline — access control that’s self-sustaining.** It reuses our existing paccar.net and PASS identity. Once it’s set up, onboarding a new dealer is essentially zero-touch. There’s no dedicated team manually granting access dealer by dealer.
So the headline is: **expose trustworthy dashboards to external dealers, with access control that runs itself.**”
—
## Slide 5 — Looker vs Tableau (~3 min)
“I want to be honest here — this is not ‘Looker beats Tableau.’ They’re good at different things, and I’d genuinely pick each in different situations.
**Looker is my choice for external, dealer-facing reporting.** When I need governed, repeatable numbers, embedded in paccar.net, where each dealer must only see their own data, and where access rides on our existing PASS identity — that’s Looker’s lane.
**Tableau is my choice for internal analysis.** When someone wants to explore freely, build a rich custom visual, do a one-off deep dive, iterate fast, and governance isn’t the top concern — Tableau is great at that.
So the rule of thumb I’d give you: **external and governed, reach for Looker. Internal and exploratory, reach for Tableau.** They coexist; this isn’t a migration.”
**Delivery note:** if asked “are we killing Tableau” — no. Say it plainly.
—
## Slide 6 — Concept Map (~2 min)
“Because most of you live in Tableau, here’s the cheat sheet so Looker doesn’t feel foreign.
A Tableau **data source** is roughly a Looker **Explore**. Your **calculated fields and data model** in Tableau — in Looker that lives in **LookML**, except it’s governed and shared, not per-workbook. A Tableau **worksheet** is a Looker **Look**. A **dashboard** is a **dashboard** — same word, same idea.
The one row I’d focus on is the bottom one. In Tableau, logic tends to get duplicated in every workbook. In Looker, it’s one central model — a single source of truth. That’s the whole governance story in one line.”
—
## Slide 7 — Build a Dashboard (~3.5 min)
“Let’s actually build one, conceptually, in five steps.
**Step one, connect.** You point Looker at the warehouse — for us that’s BigQuery. Queries run live against the warehouse; there’s no extract to refresh, so you’re not looking at last night’s snapshot.
**Step two, model in LookML.** This is where you define the Explore and the governed metrics — once. I’ll be honest: this is the least familiar part for a Tableau person, and it’s also the part most of you won’t touch daily.
**Step three, Explore.** This is where you’ll live. You drag dimensions and measures to answer a question, ad hoc, just like building a view.
**Step four, save a Look.** When you’ve got a view worth keeping, you freeze it as a reusable tile.
**Step five, assemble.** Arrange your Looks into a dashboard, add filters, and share it.
So the honest day-to-day for most of you is **steps three through five**, sitting on top of a model the team already built. The barrier to entry is low.”
—
## Slide 8 — Access Control: How a Dealer Gets In (~3.5 min)
“Now the heart of it — access control. Follow the flow across the top.
A **dealer** opens a dashboard inside paccar.net. That kicks off **SSO through PASS** — our identity provider at auth.paccarsolutions.com — which handles both internal and external users. On login, their **PASS groups** get passed to the app. And **Looker** uses those groups to decide what they get.
There are two layers of authorization, and it’s important not to conflate them.
**Content-level:** the PASS group maps to a dashboard. That decides *which dashboards* a user is even allowed to open.
**Row-level:** within a dashboard, each dealer only sees *their own rows*. So two dealers can open the same dashboard and see completely different data — their own. That’s confirmed behavior.
So it’s ‘which dashboards can you open’ *and* ‘whose data do you see’ — two separate mechanisms working together.”
**Delivery note:** this is the slide people will probe. Slow down. Be precise about content-level vs row-level.
—
## Slide 9 — Config Detail & the Claim (~2.5 min)
“Here’s what that content mapping actually looks like. In the app config, a PASS group is mapped to a specific dashboard. For example, the `ghgscorecard` group maps to the GHG dealer scorecard dashboard; the `ghgrecommender` group maps to the recommender. That’s the real config.
The important takeaway: **adding a new dashboard is one new mapping line.** It’s not a project.
And that lets me make the claim carefully. **There’s no dedicated access team** because dealer onboarding is zero-touch — identity and entitlement are reused from PASS, so a new dealer lands in the right group automatically. The only touch point is that adding a brand-new dashboard is a one-line config mapping. So — self-sustaining for onboarding, trivial for new content.”
**Delivery note:** Don’t overclaim. The precise version (“zero-touch onboarding; new dashboard = one line”) is the defensible version.
—
## Slide 10 — Live Demo (~5–8 min)
“Let me show you a real one.” *(Switch to Looker.)*
Demo checklist:
1. Open the dashboard in Looker — orient them: “this is the same dashboard a dealer sees embedded in paccar.net.”
2. Show the **Explore** behind a tile — how the numbers are produced from the model.
3. Show a **governed metric** and a **filter** in action.
4. Tie it back: “when a dealer hits this via paccar.net, PASS decides they can open it, and row-level scoping means they only see their rows.”
**Fallbacks if live fails:** have a screen recording or screenshots ready. Never live-login as an external dealer on stage.
—
## Slide 11 — Takeaways (~1.5 min)
“To bring it home, four things to remember:
One — Looker’s real edge is **governance plus embedding**: one trusted metric definition, delivered inside paccar.net to external dealers.
Two — **pick the lane**: external and governed is Looker, internal and exploratory is Tableau.
Three — **access runs itself**: SSO via PASS, group-to-dashboard mapping, row-level scoping, and onboarding is zero-touch.
Four — the **barrier to build is low**: if you know Tableau, you can build Looks and dashboards today on top of the shared model.”
—
## Slide 12 — Q&A (~remaining)
“That’s what I’ve got — I’d love your questions.”
—
# Anticipated Q&A — Clarity Prep
Grouped by theme. Each has a crisp answer plus a fallback if you don’t know.
### Positioning / strategy
**Q: Are we replacing Tableau with Looker?**
A: No. This is coexistence. Looker owns external, governed, dealer-facing reporting; Tableau stays for internal ad-hoc exploration. Different lanes, not a migration.
**Q: Why not just embed Tableau for dealers?**
A: You can embed Tableau, but you’d rebuild the governance and per-dealer access story yourself. Looker gives us the governed metric layer plus the PASS-driven, self-sustaining access model out of the box.
**Q: What does this cost / what’s the licensing model?**
A: *(Look up before the talk — Looker is platform/embed-licensed, and embedded/external users are typically licensed differently from internal creators.)* Fallback: “I’ll confirm exact licensing with the platform team and follow up.”
### Access control (expect the most here)
**Q: How does a dealer only see their own data — is that the group mapping?**
A: Two separate layers. The group→dashboard mapping controls *which dashboards* they can open. A separate row-level mechanism controls *whose rows* they see inside a dashboard. Both are in play; don’t conflate them.
**Q: Where does the dealer identity come from?**
A: PASS — auth.paccarsolutions.com — is the SSO identity provider. On login, PASS groups are passed to the app, and those drive both the dashboard mapping and the scoping.
**Q: What happens when we onboard a new dealer?**
A: Effectively zero-touch. They land in the right PASS group through existing entitlement, and access flows automatically — no per-dealer Looker work.
**Q: What happens when we add a new dashboard?**
A: One new mapping line in the app config — like the `ghgscorecard~ApplicationExists -> …` entries. Not a project.
**Q: Is it signed embed or full SSO login?**
A: The login flow I’ve seen goes paccarembedded.cloud.looker.com → auth.paccarsolutions.com → dashboard, which looks like SSO authentication into Looker with PASS as IdP, then group-based routing. *(If pressed on the exact embed type — signed vs SSO-embed — say you’ll confirm the precise mechanism with IT.)*
**Q: Could a dealer ever see another dealer’s data?**
A: Not by design — row-level scoping ties data to their identity. The honest answer: it’s confirmed behavior, and any access change is governed through PASS groups, not ad-hoc.
### Build / adoption
**Q: Do I have to learn LookML to use Looker?**
A: No. LookML is the modeling layer the data team sets up. Day-to-day for most people is Explore → Look → dashboard on top of that model.
**Q: Live queries — is performance a problem?**
A: Queries run against the warehouse (BigQuery) live, so freshness is a plus. Performance depends on the warehouse and model design; the modeling layer is where you optimize.
**Q: Can I still do ad-hoc exploration like in Tableau?**
A: Yes, that’s what Explores are. It’s just bounded by the governed model, which is the point.
**Q: Can we export / schedule / alert like Tableau?**
A: Looker supports scheduled delivery and alerting. *(Confirm the specifics we’ve enabled before promising exact features.)*
### Risk / governance
**Q: Who owns the LookML model and the mappings?**
A: The data/platform team owns the model and the group→dashboard config. That centralization is what keeps the single source of truth intact.
**Q: What’s the failure mode if PASS is down?**
A: Access is gated on SSO, so an IdP outage blocks login — same dependency as anything else behind PASS. *(Confirm any fallback with IT.)*
—
## Open items to confirm before presenting
– Exact embed mechanism (signed embed vs SSO-embed) — verify wording with IT.
– Licensing/cost model for embedded external users.
– Scheduling/alerting/export features actually enabled in our instance.
– Demo fallback recording/screenshots prepared.