---
title: "row-level security | Skills We Assign For | Azendo"
description: "Row-level security in analytics — enforcement, testing, performance, plus the Azendo roles assigned for it."
url: "https://azendo.co/skills/row-level-security/"
---

[Skills](https://azendo.co/skills/) Analytics and BI 

# row-level security.

Row-level security restricts which rows a user can see based on their identity, enforced by the database or BI layer rather than by each report. One report then serves many audiences safely.

## Where row-level security fits on a long engagement.

Enforcing access at the data layer rather than per report is what makes it trustworthy. Filters applied in individual reports are easy to omit, and a single missing filter exposes data to people who should not see it — with no error to indicate it happened.

The rules need testing like any other logic, and they rarely are. A user in two roles, a user with no role, a record whose owner has left — each is a case where the rule may behave unexpectedly, and the failure is silent in both directions: too much data shown, or a legitimate user seeing nothing and assuming there is none.

## What an assigned team does with row-level security.

Security rules also carry a performance cost. Complex rules involving joins to permission tables execute on every query, and a rule that is correct but slow makes analytics unusable.

Balancing those is ordinary engineering work rather than a security afterthought, assigned under [managed data services](https://azendo.co/services/data-engineering/).

## What we use row-level security for.

* One report serving many audiences Data filtered by identity at the source, so a report cannot leak between regions or clients.
* Rules tested explicitly Multiple roles, no role and orphaned records verified, because failures are silent.
* Performance kept acceptable Rules designed so enforcement does not make every query slow.

## How row-level security capacity is assigned.

Access control in analytics is assigned inside data capacity, with rules tested as logic rather than assumed correct once configured.

## Roles we assign row-level security for

* [BI Developer Data science](https://azendo.co/services/data-science/bi-developer/)

## Service lines it sits in

* [Data science](https://azendo.co/services/data-science/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in analytics and bi

* [Tableau — skill we assign for](https://azendo.co/skills/tableau/)
* [semantic layers — skill we assign for](https://azendo.co/skills/semantic-layers/)
* [A/B testing — skill we assign for](https://azendo.co/skills/a-b-testing/)
* [experimentation design — skill we assign for](https://azendo.co/skills/experimentation-design/)
* [causal inference — skill we assign for](https://azendo.co/skills/causal-inference/)
* [cohort analysis — skill we assign for](https://azendo.co/skills/cohort-analysis/)
* [segmentation — skill we assign for](https://azendo.co/skills/segmentation/)
* [metric definition — skill we assign for](https://azendo.co/skills/metric-definition/)

## Tell us what your roadmap needs row-level security for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)