Skip to main content

Granting access to a data product

Access to a data product is closed by default: only its owner and Qry admins can read it. Everyone else reads it through a grant, which names who may read and what they may see. This page is for the product's owner.

Goal​

You finish this page with a published product shared with a person, a group or an application, each reading exactly the rows and columns you meant.

Prerequisites​

  • You own the product (or you are an admin). Only the owner and admins can add or revoke grants.
  • The product has at least one dataset whose preview you have run, so its columns are known. Column masks need that list.

Who a grant can name​

KindWho readsWith what
Personone Qry usertheir session in Qry, a CLI token, or a Nexus access token in an assistant
Groupevery member of a Qry groupthe same credentials, each member as themselves
API clientan applicationits API key. A key always acts as the client, never as a person

Every kind takes the same restrictions.

Steps​

1. Open the Access tab​

Open the product in Nexus and choose Access. The list shows the current grants; each card summarises its restrictions (datasets, row filter, masked columns, rate limit, expiry). The Overview says the same in one line, under Who can read it.

2. Grant access​

Click Grant access and choose Who: a Person (search by name or email, three characters or more), a Group, or an API client (create one first under API Gateway → API Clients).

Then set what this grant allows. Everything is optional; a grant with nothing set reads the whole product.

  • Allowed datasets — leave empty to allow every dataset in the product.
  • Row filter — a SQL WHERE condition, for example region = 'EMEA' AND tier <> 'internal'. Only rows that match are returned.
  • Column masks — pick a column, then a preset or your own expression. The reader gets the expression's result in place of the value.
  • Rate limit override — a cap in requests per minute for this grant on this product. Empty means no extra cap.
  • Expires at — the date the grant stops working.

Click Grant access. The row filter and masks are checked in the SQL dialect of every engine the product's datasets run on, so a condition that one of them would refuse is caught here, not on the reader's first query.

3. Choose masks from the presets​

The presets are written in each engine's own SQL, so the same preset produces valid SQL on SQL Server, Oracle, BigQuery, PostgreSQL or Databricks. An engine with no way of writing a preset does not offer it.

PresetWhat the reader sees
Redact***MASKED***
Nullan empty value
Hash (MD5)an MD5 hash of the value (the same value always gives the same hash)
Keep first 3the first three characters followed by ***
Email domain***@ followed by the domain

A custom expression must be valid SQL for the dataset's engine; the check in step 2 applies to it too.

4. Revoke when it is no longer needed​

Expand the grant's card and click Revoke access. The next read through that grant is refused.

How the rules work​

Grants add up, dataset by dataset. A person can hold their own grant and their groups' grants at the same time. As with RBAC, there is no deny: access is the sum of what the grants allow. For each dataset, only the grants that cover that dataset count:

  • a dataset is readable if any grant allows it;
  • a row is visible if any grant's row filter lets it through, so a grant with no filter shows every row;
  • a column stays masked only if every grant masks it. One grant that shows the column shows it.

A grant that is unrestricted on one dataset does not lift the filter or masks another grant puts on a different dataset.

Owners and admins read unrestricted. Filters and masks do not apply to them, and an admin's read is marked as such in the audit log.

Reads run with the owner's datasource access. The grant decides whether someone may read; the query itself runs with the product owner's access to the datasource. A reader needs no access of their own to the underlying tables, and can never read more than the owner can. If the owner loses access to a table, reads of it fail for everyone.

Filters and masks cannot be worked around. The row filter and the masks are applied first, as a closed view, and everything a reader asks for (their own filters, order, pages) is applied on top of it. A reader filtering on a masked column filters on the masked value, not the original. Through an assistant, a masked column cannot be filtered, grouped or aggregated at all.

Every read is audited. Each read through the gateway or an assistant writes a row to the product's Activity tab: when, who called, which dataset, the status, the latency and the rows returned.

What readers see​

Readers see the published catalogue. Drafts and deprecated products are visible only to their owner and admins.

For a product they can read, they get what it holds: its description, its datasets, each column with its description, and the quality results. They never see how it is built (the datasets' SQL and datasource) or who else it is granted to.

Common issues​

The column list in Column masks is empty. The dataset's columns are not known yet. Open the dataset, run its Preview and save it.

Saving the grant fails with a SQL error. The row filter or a mask is not valid on one of the product's engines. Use a preset, or write the expression in that engine's dialect.

A group member still sees a column you masked in the group's grant. They hold another grant on that dataset (their own, or another group's) that does not mask it. A column stays masked only if every grant masks it.

Someone you granted cannot find the product. It is still a draft, and readers see only published products. Publish it.

See also​