Row-Level Security

Row-level security (RLS) allows you to restrict which data users can see based on their identity.

This is useful when different team members should only access data relevant to them – for example, sales reps seeing only their own accounts, or regional managers seeing only their region's data.

How it works

In your model definitions, you can use the {{user_email}} template variable. When a query runs, Supersimple automatically replaces this with the email address of the user executing the query.

Because the filtering happens in SQL, you have full control over the access rules and logic. You can reference your own permissions tables, user directories, or any other data in your warehouse to determine who sees what.

Example: Sales rep sees only their accounts

models:
  customer:
    name: Customers
    primary_key:
      - customer_id
    sql: >
      SELECT * FROM customers
      WHERE account_manager_email = '{{user_email}}'
    properties:
      customer_id:
        name: Customer ID
        type: Number
      account_manager_email:
        name: Account Manager
        type: String

When alice@company.com runs a query on this model, she only sees customers where account_manager_email = 'alice@company.com'.

Example: Regional access

Filter data based on a user-to-region mapping table:

models:
  orders:
    name: Orders
    primary_key:
      - order_id
    sql: >
      SELECT o.* FROM orders o
      INNER JOIN user_regions ur ON o.region = ur.region
      WHERE ur.user_email = '{{user_email}}'
    properties:
      order_id:
        name: Order ID
        type: Number
      region:
        name: Region
        type: String

Tips

• Manage permissions in your warehouse — use and/or create tables such as user_regions or even internal_admins in your database to control access rules. Update these tables directly to grant or revoke access without changing model definitions. This allows for centralization of permissioning logic.
• Use JOINs for complex rules — rather than hardcoding emails in SQL, reference your own permissions tables. This keeps your models clean and makes access changes a data operation, not a code change.
• Consider performance — add indexes on columns used in RLS filters
• The variable substitution happens before the query runs, so {{user_email}} works in any valid SQL context (including SQL blocks)