Normal Salesforce Dashboards Are Getting Custom LWC Widgets

This one is easy to underestimate.

Custom Lightning Web Components are coming to normal Salesforce Lightning dashboards.

Not just CRM Analytics dashboards.

The normal Dashboards tab.

The place where admins build chart, metric, table, text, and image widgets from source reports.

Summer '26 says you can add a custom LWC directly from dashboard edit mode by clicking +Widget and selecting Lightning Web Component.

That is a small UI change with a fairly big product-design implication.

Dashboards are no longer only a wall of report-derived widgets. They can now have one carefully chosen custom surface.

Quick snapshot

What: add a custom LWC directly into a Lightning dashboard.
Where: Lightning Experience dashboards, not Salesforce Classic.
How: in dashboard edit mode, click +Widget, select Lightning Web Component, configure the component, and add it.
Example use case from Salesforce: a waterfall chart or another visualisation not available in standard dashboard widgets.
Permissions: users need report/dashboard permissions to add the widget.
Data access: Salesforce says LWC data is shown based on the logged-in user's permissions.
Current help-page limit: Salesforce's help page says you can add only one custom LWC to a dashboard.
Status wording: the Summer '26 release note says generally available, while the linked help page still appears to carry beta wording in places. I would check your org and current docs before promising this in a rollout plan.

My short version:

Normal dashboards are getting a custom component slot. Use it like a scalpel, not a landfill.

Why this matters

Standard dashboard widgets are intentionally constrained.

That is usually good.

They are report-backed, admin-friendly, permission-aware, and predictable. You get charts, metrics, tables, gauges, text, and images. The dashboard stays understandable because the widget vocabulary is limited.

But there are always gaps.

You want:

a waterfall chart
a contribution bridge
a custom funnel with non-standard stages
a small risk panel that combines several checks
a guided "what changed?" explainer
a live integration health indicator
a one-click action to open the right workspace
a compact component that uses Apex, GraphQL, or external data

Before this, normal Lightning dashboards were not a natural home for that.

You either compromised with a standard widget, built a Lightning app page instead, moved to CRM Analytics, or sent users somewhere else.

This change gives you a middle option.

Keep the dashboard.

Add one custom surface where the standard widgets run out of road.

This is different from CRM Analytics dashboards

That distinction matters.

Salesforce has supported custom LWC-style extensions in CRM Analytics contexts for a while. That is not the same audience or workflow as the normal Dashboards tab used by everyday reports-and-dashboards teams.

The interesting shift here is that the ordinary dashboard builder is getting a custom LWC widget path.

That means this could be useful for teams who live in standard reports and dashboards and do not want to turn every advanced visual into a CRM Analytics project.

It also means governance matters more.

The average dashboard builder is not expecting arbitrary application logic inside a dashboard.

Example 1: a waterfall widget

Salesforce's example is a waterfall chart, and that is a good one.

Standard dashboards can get you a lot of chart types, but not every business visual fits the standard menu.

Imagine a revenue bridge:

Starting pipeline
+ New pipeline
+ Expansion
- Slipped deals
- Lost deals
= Ending pipeline

That is much easier to understand as a bridge than as a pile of separate dashboard metrics.

The Apex should still be boring and permission-aware.

public with sharing class DashboardRevenueBridgeController {
    public class BridgeStep {
        @AuraEnabled public String label;
        @AuraEnabled public Decimal amount;
        @AuraEnabled public String kind;

        public BridgeStep(String label, Decimal amount, String kind) {
            this.label = label;
            this.amount = amount;
            this.kind = kind;
        }
    }

    @AuraEnabled(cacheable=true)
    public static List<BridgeStep> loadBridge() {
        Decimal newPipeline = 0;
        Decimal closedWon = 0;
        Decimal closedLost = 0;

        for (AggregateResult row : [
            SELECT StageName stageName, SUM(Amount) total
            FROM Opportunity
            WHERE CloseDate = THIS_QUARTER
            WITH USER_MODE
            GROUP BY StageName
        ]) {
            String stageName = (String) row.get('stageName');
            Decimal total = (Decimal) row.get('total');

            if (stageName == 'Closed Won') {
                closedWon = total;
            } else if (stageName == 'Closed Lost') {
                closedLost = total;
            } else {
                newPipeline += total;
            }
        }

        return new List<BridgeStep>{
            new BridgeStep('Open pipeline', newPipeline, 'start'),
            new BridgeStep('Closed won', closedWon, 'positive'),
            new BridgeStep('Closed lost', -closedLost, 'negative'),
            new BridgeStep('Net movement', newPipeline + closedWon - closedLost, 'total')
        };
    }
}

