feat(dashboards): Add optional onboarding widgets for prebuilt dashboards

[gggritso]

Extends the prebuilt dashboard configuration to optionally declare an onboarding condition so the renderer can show onboarding when no selected projects have relevant telemetry data.

Prebuilt dashboards always render widget grids, even when no selected projects have relevant telemetry. The Insights module pages handle this by checking project flags and showing onboarding panels, but PrebuiltDashboardRenderer had no onboarding awareness. This adds an onboarding field to PrebuiltDashboard configs with three variants:

• module — delegates to the existing ModulesOnboarding flow (LegacyOnboarding + ModulesOnboardingPanel)
• custom — renders dedicated onboarding components for AI Agents and MCP dashboards
• overview — shows a generic onboarding panel for multi-module overview dashboards (backend, frontend, Next.js, Laravel) when none of the required project flags are set

e.g.,

All 28 prebuilt dashboards now have onboarding configurations.

Refs DAIN-1207

[linear-code]

DAIN-1207 Add optional onboarding UI for prebuilt dashboards

[gggritso]

@sentry review

[gggritso]

@cursor review

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Session health dashboards permanently stuck showing onboarding
  • I updated the module onboarding gate to honor requiredProjectFlags for module dashboards, so session health dashboards render widgets when selected projects have hasSessions data.

Or push these changes by commenting:

@cursor push c748ebd052

Preview (c748ebd052)

diff --git a/static/app/views/dashboards/components/prebuiltDashboardOnboardingGate.tsx b/static/app/views/dashboards/components/prebuiltDashboardOnboardingGate.tsx
--- a/static/app/views/dashboards/components/prebuiltDashboardOnboardingGate.tsx
+++ b/static/app/views/dashboards/components/prebuiltDashboardOnboardingGate.tsx
@@ -44,9 +44,22 @@
     return children;
   }
 
+  const selectedProjects = getSelectedProjectList(
+    pageFilters.selection.projects,
+    projects
+  );
+  const hasRequiredProjectFlagData =
+    onboarding.requiredProjectFlags?.some(flag =>
+      selectedProjects.some(p => p[flag] === true)
+    ) ?? false;
+
   // If the dashboard uses module-specific onboarding, check whether
   // module-specific data is available
   if (onboarding.type === 'module') {
+    if (hasRequiredProjectFlagData) {
+      return children;
+    }
+
     if (!hasAnySpanData) {
       return (
         <ModuleLayout.Full>
@@ -66,16 +79,7 @@
     return children;
   }
 
-  const selectedProjects = getSelectedProjectList(
-    pageFilters.selection.projects,
-    projects
-  );
-
-  const hasData = onboarding.requiredProjectFlags.some(flag =>
-    selectedProjects.some(p => p[flag] === true)
-  );
-
-  if (hasData) {
+  if (hasRequiredProjectFlagData) {
     return children;
   }

_{This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.}

[DominikB2014]

lgtm overall, although i think we can refactor this to be a bit simpler imo (but lmk what you think!). Regardless, a refactor isn't blocking

[DominikB2014]

I do wonder if having three types is necessary here? custom and overview are very similar, overview seems like it could just be a custom with componentId: 'overview'?

In fact i'm wondering if we need types at all here, although it would require some rejigging, it feels simpler imo if each prebuilt config just mapped to the id of their onboarding component. If we didn't care about duplication, we could even just make this a function that returns a onboarding component.

[gggritso]

They do have slightly different behaviour because depending on the type of onboarding, it has to run different checks. Plus, the different onboarding components accept different kinds of props 😬