Two Small Summer '26 Reporting Changes That Will Save Admins Time

Some release notes are small because they are unimportant.

These are small because they are practical.

Summer '26 has two reporting and dashboard changes that are easy to skim past:

brand colour palettes for reports and dashboards
up to two row-level formulas in a Salesforce report

Neither one is a platform-shaking feature.

Both will save admin time.

Quick snapshot

Brand palettes: configure a brand palette once in Themes and Branding, then apply it to report and dashboard charts.
Where: Lightning Experience in Professional, Enterprise, and Unlimited editions.
Setup path: Setup -> Themes and Branding -> create or edit a theme -> set the brand colour -> activate the theme.
Reports: select Brand in report chart properties.
Dashboards: select Brand in dashboard properties.
Row-level formulas: Salesforce reports can now include up to two row-level formulas.
Why it matters: fewer one-off chart colours, fewer unnecessary object formula fields, fewer awkward report compromises.

My short version:

Reports are getting a bit more governable and a bit less cramped.

Brand palettes solve a real governance problem

Chart colours look like a cosmetic detail until you have 200 reports and dashboards maintained by different teams.

Then you get:

sales dashboards using five shades of blue
service dashboards using random warning colours
executive dashboards rebuilt by hand every quarter
accessibility problems hidden inside "brand" choices
screenshots in slide decks that all look slightly different

Brand palettes help because the colour decision moves up a level.

Instead of manually updating colours in each report or dashboard, an admin can configure the organisation's theme and let report builders choose Brand where it makes sense.

That is the right direction.

It turns colour from a dashboard-by-dashboard preference into a governed design choice.

Example: standardise executive dashboards

Say your executive dashboards use these meanings:


Revenue	manually pick blue	use brand palette colour 1
Pipeline	manually pick green	use brand palette colour 2
Risk	manually pick red	use an accessible risk colour
Forecast	manually pick purple	use brand palette colour 3

The point is not that every chart should look identical.

The point is that the same business concept should not randomly change colour across reports.

If "At Risk" is red in one dashboard, orange in another, and purple in a third, users spend a tiny bit of energy re-learning the visual language every time.

That adds up.

The accessibility bit matters

Salesforce explicitly frames brand palettes around standardised, accessible data visualisations.

That is important because "on brand" and "accessible" are not automatically the same thing.

A brand palette for dashboards should be tested for:

contrast against the dashboard background
distinguishability for colour-blind users
meaning that does not depend on colour alone
light and dark dashboard themes
screenshots and exported/presented versions

Do not make the only difference between "good" and "bad" two shades of corporate blue.

Brand governance should make charts clearer, not just prettier.

Row-level formulas: two is a lot better than one

The other quiet win is row-level formulas.

Previously, Salesforce reports supported one row-level formula.

Summer '26 raises that to two.

That sounds tiny until you remember how many reports need exactly two derived values.

For example, an Opportunity report might need:

Time to Close
Commission Estimate

Before, you had to choose one, create an object formula field, clone the report, or give up and export to a spreadsheet.

Now the report can keep both calculations close to the question it is answering.

Example: opportunity report

Formula 1: Time to Close

CloseDate - DATEVALUE(CreatedDate)

Output type: Number.

Formula 2: Commission Estimate

Amount * 0.08

Output type: Currency.

That gives the report user both operational context and financial context:

how long did the deal take?
what estimated commission did it create?

No object formula field needed.

No spreadsheet side quest.

Use the report builder's field picker when building the formulas so you insert the exact field names for your report type.

Example: case report

Two row-level formulas also help service teams.

Formula 1: Age in Days

TODAY() - DATEVALUE(CreatedDate)

Output type: Number.

Formula 2: Needs Escalation?

IF(
  AND(
    NOT(ISPICKVAL(Status, "Closed")),
    TODAY() - DATEVALUE(CreatedDate) > 3
  ),
  "Yes",
  "No"
)

Output type: Text.

That is a much more useful report than one where the admin had to pick only the age calculation or the escalation label.

Do not overuse row-level formulas

Two row-level formulas are useful.

They are not a replacement for data modelling.

I would keep row-level formulas in the report when:

the calculation is specific to this report
the formula is exploratory
the result does not need to be reused in automation
the result does not need to be indexed, filtered elsewhere, or reported consistently across many dashboards

I would promote the logic to the object model or another shared layer when:

many reports need the same calculation
users need to filter by it everywhere
automation depends on it
the formula has business-rule ownership
the calculation is complex enough to deserve tests and documentation

The rule is simple:

If it is report context, use a row-level formula. If it is business truth, model it properly.

Why these two changes belong together

Brand palettes and two row-level formulas solve different problems, but they point in the same direction.

Reports and dashboards are becoming less hand-crafted.

The colour system moves into theme settings.

The report calculation limit gets less cramped.

That means admins spend less time working around the tool and more time answering the actual reporting question.

For a lot of teams, that is more valuable than a big flashy analytics feature.

Practical rollout

For brand palettes:

agree a small dashboard palette with whoever owns brand and accessibility
activate it through Themes and Branding
update the highest-traffic dashboards first
avoid changing colours that users already rely on for meaning without warning them

For row-level formulas:

look for reports with object formula fields created only for one report
look for reports that were cloned because one needed a different calculated column
look for spreadsheet exports where users add a second calculation manually
replace those with a second row-level formula where the logic is truly report-specific

That is where the time saving is.

Final take

These are not the loudest Summer '26 analytics changes.

They are useful because they remove friction in normal admin work.

Brand palettes make reports and dashboards easier to standardise.

Two row-level formulas make reports easier to answer without adding unnecessary fields to the data model.

Small, yes.

But exactly the kind of small that teams feel every week.