These best practices reflect recommendations shared by a cross-functional team of seasoned Lookers. These insights come from years of experience working with Looker customers from implementation to long-term success. The practices are written to work for most users and situations, but as always use best judgment when implementing.
Managing users properly is crucial to ensuring that only the appropriate people have access to particular data, features, and content within Looker. Unless you have a completely open system, it will be important to implement a strategy for managing users that ensures that all data and content is secured. Using groups will help with this and can prevent the need to add, manage, and update user access at the individual user level.
Map out permissions
Begin by making a high-level plan and mapping out the permissions and access that will be required across your user base.
- Identify the different data sets available within Looker and the combinations of these that should be available to different user groups. If your organization only has one model, this is easy. If your organization has several models, there may be a few different combinations of models (model sets) that need to be created.
- Identify the different user types that you have. Common users include people who can view dashboards but not explore data, people who can explore data but not write LookML, people who can write LookML, and administrators. The features that each of these user types will be able to use should be setup using permission sets.
- Think about how the data access (model sets) and feature access (permission sets) intersect. For example, there may be a large number of users who can only view a single model and can only view dashboards. This data and feature access would be combined to create a role.
Map out groups
Then think about the functional groups within your user base, i.e. Sales, Finance, etc. These functional groups should correlate to Groups within Looker. Groups can be used to secure content (i.e. dashboards and Looks).
- For example, you might have a Sales department in your organization, and inside of that department, there may be several account executives alongside a small sales operations team. You could create a Sales Group in Looker, and then create two subgroups inside of the Sales Group: one subgroup for Account Executives and one subgroup for Sales Ops. The Account Executives group might map to a role with viewer permissions, and the Sales Ops group might map to a role with explorer permissions.
- Access to spaces and therefore content can now be managed using these groups. For example, a Sales space could be created within the Shared space that only the sales department can see. Account Executives can be given View access on that space, while the Sales Ops team might have the ability to manage access to that space and edit content within it.
- Changes to access or permissions for the entire sales department can be managed using the Sales group.
- Changes to access or permissions for either Account Executives or the Sales Ops team can be managed at the subgroup level.
- New users can be added to the appropriate group and will automatically inherit the appropriate permissions.
Apply controls at the group level
- When setting up users, do not give any roles directly to the user. Simply assign each user to a group. Users given individual roles and roles based on group membership will inherit all roles from both the individual and group assignments.
- Take care when placing users in multiple groups. Users in multiple groups get the SUM of privileges of all the groups they’re in, so ensure that users in multiple groups are still limited to the appropriate level of access.
- When possible, assign user attribute values at the group level.
To see these practices applied, please check out our article on setting up secure content access.