Andy in the Cloud

From BBC Basic to Force.com and beyond…

Category Archives: DLRS


by Leave a comment

The Future of DLRS

Salesforce platform has long since had a place in my heart for the empowerment it brings to people who like to create. As a developer I love to create and feel the satisfaction in helping others. With Salesforce I can create without code as well. Now as much as I love the declarative side of building I do love to code!

In 2013 I found a way to magnify this feeling by closing the gap between coding and helping other creators, also known as Admin’s. This blog talks about a big next step in the future of the Declarative Lookup Rollup Summaries Tool or “Dolores” (short for DLRS) as the community refers to it – and how you can help.

Memory Lane…

DLRS was somewhat born out of a solution looking for a problem. Around the same time in 2013 I was playing around with the Metadata API, automating Setup aspects via Apex and building on the platform. In doing so I was discovering some of its declarative gaps. One such gap was the inability to define rollups that are not related to master detail relationships – resolving this within the platform itself required Apex and still does today. However, every now and again I tend to somehow see connections between things that are not always obvious – and maybe a little crazy – and so I wondered – what if an Admin tool generated and managed code?

I am also a frugal developer who likes to focus on the job at hand and thus look to open source when I can. After a quick internet search I found Abhinav Gupta’s open source Apex library LREngine, also known as Salesforce Lookup Rollup Summaries. This still required a developer to write an Apex Trigger, and  it also lacked a way to configure it without a developer. And so the neurons fired and “Declarative” Lookup Rollup Summaries tool was born! Over time LREngine received a number of enhancements via DLRS requirements and optimizations. The ways in which rollups could be invoked and configured was expanded around the library. The rest, as they say, is history!

DLRS Stats and a Realization…

There have been 39 releases to date, and I am proud to have had 18 GitHub contributors supporting the tool with amazing features, fixes and improvements. Along with an amazing Chatter Group on the Trailblazer Community with over 1140 members. DLRS has been installed in tens of thousands of orgs at this point. When I started the Chatter group I tried my best to answer each and every question. What I started to find is the community began to help the community, superstars like Jon LaRosa, Dan Donin and Jim Bartek and many others are so engaged and supportive its wonderful to see.

The reality though as over the past years my time and focus on the tool has not met the increasing and ongoing demand for the tool. Between holiday time coding I don’t feel it’s quite enough and the community and users of this tool deserve more. And so with mixed feelings I sent the following tweet – well actually my wife pressed the send button for me – she knows how much I love this tool and generally knows what’s best – so here we are!

DLRS needs a team, and you can help

TL:DR If you’d like to join a team of community members, helping to ensure the future of DLRS, email sfdo-opensource@salesforce.com for more information on how you can help.

It’s very important to me for it to remain open source, free to the community and get the love and attention it deserves. There are a number of duties managing it that cause me to become a bit of a bottleneck, such as packaging, and also some things that are only in my head around testing and the code base. So I originally reached out for a lead developer to help out.

I had some great responses from the Twitter post, but it was the suggestion to have the project managed as a community team as part of the Salesforce Open Source Commons Program which showed me another path. One that could ensure DLRS continues to thrive and expand well into the future. 

The OSC program provides a framework that wraps a great process and set of tools around open source projects, in partnership between community leaders and Salesforce. Learning about the OSC program made me realize that to ensure DLRS would truly be a sustainable and trusted package for it’s tens of thousands of users, more than a new lead developer would be needed. Maintaining a package like DLRS should be done by a team of volunteers, including those who can help others with support questions, those that want to help with docs, those that like to manage feature backlogs and more automated release processes – the list goes on. There are already eight open source projects involved with the program, ranging from managed packages to help Naval Volunteers (Ombudsman) with case management, to product support help videos, to DEI ecosystem improvement. The program hosts multiple training opportunities, and very popular Community Sprint events (like hackathons) throughout the year, to bring exposure and new volunteers to projects. 

Photo caption: Open Source Community Sprint participants, Philadelphia, October 2019

I have met with Cori O’Brien, Senior Manager of the Open Source Commons, who is very keen to share the benefits of the program further to the DLRS community and especially those that are keen to help in whatever way they can. If you would like to help or just learn more about the program, please drop an email to sfdo-opensource@salesforce.com and we will add you to a kick-off meeting to be held mid August.

