Practice — Hot · Solution
1 · The architecture
- Roles: three analysts as Members (one as Admin, or a team lead); nobody else in the workspace.
- Distribution: an app for the 500 — the showroom, with deliberate release pushes on the analysts' weekly cadence.
- RLS: at six managers, static roles are defensible (six roles, low churn) and dynamic is the better bet if manager turnover or region reorgs are expected — one role plus a mapping table beats re-publishing role assignments every reorganization. Either answer earns full marks if argued; "static now, designed so dynamic can replace it" is the strongest form.
- Refresh: the ERP export folder is on-premises — a gateway inside HQ's network brokers the nightly refresh. (Alternative worth naming: land the ERP export in SharePoint instead, and no gateway is needed — an architecture suggestion, not just a component.)
2 · The pushbacks
- Request 4 (send everyone the file): the .pbix contains the entire model with no RLS — 500 copies means 500 unsecured, instantly-stale forks, and the regional-visibility requirement (their own request 1) is dead on arrival. The underlying need — access that survives bad connectivity — is served by the mobile app's offline cached views and by PDF subscription snapshots for true offline reading. Offer those.
- Request 5 (store managers edit): 40+ editors means no single source of truth within a week — every definition this rollout exists to standardize becomes editable at every store. The underlying need — "managers spot errors" — is real and better served: a visible feedback channel plus fast analyst turnaround, and the export button they already have for local what-ifs. Spotting errors is a reporting channel, not an edit grant.
3 · A memo that would hold (abridged to its spine)
"Rollout architecture: analysts build in the workspace; all 500 staff install the app, which we update weekly after review. Regional managers see only their regions via row-level security enforced by the model — verified per role before launch. Nightly refresh requires one IT install: a gateway on the HQ network so the cloud service can reach the ERP export folder (alternatively, landing the export in SharePoint removes that dependency). Two requested changes we recommend against, with substitutes: distributing the file itself would bypass regional security and go stale immediately — the mobile app's offline views and scheduled PDF snapshots cover offline needs. And broad edit access would fork our single source of truth across 40 stores — we'll stand up a one-click feedback channel with 48-hour analyst turnaround instead, so spotted errors get fixed once, for everyone."
Reflection answers
- The legitimate need behind "send the file" is resilient access — connectivity fear, usually earned. The file is the wrong container for it; cached mobile views and snapshot subscriptions are the right ones. Pushback that names and serves the need lands; pushback that only says no gets overruled.
- The tipping facts are churn and reorganization: six stable managers favor static's simplicity; any expectation of turnover, region splits, or growth to twenty managers favors dynamic's one-role-plus-mapping. The flip trigger is the first reorg memo — which is why "static now, dynamic-ready" is the professional hedge.