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

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 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 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.

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.

@sondra.orozco could you give an update on the roadmap? This feature is pretty essential and we are currently using workarounds to deal with the problem.

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.

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.

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.

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.

plus 1 - we’d like to use Look ML dashboards for development and then push updates to existing dashboards in spaces without changing the dashboard URL.

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.

Any updates?

Ok, it looks promising, but I wish to get some visibility over the future of this feature for the EOY 2019 as it’s becoming increasingly difficult to maintain dashboards at scale 🙂

Userlevel 5

Pumping this since half a year has passed. Anything new we should be excited about?

Userlevel 7
Badge +1

Check out what I told @tnebesar over here:

In working to build the full feature, we’ve exposed some of the endpoints necessary to sync LookML Dashboards in the Experimental API 3.1, which you can see by logging into the interactive API docs on your instance and switching the dropdown from 3.0 to 3.1

Userlevel 7
Badge +1

I don’t think we have a timeline for phase 3 yet (I realize it’s been a lot longer than we guessed at so long ago, and we’ve committed to providing better estimates when we do from now on).

I hear all of those issues with that workaround, that makes sense. I think the sync_lookml endpoint I mentioned to tim above only goes one way, LookML —> UDD, so that wouldn’t work for your situation. We’ll take all your context and take it into consideration when we build our next step of dashboards.

Do you have an update when this phase would be released? We are using LookML Dashboards, but it’s really painful to make manual layout additions (especially if it’s a new tile inserted halfway up the page, since we have to then manually update the row for every single subsequent tile).

My workaround has been to convert the LookML Dashboard to a UD Dashboard, make GUI changes there, then grab the LookML generated from that and copy it back over to the original LookML Dashboard. Some problems with this include:

  • The generated LookML is not valid, and I have to manually update it to be valid. For example, we have a bunch of “spacer” tiles to manipulate the layout of the page, but they all have the name “”, so I have to manually make them unique. Also, there are some tiles which are created with periods in the name/title (ex: “Actual vs. Prior Period”), and while it is valid for the title to have a period, the name cannot include a period.

  • The order of the elements in the code is not reliable; I wish it would at least order it in row-order, vs. seemingly random. This makes it really hard to maintain changes to the dashboard.

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!

Hi Ian,

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

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

Hi @sondra.orozco,

Are there any updates on the Lookml->Space sync functionality?

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.

Userlevel 5

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

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.

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.