Who uses LookML dashboards?

  • 22 February 2017
  • 49 replies

Userlevel 2


I’m having a discussion with myself that I decided to open up to the community. Four questions have been on my mind:

  • How many of you actively use LookML dashboards?

  • Do your users get confused when they are dealing with LookML dashboards vs User defined dashboards?

  • Is it time consuming to recreate a User defined dashboard as a LookML dashboard?

  • Are LookML Dashboards part of Looker’s roadmap? I’m curious because they seem to still use old lookML.

Where I’m coming from:

Since I started using looker, my team has always used looker defined dashboards. It’s GUI and easy. However, I’ve been caught in a situation a few times where I end up updating a dozen looks in a dashboard, which ends up taking a long time & doesn’t have a lot of transparency.

There are some situations where I’m thinking it would be easier to just have a LookML dashboard, so I can quickly make updates via code rather than manually updating Looks, but I don’t have enough experience with Dashboard LookML to know if that will end up being even more time consuming.

Just looking for thoughts from large-brained people.

49 replies

I’d really like to be able to use LookML Dashboards because they are under source control and can be versioned with my model, and because when I make changes, anything I’ve broken will be found by the validator.

The big drawback is that the Newspaper layout is only available with user dashboards, and all our dashboards are designed using it.

The layouts available for the LookML dashboards are either limited or completely broken and unusable. The tile layout is probably only good for very basic dashboards and the grid layout doesn’t offer row/column spanning (which would make it a workable replacement for the Newspaper layout).

The static layout makes it sound like you can achieve similar effects as the Newspaper layout, the problem is it’s is both broken and static. Broken in that, unless you specify the top, left, height and width for every element, they will render as a jumbled mess. So you literally have to hard-code the whole thing. Except that the margins/padding are all broken, and there’s no way to say “Make the left most element 300px wide, and the right most element can consume the rest of the width”, so you have to have fixed-width layouts.

Like I said, I’d love to use the LookML Dashboards, but they feel like a completely abandoned and half-implemented feature.

I’d also like to add that another benefit of the LookML dashboards is that you can actually demo the changes you make in your models in development mode. With user-defined dashboards, you basically have to break all your dashboards either until you publish, or after you publish until you’ve updated them all.

Userlevel 3

Hey @Sam_Wilson,

We are very aware of these issues and have some plans to consolidate the world between LookML dashboards and User Dashboards.

Unfortunately, in today’s world, the cadence between rolling features out between these two dashboard types have been staggered and we definitely want to move towards a universalized world where both share the same features and functionality in terms of layout, organization, and editing. We also know the value of storing the dashboards as files for source control and migrating content between Looker instances.

We’re actively working on this so please stay tuned or if you have any questions reach out to your account manager so we can update you as progress is made on this front. We’re not abandoning LookML dashboards!

Userlevel 3

For what it’s worth we’ve completely abandoned LookML dashboards and have made everything the responsibility of the user. I’ll admit this is at least partly motivated by my own laziness, but we don’t miss them, not really.

Glad to hear you are working on it. This was seen as a key value proposition for me with Looker.

I definitely like having both options. We offer a baseline set of dashboards, and also want to support user-generated content, and appreciate the GUI/ease-of-use with developing the non-LookML Dashboards.

If there’s an issue tracker where I can up-vote something like this and track progress, that would be nice as well.

Userlevel 5

Hey @Sam_Wilson - discourse is our public-facing issue tracker. There’s a Feature Requests section that you can use when leaving upvotes and +1s - and we do watch those seriously.

In this case, LookML dashboard work entails a lot of individual issues! If there’s something particular you’d like, upvote or create an article within the Feature Requests section and we’ll make sure it gets seen by the right people.

Thanks! I’ll do that.

Userlevel 3

The way I see it, user dashboards should be as fully configurable as LookML dashboards and have the option to save down to LookML for Git versioning. Some dashboards become business critical and should have a PR process associated with them.

Userlevel 5

We got a feature request for that @Alex_Hancock - would love your feedback here:

Userlevel 1

We use Looker as an embedded BI tool, so we use LookML dashboards almost exclusively at the moment for three reasons:

  1. Version control

  2. The ability to use an actual release cycle and github pull requests

  3. the “extend” parameter, which allows us to make base templates and derived dashboards from them, which dramatically simplifies the process of propagating changes across dashboards.

We also use LookML Dashboards extensively, though, only for embedding. I have no issues with the layout per se, though I would be very interested in improvements.

LookML have the benefits you list, and I would rather author dashboards via LookML. And, I need to use them, because I’m usually prototyping a dashboard that will then be modified programmatically, and then this is pushed out into multiple projects.

However, as well as the confusion for end users that you mention, I think it’s worth considering whether you’ll be let down by the content management and discovery of LookML dashboards. I would argue that content management and discovery of LookML dashboards is so bad in Looker that you would be well advised to stay away from them if you can. After all, getting the content you develop used in your organisation and useful for other people is probably the point of doing it.

Here are my thoughts on why you would not use them.

The main discovery issues:

  • LookML dashboards are listed separately from all the other content in Looker, i.e. undiscoverable through Spaces.

  • LookML dashboards are presented via their own separate page, and on this page the Looker user is presented with an unfiltered list sorted alphabetically regardless of what Model they belong to. In my case this list is 1000 rows long.

  • In the Search Results, LookML dashboards are not listed in the Dashboards section. Instead they are in the 3rd set of search results like some kind of outcasts.

