DLRS: declarative rollup summaries for Salesforce

The rollup that needed a trigger

Declarative Lookup Rollup Summaries, abbreviated DLRS, is a community built and maintained Salesforce application that provides an admin-friendly declarative interface to generate and manage cross-object rollup summaries in a Salesforce org.

The problem it solves is narrow and extremely common. Salesforce lets you roll up values through master-detail relationships, but the lookup relationship, the ordinary many-to-one reference, does not carry values up by itself. To put the amount of a child record onto a parent record across a lookup, the standard answer was to write an Apex trigger, and then to maintain it, and to test it, and to worry about what happens when the data is edited from a different path.

The feature list states the difference plainly. Rollup information between lookup relationships, not previously possible without writing Apex triggers. And define rollups using standard declarative UI, no coding required.

The scope of the declarative part is worth being precise about, because it is not unlimited. The package defines filter criteria on rollups, so you can roll up something like the Closed Won Opportunity Amount onto an Account, that is, the sum of the amounts of the closed won opportunities associated with that account, rather than every opportunity. That filter is the feature that makes the result match what the business means, and it is the part a trigger would have had to encode in imperative code.

The package is MIT style permissive in the BSD 3-Clause form, its primary language is Apex, and the last push to the repository was on 2026-10-15.

Three ways to run the rollup

A rollup can be right and still be useless if it does not run when the data changes, and the second of the feature highlights addresses exactly that. Rollups can be run in Realtime, Scheduled and Developer API modes.

Realtime is the obvious mode, where the rollup is maintained as the child records change. Scheduled is the other extreme, where a job recalculates on a period, which is the right answer when the underlying data is edited in bulk or imported, because a realtime rollup over a bulk load is a lot of work for the database and a lot of automation for the platform.

The Developer API mode is the third, and it is the one that matters for a system integration. It means the rollup can be computed on request through the API rather than being maintained continuously, so an external system can ask for the current value and get it computed against live data.

Three modes for one feature sounds like a small thing, and for a package with an admin interface it is not, because the choice of mode is a per-rollup decision that the person configuring it makes in the interface, and it decides how much load the rollup puts on the org.

The package is part of the Salesforce.org Commons program, which is the open source programme for the platform, and the readme describes it as a sustainable open source community application, which is an unusual phrase in a readme and says that the maintenance model is the point as much as the feature is.

A Salesforce package with a real release channel

The distribution story is what you would expect from a package that a lot of administrators depend on, and it has two parts.

The first is the install link, which points at the Salesforce installation service for the latest DLRS release, and the second is the releases page on the repository, which lists the current and past releases. The readme separates the documentation, the installation instructions and the release notes, with the release notes pointing at a changelog page on the documentation site.

The release history in the metadata shows the shape of the project's versioning. There is a release branch for 2.25, published on 2026-03-20, and two beta builds for 2.26, Beta 1 on 2026-04-05 and Beta 2 on 2026-07-27. The names carry the channel, release for one and beta for the other, which is the convention the Salesforce tooling expects for packaging.

The gap between Beta 1 and Beta 2 is nearly four months, and the gap from 2.25 to the first beta is a few weeks, so the project is moving but slowly and in a considered way, with a stable line and a beta line in parallel.

For an administrator, the practical rule is to read the release notes for the version you are about to install rather than to take the newest one on trust, because a beta channel is exactly where the surprises live. The package is BSD 3-Clause licensed, which is a permissive licence and an unusual choice for a Salesforce managed package, so anyone extending the code has room to work with it.

The repository is an SFDX project with a test harness

The directory listing shows what the project actually is, and it is bigger than a single package.

There is a dlrs directory for the package itself, and a metadeploy directory, which is the Salesforce development model that keeps environment specific metadata separate from the package so the same code can be deployed to a scratch org or to production. There is a datasets directory for sample data, an orgs directory for the org configuration, an unpackaged directory for things that are deliberately not part of the package, and a robot directory, which is Robot Framework and therefore the integration test suite, run against a real org rather than mocked.

