Dashboards are essential to transform complex data into clear, actionable insights to make business decisions for practically any environment. But simply creating a dashboard isn’t enough. To truly unlock their value, you need to implement a robust dashboard lifecycle management strategy.
A well-defined lifecycle for your Looker content is fundamental and can help your data teams set clear expectations to ensure your dashboards remain relevant and add value over time.
Looker Dashboard Lifecycle Framework
It’s crucial to establish a clear content lifecycle framework, including where contents are saved, who can view the dashboards and to define Service Level Objectives (SLOs). The framework below guides your Looker content from its initial ideation through development, deployment, and eventually, deprecation.
Organize Your Contents: Personal, Shared, and Boards
To foster a collaborative, yet organized, environment for developing contents, we recommend a clear distinction between development, staging, and production phases. This approach ensures a judgment-free zone for experimentation while providing a structured path for review and eventual deployment.
1. Personal Folder: Development Sandbox
The Personal Folder in Looker is a dedicated sandbox environment. This is where all dashboard creators should save their works-in-progress and use as a space to:
- Experiment: Test new ideas, explore different visualizations, and iterate on designs without impacting others.
- Keep private: Your work remains private until the content is ready to be shared with others
2. Shared Folders: Staging and Review
Once a dashboard is ready for a broader input, it’s time to move it into a Shared Folder dedicated for staging and review. This is a critical step in the lifecycle, allowing for collaborative feedback and quality assurance before a dashboard goes live to a wider audience.
By separating these stages, this ensures that:
- Development remains agile: Individual creators can work efficiently without cluttering shared spaces.
- Review processes are streamlined: When a dashboard moves to a shared staging folder, it signals that it’s ready for testing and feedback from relevant stakeholders.
- Quality is maintained: This structured approach helps catch issues early and ensures only validated dashboards proceed to production.
Dashboard Review Workflow:
Here’s a streamlined workflow to review dashboards:
- Develop in your personal folder: The analyst develops the dashboard in their Personal Folder.
- Move to shared for review: When the dashboard is ready for review, the analyst moves it to the relevant folder within the Shared Folders.
- Initiate review via ticket: The analyst then raises a ticket in your chosen ticketing system, including a direct link to the new dashboard. This ticket should be shared with the relevant reviewers, typically a selective group of end business users.
- Review dashboard: Relevant stakeholders review and provide feedback on the dashboard. During this stage, it’s critical to log all feedback and discussions in a single, accessible place to streamline future conversations and avoid time-consuming re-discussions.
- Formal communication of approval: Once the dashboard design is stakeholder-approved (e.g. LGTM message in the ticket or chat), formally communicate to the wider audience that the dashboard is ready for a broad usage. This signals its readiness for promotion to a production Board.
3. Board: Curate contents in Production
For dashboards that have been approved for wider usage across the organization, boards (and LookML dashboards) provide an effective way to organize and present critical insights.
Here are the benefits of using Boards:
- Curate user experience: Boards allow you to add sections and context to groups of dashboards and sort them based on importance, providing a more intuitive navigation experience for business users.
- Content Reusability: Dashboards can be reused and pinned across multiple Boards, reducing duplication and ensuring consistency.
- Integrated Content: Boards aren’t limited to Looker content. You can pin external URLs to them (e.g., reports from other BI tools), making them a central hub for all your team’s important data assets.
- Separation from staging and production: Using Boards establishes a clear separation between Production and Staging phases . When a business user accesses a dashboard from a Board, they can be confident that they are officially approved dashboards.
For Board-pinned dashboards, it is important for the owner (or central data team) to commit to maintaining strong Service Level Objectives (SLOs) to ensure user confidence. For example:
- 99% Uptime and Performance: Expect no broken tiles and a relatively fast load time (e.g. under 10 seconds).
- Sub-1-Hour Response Time During Business Hours: In cases of data discrepancies or errors, someone from the data team should triage the issue within an hour of it being reported.
- Clear Escalation Process: After an error is triaged, stakeholders should not have to chase for who is responsible for the fix, the expected turnaround time, or the reason for the issue. Following a fix, an incident report should be filed to ensure the data team can plan to prevent similar issues from recurring.
[Strategic dashboard management]: Convert to LookML Dashboards for Maximum Stability
For dashboards that require version control, collaborative development, standardized design, or a seamless deployment across environments, consider converting them to LookML dashboards. While this adds some additional overhead for future changes, the benefits for stability and maintainability are significant. We don’t recommend this for all dashboards, especially short-lived dashboards.
The advantages of LookML dashboards include:
- Version Control: Easy rollbacks to previous versions if issues arise and enables developers to track changes to the dashboard
- Early Error Detection: Errors are caught during LookML validation, often before deployment.
- Seamless Multi-Instance Deployment: Simple deployment across different Looker instances via version control.
- Zero Downtime Updates: Update dashboard references along with LookML changes in a single merge, preventing broken dashboards.
Here is an outline of the process for an analyst:
- Copy the LookML code from your Staging dashboard (after the review process).
- Create a new dashboards folder in your LookML project
- Paste the code into a new LookML file e.g. business_metrics.dashboard.lkml
- Merge these changes via your standard LookML commit workflow.
- Pin the LookML dashboard (from the Shared LookML Dashboards folder) to the Board.
To edit an existing LookML dashboard, you can either directly edit in LookML code or:
- Import the LookML dashboard to your Personal Folder (this converts it back to a user-defined dashboard).
- Edit the copy.
- Review and approve the dashboard (as outlined in the staging and review section).
- Copy the updated LookML back to the original LookML dashboard file, ensuring the dashboard ID remains the same.
- Delete the copy in the Personal Folder.
[Tips] If you want to make changes to LookML dashboard via the API, you can also utilise dashboard(), update_dashboard() and sync_lookml_dashboard() endpoint to programmatically sync between UDD and LookML dashboards. For more info, refer to this community blog here.
Tracking changes to User Defined Dashboard (UDD) : alternative workaround
For users without LookML developer permissions, tracking changes to your dashboards can be tricky. Typically, you would need to collaborate with a LookML developer to convert your UDD into a LookML dashboard, and go back and forth every time you want to track a change.
As an alternative workaround, you can set up the Looker API (e.g. dashboard_lookml(dashboard_id)) to regularly capture and store dashboard definitions over time. These snapshots could then be used to restore UDDs to previous versions. However, this custom API solution usually involves significant development effort and ongoing maintenance, making it a far less efficient or robust approach compared to the inherent version control capabilities offered by LookML dashboards.
For the most comprehensive and reliable change tracking, we recommend converting UDD into LookML Dashboards. This enables you to leverage version control tools like Git, providing a complete history of every modification, who made it, and the ability to revert to previous states. While this approach does require some LookML development expertise, the benefits in terms of auditability and collaborative management of your dashboard ecosystem are significant.
[Tips] We recommend setting up Looker Continuous Integration to run the Looker content validation as part of the overall development workflow, to test for errors in Looker contents before changes are merged into production and affect the end users. For more info on Looker Continuous Integration, check out the documentation here!
4. Deprecating old dashboards
As part of the content lifecycle, we also need a robust approach to dashboard deprecation. You should regularly go through the content in your Looker instance and delete content that isn’t being used.
For example, contents:
- in Personal Folders that were created >90 days and never made it out of development
- in Shared folders that have since been upgraded to production as a LookML dashboard
- on Boards or in Shared folders, but the business is no longer using
Best practice would be to host a quarterly meeting with all of your team members to “clean up” contents by going through every dashboard in your team’s Shared Folder and make a decision to clean up old dashboards:
- Do nothing (i.e. “this dashboard is still in review”)
- Pin to Board (i.e. “this dashboard is ready to move to Production”)
- Convert to LookML (i.e. “this dashboard is critical and needs higher reliability”)
- Schedule for deletion in 7d (i.e. “this dashboard can be deleted but need some time to migrate”)
- Delete now (i.e. “this dashboard is irrelevant and can be deleted now”)
- Transfer ownership (i.e. “Sam has left the company, let’s transfer to Jenny”)
Once you’ve identified the content that needs to be deleted, you can delete it manually or script it. It’s best practice to give content owners some advance notice and the reason why their dashboards are being deleted.
Building trust through content lifecycle management
This content lifecycle is a blueprint for Looker administrators and developers to nurture their dashboards. From initial development in Personal Folders to their final display on production Boards, each dashboard matures through stages with clear expectations and service level objectives.
Fundamentally, implementing a robust content lifecycle management isn’t just about managing dashboards; it’s about cultivating a data-driven culture that prioritises precision, clarity, and continuous improvement.
Ready to elevate your Looker environment? Start by assessing your most used dashboards and identifying opportunities to bring them under a structured content lifecycle today.