Meanwhile – thank you all for the support you have given this tool – its been truly something I will be proud of for the rest of my life. I am very excited about this next step and rest assured I will be around to continue to contribute with the project – but most importantly so will many others!


by 40 Comments

Declarative Rollup Summary Tool Update

I typically do not blog about each new release of this tool, but since its been awhile and there is some key features in this release I thought I would add to the usual release notes.  If you are not aware this is a community driven tool that helps address a current platform limitation around rollup summaries. Specifically the inability to do rollup summaries between lookup relationships. This is possible between master detail relationships using the declarative mode of Lightning Platform, but not between Lookup Relationships. The tool is open sourced and supported by an amazing community! The following highlights some key aspects of this recent update.

Improved Lightning Experience Support

The tool does its thing in the background as users work so regardless if you configure it through Salesforce Classic or Lightning Experience, for your users it is irrelevant. This release has an actual Lightning App packaged with it and each of the custom UIs now leverage the default Visualforce Lightning styling. You can still use it in Classic, though the new Lightning Rollup Summaries Tool tab will not be visible.

welcome

Evolution of Rollup Configuration Storage

The tool has been around since 2013 and has undergone some changes, especially since the advent of Custom Metadata, which is now the primary means by which its configuration is stored. Support for the original Custom Object based storage of configuration is still present but is now more hidden by default to avoid confusing new users. This release includes more messaging in the older UI to help users tell the difference. Unfortunately some legacy implications still confused users which I also wanted to address in this new release.

warning

No More Shadow Rollup Records

Scheduled rollups can leverage an incremental calculation mode to differ calculations until a scheduled batch job executes, which improves interactive performance. The tool does this as the users update records by inserting into the Lookup Rollup Summary Schedule Items object to queue up the future recalculations. This object was architected before the Custom Metadata based rollups and thus demanded a reference to a Custom Object based rollup even if the user was using the Custom Metadata based rollups.

Previous releases of the tool attempted to workaround this silently by automatically creating so called “shadow rollup” configurations. However when users came across these, especially if they where still using Custom Object based rollups, it caused confusion. Starting with release v2.12 these will no longer be created. Though for those of you upgrading there is some actions to take on your side.

shadowrollup

Action to Take and New Lookup Rollup Summaries Tools Tab

In order to drop the confusing shadow rollup workaround described above I had to remove a field from the Lookup Rollup Summary Schedule Items object. This however is only removed from the package and will not automatically delete from orgs on package upgrade. I have ensured that your existing rollups will still work and still leverage this field, so there is no immediate action after upgrading.

However, if you create a new incrementally scheduled rollup and attempt to insert a child record you will see the error message that reminds you need to delete this field manually. You will also see a reminder to delete this field through the new tools tab.

optimizertool

As you can see above the new Optimizer component is also designed to share other useful insights into your use of the tool. In addition to the field deletion reminder I have also added a notification to remind the admin to review the Lookup Rollup Summary Log tab for errors that have occurred during incremental scheduled rollup executions. Each of the notifications comes with a more detailed Wiki page. Once everything has been cleared you get a nice confirmation telling you so!

allgood

Email Notifications for Batch Job Error Messages

The tool uses scheduled Apex jobs to run manual full, scheduled full and incremental recalculations of rollups. For incrementally recalculations expected errors get redirected to the Lookup Rollup Summary Log tab (hence the above reminder in the tools tab). However other errors in previous releases where only visible if you visited the Setup menu Apex Jobs page or had Apex Email Notifications enabled. Starting with release v2.12 such errors (unless they are governor limit errors) will be emailed to the user who scheduled the job.

No Need for Remote Site Configuration

Finally I also updated the tool to leverage a platform enhancement that relaxed the need to have a Remote Site configuration when using Salesforce API’s such as the Metadata API used by the tool when configuring rollups. This only applies to orgs with My Domain.

Customize Test Code for Parent Apex Trigger Tests

Sometimes the tool needs to generate Apex Trigger Test code for parent objects. In this release you can now customize that test code if there are required fields needed to be able to insert a test parent object.

