Skip to main content

​
Page Level Access Control

By default, all published pages are visible to everyone with access to the project. Page level access control allows you to specify who can view a published page. To configure who can see a page:
  • Navigate to the page in the “Editor” view
  • Open the “Share” menu in the top right corner of the page from the “Edit” view
  • Use the dropdown under “Manage Access” to configure access settings

​
Options

  • Everyone with access to the project (default) - everyone in the team will be able to view the page
  • Only specific people - you can add specific users to the page
Users with the Developer or Admin role can always view all pages.

​
Row Level Security

Row level security allows you to control who can see specific rows of data in a source. To configure row level security, first open the Access Settings for your organization. To apply row level security to a source, you need:
  • A Rule: A rule specifies which tables are affected, which column should be used to determine access, and which user variable will be compared with the column
  • User Variables: A user variable is a value set for each user to match rows against the column in the rule.
  • The rule can be configured to either apply to everyone or to no one by default. If set to “apply to no one,” you are responsible for manually granting access to specific users.
Users without defined user variables cannot access any rows in tables with RLS rules.
It can take up to 5 minutes for user variables to apply. During this time, users will not be able to access any rows in tables with RLS rules.
You can Preview the impact of a rule for a user by using the Access Preview tool. Select a table and user to see how many rows they are able to access.

​
Example

You have a “leads” table with a “sales_rep_id” column containing the id of sales reps. You want to allow sales reps to see rows with data about their own leads.
lead_namedeal_stagesales_rep_idsales_rep
ACMEProspect1John Doe
ContosoProspect2Jane Smith
FabrikamProposal2Jane Smith

​
Create a Rule

  • Column: sales_rep_id
  • Operator: =
  • User Variable: rep_id (or any name you want to use)
  • Apply to tables: leads
⚠️ The IN and NOT IN operator only support string as user variable at the moment

​
Create User Variables

  1. Create a user variable for John Doe
    • Variable: rep_id (must match column above)
    • Value: 1
    • Users: Select “[email protected]” from the dropdown
  2. Create a user variable for Jane Smith
Now when John Doe views the “leads” table, they will only see rows where the sales_rep_id column matches their id. When Jane Smith views the “leads” table, they will only see rows where the sales_rep_id column matches their id. Here’s a reformatted and reworded version:

​
JSON Format

User variables are saved using JSON format, where the value type must correspond to the column type in your database table. Saving numeric arrays (for use with IN operators): 
[1, 23, 30]
Saving string arrays (for use with IN operators): 
["abc", "true", "22"]
In this example, both true and 22 will be stored as strings, not as a boolean or number. Saving a string value (for use with = operators): 
"123"
Saving a numeric value (for use with operators like >): 
123
⚠️ Note: Numeric values are stored as UInt64 type. Saving a boolean value: 
true

​
Access Preview

You will see the following:
  • 33.3% accessible
  • Total rows: 3
  • User can access: 1
  • [email protected] is bound by access rule