Security & Data Governance
The Luminary-only Data Security hub in Lumen, where roles, Data Keys, and Data Gates combine into fail-closed governance.
When to use it — When you need to control which rows and which fields each role or user can see across every query, chart, and Orion answer.
Where to find it — Lumen sidebar → Admin group → Data Security (
/lumen/data-security).Who can use it — Luminary only. The Admin group and this panel render only when your role is Luminary.
Celiq's data governance is built from three layers that work together: roles decide what a person can do, Data Keys decide which rows they can see, and Data Gates decide which fields they can see. All three are enforced at query time, fail-closed, by a single guard so that the same rules apply everywhere data is read — Discover, Mosaics, scheduled emails, the embed and public API, Sheets, and Orion.
This page is the hub. Each control has its own detailed guide; use this page to understand how they fit together and to confirm where to manage them.
Overview
The Data Security panel has two tabs — Data Keys and Data Gates — and sits alongside roles to form the full governance model:
| Control | What it limits | Where you manage it |
|---|---|---|
| Roles | What a user can do (Luminary, Weaver, Tracer, Lens) | Roles, Users |
| Data Keys | Which rows a user can see (row-level security / RLS) | Data Security → Data Keys tab |
| Data Gates | Which fields a user can see (column-level security / CLS) | Data Security → Data Gates tab |
A Data Key restricts rows by the values of one column on a node — for example, a "Region access" key that limits a Tracer to rows where region IN ('United States', 'Canada'). A Data Gate hides specific fields on a node from roles you do not grant — for example, a "PII fields" gate that hides email and phone from Tracers and Lenses.
When to use it
- You want analysts in one geography, business unit, or account to see only their own rows.
- You need to hide sensitive columns (PII, cost, margin) from some roles while keeping the rest of the node usable.
- You are setting up a new workspace and want governance in place before you invite Tracers and Lenses.
- You need a single place to confirm that row and field protection is actually applied to every query path.
Concepts
| Term | Meaning |
|---|---|
| Role | One of Luminary (admin), Weaver (builder), Tracer (analyst), Lens (read-only). Determines bypass behavior for both keys and gates. |
| Data Key (RLS) | A row-level rule on a node column. Roles/users are assigned allowed values; unassigned means no rows. |
| Data Gate (CLS) | A field-level rule that protects one or more fields on a node. Roles are granted or denied access. |
| Assignment | The allowed values for a Data Key, granted to a role (All tracers, All lenses, All weavers). |
| Grant | A Data Gate's granted/denied state per role. |
| Fail-closed | When in doubt, deny. An unassigned keyed node returns zero rows rather than all rows. |
* (wildcard) | Full access for a key — emits no row filter. This is distinct from being unassigned, which denies. |
Getting started
You need the Luminary role. The Admin group and the Data Security panel are hidden for every other role, and the panel additionally re-checks your role before it renders.
Open Lumen
Click your workspace menu and open Lumen, or go to any /lumen/... page.
Find the Admin group
In the left sidebar, scroll to the Admin group. It appears only for Luminaries.
Open Data Security
Click Data Security. You land on /lumen/data-security with the Data Keys and Data Gates tabs.
Step-by-step
This hub gives you the high-level flow. For full field-by-field instructions, follow the linked guides.
Decide roles first
Assign each person the right role in Users. Roles drive every bypass decision below, so get them right before adding keys or gates. See Roles.
Add row-level rules with Data Keys
On the Data Keys tab, click + New Data Key, pick a node and the column to filter on, then assign allowed values to roles. Remember: an unassigned role sees no rows. Full detail in Data Keys.
Add field-level rules with Data Gates
On the Data Gates tab, click + New Data Gate, pick a node and the fields to protect, then grant or deny each role. Full detail in Data Gates.
Verify in Discover
Open Discover as (or impersonate) a Tracer or Lens and confirm the restricted rows are gone and the protected fields are hidden or marked Restricted.
Examples
A Data Key turns an assignment into a row filter at query time. For a Tracer assigned the values United States, Canada, the enforced filter is:
WHERE region IN ('United States', 'Canada')An unassigned Tracer on the same keyed node gets the fail-closed default — zero rows:
WHERE 1=0A Tracer granted full access (*) gets no row filter at all (all rows), which is different from being unassigned:
-- full access: no filter emitted for this keyFor a Data Gate, denying the Tracer role on a "PII fields" gate strips the protected fields from the projection. In Discover a Tracer sees those fields marked Restricted, while a Lens sees them hidden entirely. Weaver and Luminary always see them.
Best practices
- Set roles before keys and gates — every enforcement decision keys off the role.
- Prefer assigning keys to roles (
All tracers) over individual users so new hires inherit the right scope automatically. - Keep one key per business dimension (region, business unit, account) rather than overloading a single column.
- Use Data Gates for sensitive columns instead of removing them from the node — the rest of the node stays usable.
- After any change, verify as a real Tracer/Lens; do not rely on a Luminary view, which bypasses everything.
Tips
A blank assignment is not the same as full access. Leaving a role unassigned on a keyed node denies all rows (WHERE 1=0). To grant everything for a key, use the Full access (* = all rows) option, which emits no filter.
Common mistakes
- Expecting unassigned to mean "all rows." It means no rows. Assign explicit values, or choose Full access.
- Testing as a Luminary. Luminary bypasses both keys and gates, so everything looks visible. Verify as a Tracer or Lens.
- Trying to hide fields from Weavers with a gate. Weaver bypasses Data Gates. Use roles to limit who is a Weaver instead.
- Forgetting that demo rules are protected. Rules whose name starts with
[DEMO]cannot be deleted.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| You cannot see the Data Security item in Lumen | You are not a Luminary; the Admin group renders only for Luminaries | Have a Luminary grant you the role in Users, or ask a Luminary to make the change |
| A user sees no rows on a node | They are unassigned on a Data Key for that node — the fail-closed default is WHERE 1=0 | Add an assignment for their role with the allowed values, or grant Full access |
| A user still sees a field you tried to hide | They are a Weaver or Luminary, who bypass Data Gates | Restrict via role, or accept that builders/admins see all fields |
| A Tracer sees a field as Restricted instead of hidden | That is the intended Data Gate effect for Tracers (Lenses see it hidden entirely) | No action — grant the role if it should be visible |
| The delete (🗑) button is disabled on a rule | The rule is a protected demo rule (name starts with [DEMO]) | Create your own rule instead; demo rules cannot be deleted |
| "Pick a node and enter a name." when creating a rule | Required fields are missing in the create dialog | Select a node and enter a name; for a key also pick the column, for a gate pick at least one field |
Related pages
- Data Keys — row-level security, in depth
- Data Gates — column-level security, in depth
- Roles — Luminary, Weaver, Tracer, Lens and their permissions
- Users — assign roles to people
- Permissions — broader access controls
- Audit Log — review who changed what