testparent

Future Releases

There is currently 82 enhancement ideas and 22 known bugs to pick from. If you want the perspective on must have fixes and enhancements from one the amazing contributors, Dan Donin, you can see Dan’s filtered list here.

Hopefully having moved the project to SFDX you or a developer you know will feel encouraged to help out with some of these. I am also keen for ideas on how to enhance above optimizer feature to provide more proactive recommendations to admins and cut down on common questions and keep configurations optimum.

Finally there is a long standing request for UI to help configure the rollup filters that might finally be closer to reality thanks to some great work here. Meanwhile, thanks for all for the support!

image-31

 

 


by 119 Comments

Declarative Rollup Tool Summer Release!

Over the course of the last couple of weeks, i have been focusing my community time on release v2.4 of the DLRS tool. Specifically focusing on some much requested features driven by the community in the the Chatter group.

So lets get stuck in…

Rollup Scheduler Improvements

The ability to run a full (or partial with criteria) recalculate of a rollup on a daily schedule has been in the tool for a few releases now. However up until now the only option was to run it at 2am everyday. It is now possible to change this with this new UI, its a bit raw and basic, but for now it should at least give some more flexibility.

RollupSchedule.png

Support for Merging Accounts, Contacts and Leads

The platform has some special handling for merging Accounts, Contacts and Leads. Especially when it comes to when Apex Triggers are invoked. Basically if your parent object is one of these objects, prior versions of the tool had no awareness of this operation, so rollups would not recalculate. If you are using Realtime or Schedule calculation modes on your rollups. Since the platform does not fire Apex Triggers for child records reparented as a result of a merge.

With this release there are two things you can do to fix this. First when you click the Manage Child Trigger button, you get a new checkbox option to control deployment of an additional Apex Trigger on the parent object. If your upgrading you will need to click Remove then Deploy again, to see this.

ParentTrigger.png

IMPORTANT NOTE: If you don’t feel merge operations are an issue for your use cases you can deselect this option and cut down on the number of triggers deployed. Also if it is only the rollup child object that supports merging, there is no need to deploy any additional triggers and the tool does not show the above checkbox option.

Secondly you need to setup the RollupJob as an Apex Scheduled job (under Setup > Apex Classes), even if you don’t have any Schedule Mode rollups. This is due to the fact that due to a platform restriction, the tool cannot recalculate rollups realtime during a merge operation. So it can only record that they need to be recalculated. It does this via the tools scheduled mode infrastructure, by automatically adding records to the Lookup Rollup Summary Schedule Items object. Note that you don’t need to change your rollups from Realtime to Scheduled mode for this to work, only schedule the job.

Support for Archived / Deleted Records via the All Rows Setting

Salesforce archives Tasks and Events after a while. If you have rollups over these child objects you can enable the Aggregate All Rows checkbox. This will ensure your rollups remain accurate even if some records have been archived. Note this also will apply to records in the recycle bin. For upgrades (if your not using the Manage Lookup Rollup Summaries tab), you will need to add this field to your layout to see it.

AllRows.png

Row Limit for Concatenate and Last Rollup Operations

If your using the Last or Concatenate operations, you can define a limit as to how many child records are actually considered when calculating the rollup. This is useful if your using Concatenate into a fix length field for example. When upgrading you need to add the new Row Limit field to your layout if your not using the swanky new Manage Lookup Rollup Summaries tab.

RowLimit.png

Improved House Keeping for Scheduled Mode

If your are using rollups with their Calculation Mode set to Scheduled. The tool records parent rollup records to be later recalculated by the RollupJob Apex Scheduled job. In past releases if through merge or other operation the parent record was deleted before the next scheduled run. Then records would sit in limbo in the Lookup Rollup Summary Schedule Items object, being processed and erroring over and over. These will now be cleared out and there is no upgrade actions you need to take for this.

Summary

Thanks for everyones support for this tool, i hope these changes help you go further with clicks not code! Though as reminder please keep in mind the best practices and restrictions listed in the README. If you have any questions you can either post comments on this blog or use the Chatter Group. The Chatter Group is a great place to get your query seen by a broader group of people who are also diligently supporting the tool as well!

You can find releases of the tool here.