What makes a Roll-Up Summary?
For what feels like ages we have always assumed we have to have a Master-Detail relationship in order to calculate a Roll-Up Summary. Of course we could always go to code, we all have time for that right?
Welcome back trailblazers, today we’re going full declarative with Lightning Flow Builder to skip the Master-Detail Relationship and building a quick Roll-Up Summary field.
You may be wondering why on earth I’m suddenly starting to care about making a Roll-Up Summary without the relationship. Well recently I was working with some declarative objects (Case and Contacts) and wanted to quickly find how many open cases each Contact so I could sort the Contacts most affected. Going over to my trusty report builder. Had to make a custom report type of Contacts with/without cases. From here we should be able to count how many open Cases a Contact has.
Well, yes, but at the same time, no. Using Salesforce reports I’m able to build a report that shows me how many cases my contact has, but what about taking action on that data? I’ll filter the report to show me contacts with more than 3 cases, wait I can’t use the count to filters. Fine, I’ll sort from most to least. That’s a no go. Really it was quite annoying.
Now that we know the why let’s get started. First things first, if I am going to store the number of open cases on the contact record I will need a number field. I’m going to call it Open Cases (Open_Cases__c). It’s a number field with no decimals and a default value of 0.
Once I have a field to store the count in I’m ready to head over to Flows and build the logic to update my roll-up. I don’t want anyone to have to do anything to update the counts so I’m going to create a new auto-launched flow.
An Input Variable
As we want to automatically update the count of cases from a contact we will need to be able to tell the flow which contact we are referencing. We do this by creating a Text Variable that can have Inputs pushed to it. I can select to add a new resource by selecting the Manager tab and selecting New Resource.
Find Our Open Cases
For our node we can use the Get Records element from the Elements tab. We are looking for cases that meet the following criteria:
1. Case Is Close = False
2. Contact = Our Contact Variable
We will store all records that mee this criteria. As a matter of choice you can choose to automatically store all fields (my preference as I’m super lazy) or you can get specific and limit either the number of fields you retrieve or choose the fields and define your own variables.
Now that we have gathered our cases, we want to check how many cases were located. You may have guessed it but we need a place to store this number, so we are off to make another variable. In this case a number variable (varCountCases). Next up we are going to set the variable we just made equal to the count of records located from the Get Records element we just used. For the operator to Equals Count, not equals. In the value drop down you now see the Get Records collection. This is because we are storing multiple records (aka using a collection).
Let Update That Contact
Now that we know the contact record and how many cases we have it’s time for the final element, an Update Record. For this Update Record we can select Specify conditions to identify records, and set fields individually. This will allow me to tell the flow which record I want to update and just set the field. I will select the Contact object and specify to update the Contact that matches the varContactIDTxt (the variable I pass at the very beginning). Then I am going to set the field I created (Open_Cases__c) to match the count variable I made (varCountCases).
The Final Piece of the Flow
Now that we have made all of our elements, it is time to connect them. (If you’re like me you couldn’t help it, you were too excited for our roll-up so you connected them as you went along). Time to Save and Activate our Flow.
The Process Builder
We made our flow and we’re done right? Well if you read the title of this section, you probably realize there is more to it than that. The flow doesn’t know when to run and which contact records to update. So we’re going to make a process builder to do so. As an advance consideration, we want to limit the number of times the flow is kicked off from the case.
The Process Builder should run when the case is created or edited. For the criteria we want the Process Builder to always check there is a contact ID listed so we can update our roll-up. It then check whether the case is new, the contact has been changed(added), or the case has been closed. Finally for the action we are going to call the Flow and select the flow we created. You’ll not there is an option to set the flow variable, this is because we defined the text variable as open for input.
The Old Contact
In our first criteria we checked that the contact id was populated, but what if the change was removing the Contact from the Case? In this case we create a new criteria that checks if the contact id is currently null and wasn’t previously. If it wasn’t we pass the old contact id (priorvalue) to the flow to update the previous record.
Our Roll-Up In All It’s Glory
Tired yet? I am, but victory is ours. Check out the screen shots below.
Hope everyone enjoyed it. In case you didn’t follow along and just wanted a shortcut, here’s the unmanaged package ready to go:
You will have to add the field to any page layouts you want, hey, you’re in this too right?
What do you think trailblazers? What do you want to see next?