Challenge

GitLab’s data access was tied to its nested group structure rather than to user permissions. The consequence: customers couldn’t roll up metrics across teams they managed unless those teams shared a parent group in the application hierarchy. For any organization that didn’t accidentally mirror its data needs in its repo structure, meant most cross-team analysis was simply unavailable. The static dashboards that did exist suffered low adoption for related reasons: users couldn’t aggregate across organizational boundaries or build views for their own questions. A model that should have empowered cross-team decisions was actively preventing them.

My role

  • Led the design effort to rethink the data access model end-to-end
  • Joined customer calls with my PM to understand how the constraint surfaced in real workflows
  • Partnered with engineering on what extensions to GLQL (GitLab’s query language) would be needed to support cross-group aggregation and visualization rendering
  • Collaborated with designers across product areas affected by the change

Approach

I designed a model that decoupled data access from application structure entirely — moving access to a permission basis at the organization level, so the question “what can this user see?” stopped being a function of “where in the group tree does the data sit?” That unlocked permission-based access, self-service dashboard creation and sharing, and flexible aggregation across whatever organizational shape a customer actually had.

Data access model before and after
Data access model before and after

Engineering partnership on what was possible

I partnered with engineering to understand the constraints of GLQL and what extensions it would need to support both cross-group queries and visualization rendering. Decoupling the access model was the design move; making GLQL able to support it was the engineering one, and the two had to be designed together.

Building on shared foundations

The dashboard surfaces this work shipped through were built on the data-visualization patterns and components from a parallel initiative — see Data Visualization Design System. Reusing those foundations meant the access-model rethink could be evaluated on its own merits without each team rebuilding the dashboard UI from scratch.

Dashboard creation flows
Dashboard creation flows

Solution

A redesigned data access model that delivered:

  • Permission-based data access at the organization level, decoupled from group hierarchy
  • Self-service dashboard creation, customization, and sharing for users with the right permissions
  • Flexible aggregation across GitLab’s group structure, so customers could roll up metrics along the organizational shape that actually mattered to them
  • Extended GLQL to support data visualization rendering and cross-group queries

Outcomes

  • Customers could roll up metrics across teams they managed,
  • Self-service replaced engineering-mediated dashboard creation, reducing the bottleneck and the request load
  • Diverse workflows were supported by a single flexible model rather than per-team workarounds
  • Internal teams started to consolidated onto these dashboards instead of using third-party BI tools, reducing cost and increasing data trust