User Guide Getting Started Help Center Documentation Community Training
Looker
Designing and Configuring a System of Access Levels

Looker’s system of access levels determines which users may edit and view content in Looker Spaces. Access levels are designed to support many different systems for managing user access to content. In general, though, access level systems fall into one of three broad categories:

Access Level System Description Recommended Use
Completely open All users can view and modify all shared content. This is Looker’s default configuration. An open system is recommended for small companies or teams using Looker, companies with open policies about data, and companies where sharing editable reports is a primary use case.
Open, with restrictions Access to shared content is restricted in some way, either so that only certain people can edit certain content, or so that certain content is entirely invisible to particular people. An open system with restrictions is recommended for medium-sized or larger teams and companies, highly diversified user bases where reports aren’t relevant to everybody, or companies that want content to be viewable by everybody but editable by only a few.
Closed Also called a multitenant installation, this system silos content to certain groups and prevents users from different groups from knowing about each other. A closed system is recommended for whitelabel use cases where customers host their clients into the system, but clients may be from different companies or groups and should not know about one another.

This page discusses best practices for configuring each of these categories of access levels.

Understanding Space Hierarchical Inheritance

Before designing a system of access levels, it’s important to understand how access levels in subspaces are inherited from their parent Spaces.

The top level of the Space hierarchy is the Shared Space. Access levels flow down the hierarchy and are inherited by subspaces of the Shared Space, and then subspaces of those subspaces, and so on.

The different access levels behave as follows:

Access Level Inheritance Pattern Description
Manage Access, Edit Flows all the way down the Space hierarchy Once you give a user access to Manage Access, Edit in a Space, they have that access level to all Looks, dashboards, and subspaces within that Space; you won’t be able to lock down their access at a lower part of the hierarchy.
View Can be removed at any point in the hierarchy The View access can be removed at any point lower in the hierarchy (unlike the Manage Access, Edit access, which flows all the way down). Removing View revokes a user’s ability to see that Space and all its content.

Looker admins have Manage Access, Edit to all Spaces and therefore all content. This ensures their ability to manage the system, prevent orphaned content, and assist any user who runs into issues.

Configuring a Completely Open System

This is Looker’s default configuration. The All Users group is assigned to Manage Access, Edit on the Shared Space, and all subspaces within the Shared Space are set to inherit from it:

Once a user has Manage Access, Edit on a Space, they have Manage Access, Edit to all content in that Space, including all subspaces under it. That means there are no restrictions to content access in this system.

Personal Spaces exist in a separate hierarchy, and those are set to match defaults, too. The All Users group is set to View on all personal Spaces, and each user determines whether to make their Space private or not:

Configuring an Open System with Restrictions

You need to be an instance admin to fully configure your system in the way described below.

To configure an open system with restrictions, perform these tasks (described in the sections below):

  1. Plan out your structure.
  2. Configure groups to provide granular access.
  3. Change the access level of the All Users group for the Shared Space.
  4. Remove All Users from any Space you don’t want viewable by the whole company.

Plan Out Your Structure

Who do you want to allow to view and edit particular Spaces? It makes your life easier if you sketch out your plan before you start configuring access. This also gives you a place to check off changes as you go through the process, so you don’t have to go back to check on various Spaces.

One of the most common configurations is to have one Space per department or team, which looks something like this:

Configure Groups to Provide Granular Access

If you’re planning to restrict access to content, Looker groups make things much easier. Groups can be granted access to Spaces and subspaces the same way that users are, and groups can contain other groups. For information about how to configure groups, see the Groups page.

Start with the Spaces inside of Shared first. Because permissions flow down the hierarchy, it’s safest to begin by manipulating the access to the lowest subspaces and then move up through the parent Spaces and change their access levels next. In this example, we’ll start with the subspaces inside of Shared first.

Set each Space within Shared to A custom list of users and assign Manage Access, Edit to the groups and users you want to be able to edit content, then assign View to groups and users you want to have read-only access:

Until you change the settings for the Shared Space, nothing goes into effect. The access level for the All Users group is set to Manage Access, Edit in the Shared Space and flows down through all individual subspaces. You cannot modify the settings for All Users in individual subspaces until the access level for that group is changed in the Shared Space.

For the initial setup, we recommend using the Content Access section of the Admin panel, as it’s a single place to make changes to each Space. Click on the Space you want to configure and then click Manage Access:

Change Permissions of the All Users Group on the Shared Space

This is when your changes go into effect. Remember to consult the plan for your structure. If you want everyone to be able to view all content in your system, change All Users from Manage Access, Edit to View:

If your plan is to display certain subfolders only to certain groups, continue to the following section.

Remove the All Users Group from Spaces You Don’t Want Viewable

If you want any Spaces to be private to a certain subgroup of people, go back and remove All Users completely using the X to the right of its access level. The Space only shows up for groups and users you explicitly list:

Configuring a Closed System

Only enable the Closed System option if you plan to whitelabel Looker for your customers. Internal use cases should use a different system. You need to be an instance admin to fully configure your system in the way described below.

Creating a closed system in Looker involves enabling the Closed System option, which causes three core changes to Looker:

To configure a closed system, perform these tasks (described in the sections below):

  1. Ask for the Closed System option.
  2. Plan out your structure.
  3. Configure groups to provide granular access.
  4. Enable the closed system in the Admin panel.
  5. Give each company group in your system View access for the Shared Space.
  6. Configure access levels for each subspace of the Shared Space.
  7. Migrate content into subspaces.

These steps assume that no content for multitenant users is currently housed in the Share Space.

Ask for the Closed System Option

Contact your Looker account manager or support@looker.com to ask that the Closed System option be enabled for your instance.

Plan Out Your Structure

It makes setting up your system much easier if you have set up your plan in advance. There are two main areas to think about.

First, be sure to create a group for each company. A company group associates all users from each company together, and keeps those users separate from other companies.

Secondly, consider whether you’ll want to have multiple companies looking at the same Space (for example, for dashboards that are relevant to all companies), or whether you’ll want one top-level Space for each company (for distinct content that only applies to a single company).

Configure Groups to Provide Granular Access

While there should be at least one group per company, there may also be subgroups within that group. If you would like to allow some users at a company to edit and manage content, and allow others only to view content, we recommend creating separate subgroups for those different types of users. For example, Company A as the umbrella group, Editors at Company A as a subgroup, and Viewers at Company A as another subgroup:

All groups that pertain to an individual company should be housed under one umbrella group.

For information about how to configure groups, see the Groups page.

Enable the Closed System Option in the Admin Panel

It’s best to enable the Closed System option before setting up any access controls on Spaces, since enabling the Closed System option makes changes to your system, as discussed above. Enable the option by going to the Settings section of the General panel in Looker’s Admin section:

Give Each Company Group View Access for the Shared Space

Grant View access to each company group for the Shared Space. This lets members of those groups access the Shared Space and see their own company’s Space within it:

Configure Access Levels for Each Subspace

Set access levels for who can view or edit content in each subspace. This should include removing other companies who had View access to the Shared Space from subspaces that are specific to a certain company:

In the above example, we selected A custom list of users and Company B was removed from Company A’s content. Company B can’t see that Company’s A’s content exists.

Migrate Content into Subspaces

If your company had allowed users to see their own Space and certain other personal Spaces, we recommend migrating any content from those personal Spaces into the appropriate folders in the main Shared hierarchy.

Top