Row-level security in Explore

Explore administrators can restrict which rows of data each Explore user can see. Create Row-level security (RLS) rules on underlying data tables, organizing users into access groups, then verifying access with test users.

Overview of row-level security (RLS)

Row-level security (RLS) rules in Explore restrict which rows of data each user can see, based on their individual identity or group membership. For example:

Users can only see rows where they're the assigned underwriter.
Users can only see rows for their line of business. (They belong to a line of business group.)

Explore administrators apply RLS rules to an underlying Explore table just once, then the rules automatically apply to all models, answers, and liveboards that use the table.

Example RLS rule access patterns

Row-level security (RLS) rules identify groups and users by referencing the following system variables:

ts_username: Explore username (typically email)
ts_groups: List of Explore user groups that the user belongs to

The variables are used within two primary RLS access patterns, as shown in the following examples.

Individual: Users only see rows matching their email address

Individual user access only lets users see rows that belong to them. For example, each underwriter only needs to see their own policies. You create the following RLS rule that says, “Users can only see rows where the underwriter email address matches their Explore user email address.” ts_username() is the system variable for the Explore user email address. underwriter_email is the name of the table column that contains email address values.

[underwriter_email] = ts_username()

Group: Users only see rows matching a group they belong to

If a group of users needs to see the same rows, create an Explore user group. For example, all underwriters within a line of business (LOB) need to see that LOB’s data. In this case, you create user groups for each LOB value, such as “auto” and “homeowners”. The group name must exactly match the corresponding column value in the data. Add each underwriter to their LOB group.

Then, you create the following RLS rule that says, “Users can only see rows where the LOB value matches an Explore group that they belong to.” ts_groups is the system variable for the Explore group name. lineofbusiness is the name of the table column that contains LOB values.

[lineofbusiness] = ts_groups()

Multiple RLS rules on one table

Multiple row-level security (RLS) rules on the same table use OR logic. If you need AND logic (such as "restrict by both underwriter AND line of business simultaneously"), use an access control list (ACL) table approach instead. Contact Guidewire for guidance.

Bypassing row-level security

Explore users with the Row-Level Security (RLS) Bypass role can view all data even when it’s restricted by RLS rules. This role helps Explore admins create and test RLS rules.

Add row-level security to a liveboard

After reading this topic, you'll be able to:

Identify the dimension that will control access to data
Create an RLS group in Explore and add users
Create an RLS rule on an Explore table
Verify the RLS configuration

Before you begin

You must have the following roles in Explore:

Group Administration
Row-Level Security (RLS) Bypass

Procedures

Step 1: Identify the access dimension

About this task

Determine which columns in the data you want to use to control access. For example, for the Renewal Insights embedded liveboard, common patterns include:


Use case	Table and column names
Users only see rows for their line of business	GW_EfP_Submission_Processing_Table `lineofbusiness`
Users only see rows matching their email address	GW_EfP_Submission_Processing_Table `underwriterusername`
Users only see rows for their state	GW_EfP_Activity_Table `primarystate`

Procedure

To identify the source table and column for any liveboard:

Identify the underlying Explore model: Next to the liveboard title, select Liveboard details.
Under Data Sources see the model name.
Go the Data workspace, open the model, then select Edit model.
Under Columns, identify a column's Source table name and Source column name.

Step 2: Create RLS groups and add users

About this task

You can skip this step for individual-based RLS rules. For group-based RLS rules, create a group for each access column value and add users. A user can belong to multiple RLS groups. Because Explore evaluates multiple rules with OR logic, a user in two groups will see rows matching either group's value.

Procedure

In Explore, go to the Admin workspace, then select Groups > Create Group.
Set the Group name (not Display name). Make sure it matches the exact column value, such as auto). Do not reuse existing user groups for this purpose. Their names do not match data column values and will not filter correctly.
Set a Description that makes the purpose clear. For example: RLS group. Renewal Insights access for auto line of business. Do not for object sharing.
Set the Display name as anything descriptive. For example: RLS group: Auto line of business
Do not grant any Explore roles to this group.
Select users to add to the group.
Select Save.
Repeat for each distinct value that needs a separate access boundary.

Step 3: Create an RLS rule on an Explore table

About this task

Define the RLS rule on the source Explore table. The rule automatically applies to the Explore models, answers, and liveboards that use the table.

Procedure

In Explore, go to the Data workspace.
Select Tables and open the table that contains the access dimension.
For example, the GW_EfP_Submission_Processing_Table table.
Select Row Security > + Add row security.
Enter a Rule name.
For example: lineofbusiness_rls

Enter the Rule expression based on your access pattern. Replace column_name with the actual column name. For example:

[lineofbusiness] =
                                    ts_groups()

Option Description

Individual access [column_name] = ts_username()

Group access

Option	Description
Individual access	`[column_name] = ts_username()`
Group access	If the access column is a string data type: `[column_name] = ts_groups()` If the access column is a numeric data type, cast it to string: `to_string([column_name]) = ts_groups()`

If the access column is a string data type: [column_name] = ts_groups()

If the access column is a numeric data type, cast it to string: to_string([column_name]) = ts_groups()

Select Save.
Repeat for each RLS rule.

Step 4: Verify the RLS configuration

Procedure

Test all data:

Log in as a user with the Row-Level Security (RLS) Bypass role.
Open the liveboard and confirm all data loads correctly and is all visible.

Test an RLS rule:

Create a test user who belongs to exactly one RLS group, or whose username maps to specific rows.
Log in as the test user.
Open the liveboard.
Confirm that only rows matching the assigned value are visible.
Confirm that rows for other values are not visible.

Troubleshooting RLS rules

User sees no data at all: The user isn’t in any RLS group or the group name doesn’t match a column value exactly.
User sees all data: The RLS rule was applied to the wrong table or the rule expression has a typo.
Rule expression error on save: Column is a numeric type. Cast it to string: to_string([column_name]) = ts_groups()

Remove RLS rules

Procedure

To remove an RLS rule from the table:

Go to the Data workspace, open the table, then select the Row Security tab.
Select the delete icon next to the rule.
All users immediately see all rows.

To remove a user from an RLS group:

Go to Admin > Users and select the user.
Remove the group from Group membership.
Select Save. The change takes effect the next time the user views the data.