Ship it

Workspaces are cheap; sprawl is not. Three habits keep a tenant navigable:

• Separate dev from what viewers see. Build and break in a dev workspace; promote to a test or prod workspace, and publish the app from prod. Viewers never watch you refactor live.
• Name for the finder, not the builder. "Daybreak - Revenue (Prod)" beats "phoebe_test_v3_final". Six months from now, someone searches - make sure they find the right one.
• One named owner per workspace. When refresh breaks at 6am (part 2), someone specific gets the alert. "The team owns it" means nobody does.

Same tree, two toolbars:

• App - broad, stable audiences get the curated bundle. Direct share - a link or permission for a handful of people, ad-hoc. Embed - the dashboard appears inside a portal, wiki, or Teams channel. Subscription - an emailed snapshot on a schedule. Alert - a notification when a number crosses a threshold.

Match the refresh to the question's rhythm, not to "as often as possible":

• Daily exec pack: decisions happen in a morning meeting → refresh once, before the meeting (6am). Hourly refresh would burn source capacity to update numbers nobody reads until tomorrow.
• Ops floor: people act within the hour → hourly, or consider a live connection (b1's trade-off returns).
• Monthly board view: monthly refresh after close, then endorsed and frozen. Mid-month wobble creates questions, not decisions.

Then wire the failure alert: a refresh that fails silently is worse than no refresh, because the dashboard keeps confidently showing last week. Cadence + alert together are the heartbeat.

Moral: a shipped dashboard is data + refresh + someone watching the refresh. Put "last refreshed" on every page you ship; it is the cheapest trust signal in BI.

Strip away the portal screens and RLS is just this: the platform appends a WHERE clause the viewer never sees. Here is what Daybreak's dashboard effectively runs when the Seattle manager opens it:

SELECT c.city,
       ROUND(SUM(oi.quantity * oi.unit_price), 2) AS revenue
FROM orders o
JOIN order_items oi ON oi.order_id = o.order_id
JOIN customers c ON c.customer_id = o.customer_id
WHERE c.city = 'Seattle'
GROUP BY 1;

Everything the platform adds - roles, group membership, the security dialog - exists to attach the right invisible WHERE to the right person, reliably, at scale.

Either way, membership is granted by adding users or groups to the RLS role - and PL-300 tests both the role setup and the membership step.

Before touching the security dialog, write the matrix in plain language and get it signed off. Daybreak's:

A written matrix turns "did we secure it right?" from a feeling into a checklist - and it is the artifact auditors ask for.

Route these through part 1's decision tree, then check yourself:

• 300-viewer exec pack, read every morning → the app: broad, stable audience, curated bundle.
• The CFO wants Monday's numbers in email at 7am → a subscription: scheduled snapshot, no login required.
• Ops needs a ping if daily orders cross a threshold → an alert: nobody should stare at a chart waiting for a number to move.

Every dynamic rule reduces to one sentence of the form: "Filter [table] to rows where [column] equals the value mapped to the logged-in user." For "each city manager sees own city":

"Filter customers to rows where city equals the city mapped to the logged-in user in the manager-city table."

One role, any number of managers, and onboarding a new one is a single mapping row - no model change. If you can write the sentence, you can build the role in any tool.

You are the RLS engine now. Edit 'Seattle' to another city and re-run - you just switched which viewer is logged in. (Not sure which cities exist? Run SELECT DISTINCT city FROM customers; first.)

SELECT c.city,
       ROUND(SUM(oi.quantity * oi.unit_price), 2) AS revenue
FROM orders o
JOIN order_items oi ON oi.order_id = o.order_id
JOIN customers c ON c.customer_id = o.customer_id
WHERE c.city = 'Seattle'
GROUP BY 1;