The project configuration is the standard Salesforce one. There is a cumulusci.yml, the community tooling that drives the build and the test pipeline, an sfdx-project.json with the project name and the source API version, an apex-ruleset.xml for the Apex linting configuration, and a docs directory alongside the images used in the documentation.

The linting configuration is split into three parts, which is the detail that shows the project uses all three of the front end stacks the platform offers. There is an .eslintignore and a .prettierignore and a .prettierrc for the formatting rules, and the package manifest points at three separate lint configurations, one for Lightning Web Components, one for Aura and one for Lightning, which is the sensible arrangement when a package contains code from all three.

The readme itself notes that its content was moved to a wiki page as of October 25, 2022, because the documentation now lives on the documentation site and the wiki page holds the old text for auditing.

Local development is eslint, jest and prettier

The package manifest is named for what it is, a local development setup, and its scripts describe the working day of a contributor.

"lint": "npm run lint:lwc && npm run lint:aura",
"test:unit": "sfdx-lwc-jest",
"test:unit:coverage": "sfdx-lwc-jest --coverage",
"postinstall": "husky install",
"precommit": "lint-staged"

The unit tests run through the Salesforce jest runner for Lightning Web Components, with watch, debug and coverage variants alongside the plain run. The lint step is split by stack as well, and the prettier configuration covers a long list of file extensions, which for a Salesforce package is the interesting part, because it includes the Apex specific ones, cls, trigger, page and cmp, alongside the front end ones, and the Apex support comes from a separate prettier plugin.

The git hooks are wired the usual modern way, with husky installing itself after the install script and lint-staged running the formatters on the files in a commit, so a contributor never has to remember to run the formatter.

The two runtime dependencies are small and revealing. cronstrue is a library for turning cron expressions into English, which is what a scheduled rollup configuration screen needs, and js-levenshtein computes edit distance, which is what a name suggestion or a fuzzy match feature needs. Both are the kind of dependency that tells you which parts of the interface are about configuration rather than about data.

A community project with sprint contributions and a group for support

The community arrangements are described in the readme, and they are the part that makes this a Salesforce Commons project rather than an open source repository with a trigger in it.

Support runs through the Trailblazer Community Group on the Salesforce success site, and the readme asks people to share their experiences there, which is the Salesforce community equivalent of a forum. Questions about configuration, about edge cases in the declarative interface and about what a rollup does when data is edited in bulk are answered by administrators who have already hit them.

Contribution happens in two ways. Developers are pointed at the documentation on how to contribute, and the readme makes a point that the project is in part contributed to during Salesforce.org Commons community sprint events. The non-code work has its own repository, the documentation and user experience improvement tracker, which is a split that many projects would benefit from, because the documentation for an administrative interface is a different job from the code behind it.

The project is BSD 3-Clause licensed and lives in the SFDO-Community organisation, and the whole package is distributed through the standard Salesforce installation path, so an administrator installs it the way they install any other managed package rather than from source.

The last push was on 2026-10-15, and the most recent published builds are the two beta releases of 2.26, so the project is being worked on and the question for a new user is which channel to take.

Editorial conclusion

DLRS fits a Salesforce administrator who has to keep a number on a parent record in step with a child record, and who does not want to write and maintain a trigger for it, because the whole point of the package is that the rollup is defined in a declarative interface and runs in the mode you need. It is the wrong choice if you need the same result on a platform that is not Salesforce, since it is a managed package for one platform, and it is the wrong choice if you want a stable release, because the recent versions are beta builds, with 2.26 published as Beta 1 and Beta 2 rather than as a final release. Before you install it, read the release notes for the version you pick, decide which of the three execution modes you need, and check the documentation site rather than the readme, because the readme content was moved to a wiki page in October 2022.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. SFDO-Community/declarative-lookup-rollup-summaries on GitHub