Each person sees their own rows. Set once, applied everywhere.
One sales dashboard for the whole company, and each regional manager sees only their region. One group finance view, and each managing director sees only their entity. Klayara's row-level security and column masking are set once per person or team and then hold in every dashboard, download, scheduled report, public link, embed and AI answer.
One rule, every surfaceColumn hiding and maskingCheck access previewCoverage gaps visible
What is row-level security in BI?
Row-level security in BI limits which rows of data each person can see, so one dashboard shows each reader only their own region, branch, customer or entity. In Klayara a rule is set once, from each person's profile, a mapping table or named security dimensions, and applies everywhere: dashboards, downloads, scheduled reports, public links, embeds and AI answers. Column rules can hide or mask sensitive values.
Row-level security for dashboards: one dashboard, many readers
Row-level security lets you build one dashboard instead of one per branch. Without it, a company with eight regions either maintains eight copies of the sales dashboard or shows everyone everything. With a row rule on the region column, the same dashboard shows the North manager the North, the head of sales every region, and a new joiner nothing until granted.
The rule lives on the data, not on the dashboard. Add a new chart, a new page or a new dashboard on the same table and the rule already applies; nobody has to remember to set permissions again. That is what makes it safe to give wide read access to managers, branch heads and the board.
Restrict data by region, branch or entity
Klayara gives three ways to decide who sees which rows. A rule can follow each person's own profile, so a manager whose profile says "Region: Gulf" sees Gulf rows. It can follow a mapping table you maintain, listing which people cover which branches. Or it can use security dimensions: named axes such as branch or region, where each person is granted "all" or a specific list.
Security dimensions are the clearest choice for most groups. Name the axis once, use it on every table that carries a branch, and grant each person their branches in one place. Start everyone on "nothing until granted", so a forgotten grant hides data rather than exposing it.
- From each person's profile: their own region or branch
- From a mapping table that you keep up to date
- Security dimensions: grant "all" or a list per person
- Nothing until granted as the safe starting point
Column-level security and data masking in reports
Column-level security controls which columns a person can see, and how. Klayara can hide a column entirely, blank it, replace its values with a fixed text, or keep only the last four digits — useful for bank account numbers, national IDs or phone numbers. Named exceptions let payroll see the full salary column while everyone else sees it blank.
Masking reaches into the formulas too. An author who is not allowed to see a column cannot use it in a calculation, and gets no hint that it exists. So a hidden column cannot be brought back into view through a calculated column on a dashboard.
Set once, applied everywhere: no side doors
A permission rule is only as strong as its weakest path to the data. In Klayara the same row and column rules apply to dashboards, the spreadsheet-style viewer, Excel, CSV and JSON downloads, scheduled PDF and image reports, public links, embedded dashboards and Klayara AI answers. There is no export or assistant that returns more than the person may read.
Scheduled reports are rendered per recipient, so one branch report schedule sends each manager their own branch. Public links publish a dashboard with the same row rules applied. When you embed dashboards in your own product on Enterprise, each of your customers sees only their own rows without needing an account.
- Dashboards and the data viewer
- Downloads to Excel, CSV and JSON
- Scheduled reports, rendered per recipient
- Public links and embeds, with the same rules
- AI answers, within the asker's permissions
Multi-entity group reporting permissions
Groups with several companies are where row-level security earns its keep. Load each company's ERP or accounting data into the same tables with an entity column, build one group dashboard, and put a security dimension on entity. The group CFO is granted all entities; each managing director is granted their own; a shared-services accountant is granted the three companies they close.
The same pattern works for franchises, distributors and agencies reporting to clients. One build, one set of definitions for revenue and margin, and each reader sees their slice. Chart-level sharing adds a further layer when a single chart on a shared dashboard should be visible only to finance.
Check access: see exactly what a colleague sees
Check access shows a table exactly as a chosen member would see it: their rows, their hidden columns, their masked values. Before you send a dashboard link to the board or switch on a scheduled report, you can confirm that the Riyadh branch manager sees Riyadh and that the salary column is blank for them.
The coverage view answers the opposite question: which tables each rule governs, and which members still lack grants. The access console explains in plain words why someone can reach something, and batch changes let you review and apply up to 200 grants, removals and role changes at once. A plan change or billing lapse never switches a security rule off.
From first click to everyday use.
Name the axes
Define security dimensions such as region, branch or entity, or point a rule at profiles or a mapping table.
Grant people
Give each person or team "all" or a list of values; everyone else starts with nothing.
Mask columns
Hide, blank, replace or keep the last four digits of sensitive columns, with named exceptions.
Check and share
Use Check access to see as a colleague, check coverage for gaps, then share widely.
Rule types and what they do.
| Rule type | What it does | Example |
|---|---|---|
| From each person's profile | Limits rows to the value stored on the person, such as their region or branch | A regional manager whose profile says "North" sees only North sales |
| Mapping table | Limits rows using a table you maintain of who covers what | Key-account managers see only the customers listed against them |
| Security dimensions | Named axes where each person is granted "all" or a list, starting from nothing | The group CFO gets all entities; each managing director gets their own company |
| Hide a column | Removes the column for that person everywhere, including in formulas | Cost price hidden from the sales team |
| Blank a column | Keeps the column but shows it empty | Salary blank for everyone except payroll |
| Replace values | Shows a fixed text instead of the real value | Customer phone shown as "Restricted" to external agencies |
| Keep the last four | Shows only the final four characters | Bank account numbers shown as the last four digits to the collections team |
Everything included: security and governance.
Decide once who sees which rows and columns; the rule holds in every dashboard, download, report, embed and AI answer. See every feature.
Row-level security
Each person or team sees only their region, branch, customer or entity — set once, applied everywhere.
Growth and EnterpriseRules from each person's profile
Row rules can follow each person's own region or branch, or a mapping table you maintain.
Growth and EnterpriseSecurity dimensions
Name axes such as branch or region, grant each person "all" or a list, and start everyone on "nothing until granted".
Growth and EnterpriseColumn-level security and masking
Hide a column, blank it, replace it, or keep only the last four digits — with named exceptions where needed.
Growth and EnterpriseCoverage view
See which tables each rule governs and which members still lack grants, so gaps are visible.
Growth and EnterpriseCheck access
See a table exactly as a chosen member would: their rows, their hidden columns, their masked values.
Access console
Browse access by person, role or resource, with a plain explanation of why someone can reach something.
Batch access changes
Review and apply up to 200 grants, removals and role changes at once.
Several roles per person
One person can hold several roles at once, such as Sales and Finance reader.
Safety rails
The last owner can't be removed, and removing someone clears all their individual access.
Protection survives plan changes
A billing lapse or plan change never switches a security rule off.
Two-factor sign-in
Authenticator-app codes with recovery codes, plus passwords, one-time codes and Sign in with Google.
Re-confirm for sensitive changes
Changing a password, two-factor settings or email requires signing in again.
Personal API keys
Each user can issue and revoke their own keys for scripts and notebooks.
Activity log
Changes, shares and sign-ins recorded with before-and-after detail.
Separate usage limits
Normal use, sign-ins, AI and each embed have their own limits, so one can't starve another.
Row-level security questions, answered.
Something else on your mind? Ask us directly — a person answers.
What is the difference between row-level and column-level security?
Row-level security decides which rows a person sees, such as only their region's sales. Column-level security decides which columns they see and how, such as hiding cost price or showing only the last four digits of an account number. Klayara supports both, and they combine.
Do permissions apply to scheduled reports and downloads?
Yes. Scheduled PDF and image reports are rendered per recipient with only their rows, and every Excel, CSV or JSON download applies the same row and column rules as the screen. There is no export path that bypasses them.
Do permissions apply to embedded dashboards and public links?
Yes. Public links publish a dashboard with the same row rules applied. Embedded dashboards, available on Enterprise, show each of your customers only their own rows, without them needing a Klayara account.
Can the AI assistant reveal data a person is not allowed to see?
No. Klayara AI sees only what the person asking may see, under the same row and column rules as everywhere else. A regional manager asking about total sales gets their region's total.
How do I test a rule before rolling it out?
Use Check access to view any table exactly as a chosen member would, with their rows, hidden columns and masked values. The coverage view then shows which tables each rule governs and which members still have no grants.
Which plan includes row-level security?
Row-level security, column masking, security dimensions and custom roles come with the Growth and Enterprise plans. Check access, the access console, sharing at view, edit or admin level and several roles per person are part of every plan.
What happens to security rules if our plan changes?
They stay on. A billing lapse or a plan change never switches a security rule off, so a downgrade cannot suddenly expose rows that were restricted. Existing grants, masks and security dimensions keep applying to every reader.
See it on your own data.
Bring one report your team relies on. We'll rebuild it live in Klayara, with your permissions, so you can judge it on real numbers.
Prefer to see plans first? See pricing