For the complete documentation index, see llms.txt. This page is also available as Markdown.

Row-Level Security

Row-Level Security (RLS) controls which rows of data each user can see — not just which Boards. A multi-location group can share one set of dashboards while each manager sees only their own location's numbers; a multi-brand organization can keep every brand's data walled off inside a single account.

How it works

RLS is enforced in the data warehouse itself, at query time. That means it applies everywhere a query runs, automatically:

  • Boards and widgets — the same widget shows each user only the rows they're permitted to see

  • Board filters — filter options are scoped to the user's permitted values, too

  • AskCorral — AI answers are computed only from the rows the asking user can access

  • MCP (Claude / ChatGPT) — queries run through the CorralData MCP server respect the same rules

Because the filtering happens at the data layer, there's no separate setting to keep in sync per dashboard — one policy governs every path to the data.

Access modes

Each protected table can be governed in one of three ways:

  • Value-based filtering — every user's rows are filtered by their assigned values (for example, their location or brand). The most common setup.

  • Specific users — only individually designated users see the table's rows; everyone else sees none.

  • Full access — the table is explicitly open to all users on the account.

Per-user overrides can be layered on top — for example, a manager scoped to one brand everywhere, except one shared company-wide Board where they're granted full visibility.

Setting it up

Your CorralData team configures RLS with you: together you define the mapping (which users see which locations, brands, or entities), and we apply and maintain the policies. Changes — new hires, new locations, role changes — are handled the same way.

Want RLS on your account, or need a mapping updated? Reach out to your CSM or support@corraldata.com.

Was this helpful?