Other discovery issues:

  • LookML dashboards do not appear in the Top Content list.

  • Lookml dashboards cannot be made as Favorites.

  • LookML dashboards do not show up as Recently Viewed content.

  • The dropdown navigation box (top left) on a LookML dashboards links the user to every single other LookML dashboard. In my case I get a dropdown list of 1000 links.

  • LookML Dashboards are named like something that only people with developer mode should be seeing it. Most end users of Looker will never edit (or know of) LookML so why use such an esoteric name as their label? Personally, I would label them Curated Dashboards. (Well actually I’d just rather label them Dashboards and have them with the rest of the Looker content.)

Plus, they’re missing from Usage reporting, so you can’t really tell is they’re used or not. You’ll have to know what Explores are being used within them and work back from that.

Regarding the LookML dashboard roadmap:

I was told in 2014 that better organisation of LookML dashboards was coming, but actually since then the organisation of them has gotten worse - the long LookML Dashboard list used to be filterable.

So while I’m sure better support for LookML dashboards is on a roadmap I’m guessing it’s a fairly low priority and not something one should rely upon.

Userlevel 1

I think this is really important. @Andrew_Kraemer thanks for starting the conversation and @sam, @mikhailxu please let me know where to vote to prioritize this consolidation!

The BI team in my organization owns the data analysis stack, including our EL and ETL tasks, database maintenance, and Looker modeling, and we are also the biggest users of Looker; answering questions directly and sharing the results via links, curating content in the form of dashboards, and helping other users answer their own questions by pointing them in the right direction.

A previous analysis / reporting tool used in our organization had gotten messy because all users were allowed to save and publish content, and there wasn’t much centralized governance in terms of naming conventions, ownership/maintenance of content, and discovery/organization of content (the result of a lack of planning, also an inferior tool).

Given that experience, we wanted to tread lightly when we introduced Looker, and put a lot of thought into how content would be curated / presented. I just posted on a different thread a little about our model development pattern, and given that underlying Looker project organization and our prior experience, we are leaning towards exclusively developing LookML Dashboards.


  • Dashboards are guaranteed to be consistent across models (because there is only one place where the elements are coded)

  • Dashboards are validated

  • Source control allows us to go back if we break something


  • Content discovery / Favorites / Spaces are unusable (not the end of the world with limited content; we may add our own simple directory of dashboards)

  • Some confusion around what model is being referenced, since the dashboard title is the same across all models (we are investigating using extends to address this)

  • Balancing act between being a bottleneck and doing responsible platform governance.

Userlevel 5

Looks like you found the right place - LookML Dashboards don't work with Spaces would be the most apt feature request for consolidation of LookML and User-Defined Dashboards.

I would echo Jay Stricks above… we use LookML Dashboards for embedding, and we rely on the ability to version control dashboards as part of our deployment process. The fact that the validator runs against LookML Dashboards is a huge benefit when I’m changing a model.

The UI differences between user-generated dashboards and LookML dashboards is an issue for my organization. We are making UI changes in the user-generated dashboards and then finding that the newspaper layout does not translate to LookML. Is there any movement on synchronizing the two, so we can create the layout using the GUI and copy source to the LookML Dashboard?

Hi abbywest,

A few questions -

You’ll no longer have to use the Import to Space functionality (which breaks the association with its LookML) to expose LookML dashboards in Spaces

Will this association with a Space be done in the LookML definition of a dashboard? Or will there be some other UI action to be performed? We roll out our LookML dashboards to 30+ instances and it would be great if this was all source controlled too.

The ability to expose LookML Dashboards in Favorites & Top Content

Will this also allow usage monitoring of these dashboards via i__looker? I’ve raised this feature request:

as it’s a very big issue for us.

Userlevel 7

abbywest hows the progress with the 3 phase plan going, any idea about a timeline for this?

Userlevel 2

Hi Ian,

I just checked in with our product team, Phase 1a was released in 4.12, and they are still actively working on the remaining phases. You can expect more pieces to be released over the next few months!

Hi Ian,

Is it correct to say we’re not at 1b yet?

Userlevel 7

Hi Andrew, you got the wrong person here, you want @Jiro Im ian@king, was looking out for you at Join but don’t think you made it.

Im happy to make a stab at the answer being a NO though.

Userlevel 2

Hey @andrewk,

as @IanT mentioned we are not there yet. LookML Dashboards aren’t able to be favorited, they’re technically not considered “content” since they’re not stored in-database and thus don’t live in Spaces. There is work going on it but just not yet completed.



Woops. Thanks @IanT! Both for setting me straight and realistically setting my expectations.

Userlevel 7


Is there an update on this? We are embarking on a project where lookml dashboards (at the end of the 3 phases) would be ideal. It would be great to get a feel for if the phases/steps are miles off, some steps will be ready soon or if all steps and phases are going to be released in one big bang. It would really help for planning and putting together processes at this exact moment.


Hi Ian,

We have had to make some changes to the plan, and unfortunately we are not close to phase 3. We are getting closer to completing phase 2, but will provide this functionality via API, not through the Looker UI.

In our current plan, we’ll be addressing the desired outcomes of 1b and 2 described above by providing API endpoints for two things:

  1. letting you move a LookML dashboard to a Space where it will exist just like a User Defined Dashboard (you can already do this today in the Looker UI, but API endpoints are not yet available), and

  2. allowing syncs from LookML to the dashboards in the Space (this will enable you to make edits in LookML and push those up to the dashboard your users are interacting with).

Using this workflow, you’ll be able to continue to take advantage of the benefits of LookML dashboards, but also have a version of those dashboards living in Spaces where they can also be surfaced in Favorites and Top Content. We are targeting Q3 for delivery of those API endpoints.