New: Cookbooks and AI ExplanationsStep-by-Step recipes to solve problems connected to Roadmaps and Cheat Sheets. Need more details? Use AI buttons for structured and simple explanations with concrete examples throughout the whole platform.Take a look
Finance needs the full customer table, and the support team down the hall queries the exact same table but should never see a salary column.
What you'll have at the end
One shared Iceberg table where Finance's login returns every row with real salary values, and Support's login returns only its own region's rows with salary blanked, confirmed by querying as both roles.
You need
A shared lakehouse table both teams already query, with a column marking each row's region and a separate sensitive column one of the teams shouldn't see, plus working login credentials for one real member of each group.
Not covered
Creating the account groups themselves or wiring them to your identity provider: this starts from two groups that already exist and gets the table to respect them.
Leans on
Pick a catalog so Spark and Trino can query the same lakehouse table
When no single catalog yet governs every engine reading this table, since a row filter or mask only fires for reads that go through the catalog it's attached to.
Customer emails and other PII sit unmasked in a shared table
When the fix belongs at load time, rewriting the sensitive value once in the pipeline itself, rather than enforced dynamically per query and per role.
Mask PII so only the right role sees it
When the table with the sensitive column lives in Snowflake rather than a lakehouse catalog.
Checked 26 Aug 2026
Part of the Data Lakehouse cookbook