The key choices:

with sharing keeps record visibility aligned with sharing rules.
WITH USER_MODE keeps object, field, and record access in the query path.
The LWC receives summary data, not a giant unfiltered record dump.

The dashboard widget should not be a backdoor around report security.

Example 2: dashboard-safe LWC shape

For the LWC, I would keep the public API small.

import { LightningElement, api, wire } from 'lwc';
import loadBridge from '@salesforce/apex/DashboardRevenueBridgeController.loadBridge';

export default class RevenueBridgeWidget extends LightningElement {
  @api title = 'Revenue Bridge';
  @api showActions = false;

  @wire(loadBridge)
  bridge;

  get steps() {
    return this.bridge.data ?? [];
  }

  get hasData() {
    return this.steps.length > 0;
  }
}

<template>
  <section class="bridge-widget" aria-label={title}>
    <h2>{title}</h2>

    <template lwc:if={hasData}>
      <template for:each={steps} for:item="step">
        <div key={step.label} class="bridge-row">
          <span>{step.label}</span>
          <lightning-formatted-number
            value={step.amount}
            format-style="currency"
            currency-code="USD">
          </lightning-formatted-number>
        </div>
      </template>
    </template>

    <template lwc:else>
      <p>No bridge data available.</p>
    </template>
  </section>
</template>

This is deliberately modest.

The component can be configured in the dashboard, but it does not try to become the whole dashboard.

That is the design discipline I would want here.

The permission nuance is important

Salesforce's help page says the LWC data is shown based on the logged-in user's permissions.

That is worth spelling out because dashboard data can already have its own viewing model. Standard dashboard widgets are based on source reports and dashboard settings. A custom LWC is application code.

So ask:

Does the Apex use with sharing?
Do queries use WITH USER_MODE where user-facing data is returned?
Are fields checked by the query path rather than manually assumed?
Does the component show less data for users with less access?
Does the dashboard still make sense when the LWC returns no rows?

The worst version of this feature is a dashboard where the standard widgets obey one access model and the LWC quietly obeys another.

Do not do that.

The one-LWC limit changes the design

The linked help page says you can add only one custom LWC to a dashboard.

That might sound restrictive, but I think it is healthy.

It stops the dashboard becoming a disguised Lightning app page.

If you only get one custom component, it should be the component that adds the most value beyond standard dashboard widgets:

a visual Salesforce does not provide
a cross-object or external-data summary
a guided interpretation panel
a small workflow launcher
a high-signal exception list
a dashboard companion that explains what changed

It should not be five mini-apps crammed into a reporting page.

Good uses

I would be excited about:

waterfall charts
cohort visuals
data-quality health panels
forecast movement explainers
territory coverage maps
renewal risk widgets
external system status panels
compact action launchers
dashboard commentary generated from governed data

Those are all cases where the dashboard remains the dashboard, but the LWC adds a custom lens.

Bad uses

I would be wary of:

recreating standard chart types in code for no reason
building full CRUD screens inside a dashboard
bypassing source-report governance
loading thousands of records into the browser
making the dashboard depend on slow callouts
hiding important business rules in JavaScript
creating a component only one dashboard can ever understand

If the LWC needs a navigation menu, tabs, modals, background polling, and a full state model, you may not want a dashboard widget.

You may want an app page.

Practical rule

The LWC should answer one of these questions:

What can this dashboard not visualise with standard widgets?
What context does the dashboard need next to the report data?
What small action belongs exactly here?

If it cannot answer one of those, leave the dashboard alone.

Standard widgets are still better for standard reporting.

Final take

I like this change a lot.

It suggests Salesforce is letting normal dashboards become a little more composable without forcing teams into a completely different analytics product for every custom visual.

That is useful.

But the constraint is the feature.

One strong custom LWC can make a dashboard much more useful.

Ten custom LWCs would just turn the dashboard into a confused app page.

Use the custom widget for the thing standard dashboards cannot do, keep the data access user-safe, and let the rest of the dashboard stay boring.