Salesforce dashboards without deployments: a config-driven LWC pattern
Every new metric should not require a developer. This pattern uses three custom objects and one recursive Lightning Web Component so admins build rep dashboards entirely with records.
A fast-growing sales organization on Salesforce had a dashboard bottleneck. Five teams, each wanting a slightly different view of their day: queues, metrics, leaderboards. Every request became a developer ticket, a sandbox change, a deployment. The backlog was three weeks deep with requests that were, functionally, configuration.
The short answer
We replaced bespoke dashboard components with one generic, recursive Lightning Web Component pair driven entirely by data:
- A Dashboard object defines the surface.
- A Section object defines groupings.
- A Panel object defines each unit: its type (metric, table, or tab), its SOQL query, its columns, its drill-down link.
The component reads those records and renders whatever they describe. Panels can nest inside tab panels, and the component calls itself to render nested layouts, which is what makes arbitrary structures possible with exactly two components.
Adding a new metric is now: create a Panel record, paste a query, save. Live in production in two minutes, no deployment, no developer.
How queries stay safe and personal
Each panel’s query supports a small set of whitelisted bind variables, like the currently selected user’s ID. A manager opens the dashboard, picks a rep from the header selector, and every panel re-runs scoped to that rep. Queries execute with sharing rules enforced, so the dashboard can never show a user data Salesforce itself would not show them.
That bind-variable whitelist is the load-bearing wall. Free-text substitution into SOQL would be an injection hole; a fixed vocabulary of safe tokens keeps admins productive without opening one.
Why this beats standard dashboards for daily work
Standard Salesforce dashboards are summaries of reports, refreshed periodically, living on their own tab. Daily-work surfaces have different needs: live numbers, clickable rows that open the actual records, embedding directly where reps already are, and instant reconfiguration. This pattern delivers those without giving up governance, because the configuration is records, visible in setup audit trail like everything else.
What it changed operationally
The dashboard backlog went to zero and stayed there. More interesting was the second-order effect: because experiments became free, the team iterated. Queues got tuned weekly. Metrics that earned no attention were deleted instead of lingering. Configuration-as-records made the dashboards a living tool rather than a quarterly project.
Build notes
- Keep panel types few. Metric, table, tab covered ninety-five percent of requests; resisting a chart type until genuinely needed kept the component simple.
- Put a user selector in the shell and broadcast changes over a message channel; every panel subscribes and refreshes itself.
- Document the bind variables on the Panel object’s help text. The pattern lives or dies by whether admins can self-serve.
Common questions
Can Salesforce admins build custom dashboards without code?
Yes, beyond standard dashboards. With a config-driven Lightning Web Component pattern, admins define metrics, tables, and tabs as records on custom objects, and a generic component renders whatever the records describe. New dashboards require zero deployments.
How is this different from standard Salesforce dashboards?
Standard dashboards summarize reports. This pattern renders live, role-aware work queues and metrics inside record pages and app pages, with clickable drill-downs and per-user context, which standard dashboards cannot do.
Is SOQL stored in records a security risk?
Queries run with sharing enforced, accept only whitelisted bind variables (like the selected user), and are created by admins, not end users. Treated that way, it is configuration, the same trust level as a report definition.