Module 3 · Governance & Sharing

An app is only useful if it’s safe to share. Data apps run on the platform’s governance: viewers interact under their own role — row-level security, connector scope, and any capability the app invokes are checked against the viewer, not baked in at build time.

Prompt

Explain how this app behaves for different viewers: what does a user in the [restricted role] see vs an [analyst role]? Which permissions are checked when a viewer interacts? Then share the app with [team/role] and show me exactly what they'll be able to see and do.

You’ll see: the sharing model spelled out — and if your workspace has restricted roles (e.g. a business-user role scoped to governed views), the same app shows each viewer their permitted slice.

Verify, don’t assume — Before sharing broadly, test-view the app as a restricted role (or have a colleague in that role open it) and confirm the boundary holds. Governance you’ve verified is governance you can defend.

TQL-only connections — If a connection your app reads has been marked TQL-only by an admin, the app’s live data sources must be governed ontology query files — inline SQL sources are refused on that connection (that’s the point: row-level security lives in the query files). Building on governed surfaces from the start costs nothing and means a later lockdown never breaks your app. If Ana proposes an inline SQL source against a sensitive connection, ask her to use (or create) a governed query surface instead.

✅ Checkpoint

The app is shared to a real audience
You verified what a restricted viewer sees

​✅ Checkpoint

✅ Checkpoint