Explains what the feature is or what its benefits are to the user or customer.
Legacy Row Level Security is no longer used. This documentation is retained to support implementations that are already using this method.
If you're setting up row level security for the first time, see About Rule-Based Row Level Security. That is the preferred method. It supports thousands of groups, and is easier to set up and maintain then Legacy Row Level Security.
This legacy version of row level security allowed you to define which groups could see individual rows in a table, based on the values in a column.
Legacy Row Level Security settings
You define the rules for row level security by editing the security file in Excel. Each row in the file is a rule, consisting of:
Best practices for using Legacy Row Level Security
- Give users access to worksheets instead of tables.
For each table that uses row level security, you should create a worksheet and share it, so that users can search it instead of the underlying table. The worksheet must include the column(s) where the security rule(s) are defined. Then remove access to the table where you applied the row level security. This is the safest way to ensure that users never see any data from rows they shouldn't see.
Row level security only applies in searches that include the column on which the security rule is defined. So if a user has access to the tables directly, they could do a search that omits the column that has the security rules applied, and then see the data in the other columns. But a worksheet that includes the column with the row level security definition will always hide all values from rows that don't satisfy the row level security condition.
Because of this, it is a best practice to always use worksheets with row level security, and remove access to the underlying tables. This will ensure that groups can only see the data that is defined as visible to them.
- Explicitly grant access for users that should see all rows.
As soon as you create a row level security definition on a table for one group, all other groups are then blocked from seeing any rows in the table. You have to specifically grant other groups access in order for them to see any rows.
If you want to ensure that a group can always see all rows in a table, grant them NE (not equals) privileges on a dummy value that does not appear in that row. For example, these settings would enable users in the group Managers to see all rows in the Sales table:
- Managers Sales Region NE xxx
- The operations GE (greater than or equal to), GT (greater than), LE (less than or equal to), and LT (less than) are meant to be used with measures (numeric values) and not with attributes. Though they technically can be used with attributes, they would be applied based on alphabetical order, which could return confusing results.
Row level security with multiple conditions
When multiple row level security rules apply, the permissions are additive. That is, when there are multiple row level security conditions specified on a table, they are applied using an OR operator. These examples will help you understand how this works in practice:
In this example, the group Analysts has two separate security entries for the Region column in the Customer table. One entry allows Analysts to see rows where the Region is equal to West. The other allows them to see rows where the Region is equal to East. So users in the Analysts group will be able to see all the rows in either Region.
In this example, a user is a member of two groups: Analysts and Sales. The security file lists different permissions for each group based on the column Category. Analysts can see rows where Category is equal to Consumer and Sales can see rows where Category is equal to Enterprise. So the user who is a member of both groups will be able to see all the rows where the Category is equal to either Consumer or Enterprise.
It works the same way with ranges and between operators as with equality. The user will be able to see any row that fulfills any of the conditions.