From BBC Basic to Force.com and beyond…

Category Archives: Process Builder

Building solutions on the Lightning Platform is a highly collaborative process, due to its unique ability to allow Trailblazers in a team to operate in no code, low code and/or code environments. Lightning Flow is a Salesforce native tool for no code automation and Apex is the native programming language of the platform — the code!

A flow author is able to create no-code solutions using the Cloud Flow Designer tool that can query and manipulate records, post Chatter posts, manage approvals, and even make external callouts. Conversely using Salesforce DX, the Apex developer can, of course, do all these things and more! This blog post presents a way in which two Trailblazers (Meaning a flow author and an Apex developer) can consider options that allow them to share the work in both building and maintaining a solution.

Often a flow is considered the start of a process — typically and traditionally a UI wizard or more latterly, something that is triggered when a record is updated (via Process Builder). We also know that via invocable methods, flows and processes can call Apex. What you might not know is that the reverse is also true! Just because you have decided to build a process via Apex, you can still leverage flows within that Apex code. Such flows are known as autolaunched flows, as they have no UI.

I am proud to announce the publication of the second edition of my book Force.com Enterprise Architecture. In this blog we take a look at what the book covers for new readers and for those who have read the first edition, what’s in store for them in the second!

What is the book about?

“This book will teach you how to architect and support enduring applications for enterprise clients with Salesforce by exploring how to identify architecture needs and design solutions based on industry standard patterns. There are several ways to build solutions on Force.com, and this book will guide you through a logical path and show you the steps and considerations required to build packaged solutions from start to finish. It covers all aspects, from engineering to getting your application into the hands of your customers, and ensuring that they get the best value possible from your Force.com application. You will get acquainted with extending tools such as Lightning App Builder, Process Builder, and Flow with your own application logic. In addition to building your own application API, you will learn the techniques required to leverage the latest Lightning technologies on desktop and mobile platforms.” You can read more from the Amazon page here.

What is new in the second edition?

This second edition is 512 pages, of which over 100 pages are new, including 2 brand new chapters, covering Lightning and Testing. Plus numerous other updates to reflect the latest the platform currently has to offer, as well as thoughts on what’s upcoming. The following are some highlights:

Patterns, further worked examples of using the Application and Query factories and other features contributed by the community. The sample FormulaForce app is extended to support generic Lightning components that leverage factory principles.

Custom Metadata, is now integrated into various chapters throughout the book and the sample application FormulaForce. Showcasing various benefits relating to reducing configuration management overheads, through to managing extensibility.

Lightning Architecture and Components, builds from the ground up an appreciation of the Lightning framework fundamentals, including how SOC is applied. Builds from some simple components you can run standalone to more advanced integration approaches with Salesforce’s own app containers.

Lightning App Containers, continues to explore Lightning Experience and Salesforce1 mobile features with more complex components.

Advanced Unit Testing, the second of the two brand new chapters introduces a coded use case and contrasts the differences between integration testing and unit testing. Focusing mainly on the later, the chapter teaches the principles required to implement true unit testing, such as Dependency Injection and Mocking. The latest Apex Stub API and the FinancialForce ApexMocks framework is also covered.

I’m constantly amazed at the number of varied use cases folks in the Chatter Group are applying to the Declarative Lookup Rollup Summary tool these days. This short blog highlights a particular use case that seems to be on the increase. To resolve it i reached out for additional help in the solution from Process Builder, this is the story…

Background: What causes a Rollup to recalculate?

The default behaviour of the rollup tool is to look for changes to the field your rolling up on, the one specified in the Field to Aggregate field. In addition you can list other fields for it to look at via the Relationship Criteria Fields field, which as the name suggests is also important information if you’ve used rollup criteria. However its also important if the field your rolling up on is a Formula field. In the case of formula field rollups the platform doesn’t inform the tools Apex Trigger of changes to these. So it cannot directly monitor such fields and to resolve this must instead be told explicitly about the fields that are referenced by the formula expression. So far so good…

Challenge: Rollups over Cross Object Formulas?

A challenge however arises if you’re wanting to do a realtime rollup based on a formula field that references fields from a related record, a cross object formula! In this case how does the rollup tool know when changes are made to related records?

One solution to this is to switch to schedule mode by clicking the Schedule Calculatebutton on the rollup. For realtime rollups, its potentially feasible to enhance the tool to deploy triggers to related objects and bubble up knowledge of field changes to the cause a recalculate of the rollup on the child object… However before we resort to more code (even in the tool) lets see what we can do with the declarative tools we have already today…

Example Use Case

The following schema diagram shows a simplified mockup of a such a challenge i helped a community member out with in the tools Chatter Group.

Here is the scenario assumptions and break down…

For whatever existing reasons the above is NOT a Master Detail relationship

Rollup needed is to Sum the Quote Line Item > Amount into the Quote > Total field.

The Quote Line Item > Amount field is a Formula field, which is a cross object formula pointing to the related Widget > Total field.

The Widget > Total field is itself a Formula field, in this simplified case adding up the values of Widget > A + Widget > B + Widget > C.

Whenever changes to the Widget > A, Widget > B or Widget > C fields are made we want the Quote > Total field to be recalculated.

Here’s the rollup summary definition between Quote and Quote Line Item…

While the above works if you use Calculate (one off full recalculate) or Schedule Calculate (daily full recalculate) buttons. Our issue arises in the general use of the Realtime mode. Since the tools triggers see nothing of the changes users make to the Widget fields above, realtime changes are not reflected on the Quote > Total rollup. This is due to the aforementioned reason, since we are using a cross object formula.

NOTE: The Calculate Mode pick list also has a Schedule option, this is a more focused background recalculate, only recalculating effected records since the last run, rather than Schedule Calculate button which is a full recalculate every night. So be aware if your using this mode that the problem and solution being described here also applies to Calculate Mode when set to Schedule as well. As it uses the same field monitoring approach to queue records up for scheduled recalculation.

If your fine without realtime rollups go ahead and use the Schedule Calculate button and at 2am each morning the Quote > Total amount will catchup with any changes made to the Widget fields that effected it, job done!

Solution: Shadow Fields and Process Builder

So when considering the solution, i did consider another rollup between the Widget and Quote Line Item to start to resolve this, thinking i could then put the result in field that the Quote Line Item > Quote rollup would see change. However this was quickly proved a poor consideration as the relationship between Widget and Quote Line Item in this use case is the wrong way round, as Quote Line Item is the child in this case, doh! In other use cases, i have had success in using nested rollups to get more complex use cases to fly!

Shadow Field?

Either way i knew i had to have some kind of physical field other than a Formula field on the Quote Line Item object to notify the rollup tool of a change that would trigger a recalculate of the Quote > Total. I called this field Amount (Shadow) in this case, i also left it off my layout.

NOTE: I’ve made the assumption here that for whatever reason the existing cross object Formula field has to stay for other reasons, if thats not a problem for you, simply recreate Quote Line Item > Amount as a physical field and as you read the rest of this blog consider this your shadow field.

I then changed my rollup definition to reference the Amount Shadow field instead.

NOTE: If you managed to switch the field type of your Amount field from a Formula to a physical Number field as noted above you don’t need to do this of course.

Process Builder to update your Field to Aggregate

Next i turned to Process Builder to see if i could get it populate the above Amount (Shadow) field on Quote Line Item, as users made changes to Widget fields. Leveraging the child parent relationship between Quote Line Item and Widget. Here is the setup i used to complete the solution!

Summary

Its worth noting that if the relationship between Quote Line Item and Quote was Master Detail, you can effectively now of course use standard platform Rollup Summary Fieldswithout needing the rollup tool at all. You may think me bias here, but not at all, i’d much rather see a fully native solution any day!

Regardless if this use cases fits yours or not, hopefully this blog has given you some other useful inspiration for further rollup and Process Builder combo deals! Enjoy!

Share this:

Like this:

As soon as I got my hands on the LittleBits kit last December, i quickly fell in love with it. With its mission to bring IoT and electronics closer to everyone or in the words of LittleBits themselves …

OUR MISSION IS TO DEMOCRATIZE HARDWARE

It felt very familiar! Salesforce’s own Clicks not Code methodology is effectively the same but for Software! However i quickly found some missing capabilities. While IFTTT (default way to control LittleBits) is great, there is only support for sending a Chatter Post. But no way to have Salesforce control devices or respond to them in different ways.

Here is very cute creation from SNUGSFBAY using an early release… “this guy’s blue light shines when Salesforce targets are met!”

Dreamforce 2015

If your attending Dreamforce, I’ll be explaining more about IoT, its background, why you need to thinking about it and how you can have some fun exploring ideas with Salesforce and LittleBits, click the link below to signup to my session!

Abstract: Devices are soon to out number humans as connected things on the internet! Are you prepared for judgement day? LittleBits is the perfect hardware complement to Salesforce’s clicks-not-code approach. No knowledge of electronics or even how to solder wires together is required. It’s all plug and play, or clicks-not-solder! There are over 40 LittleBits modules allowing projects such as automatic fish feeders, burglar alarms, or anything you can imagine. Join us to see how we’ve built the LittleBits Connector for Salesforce. Learn to connect your own Internet of Things creations to your Salesforce objects, processes, and reports using clicks-not-code via LittleBits

Latest Release of the LittleBits Connector

The latest release of the LittleBits Connector v1.12 now provides full support for integrating with LitteBits devices. Meaning you can now not only tell the device to perform an action from Salesforce, but you can also have Salesforce respond to messages (or events) the device sends. Your imagination is really the only limit! Choose from one of its many input bits, such as sound, movement and other sensors. As before this is made possible without coding at all!

Here is a sneak preview of one of my slides from my Dreamforce session above…

Simply create a Salesforce Summary Report and the connector runs the report on an hourly basis and updates your chosen device! In the following example, i created a report showing Closed Won Opportunities for the period, leveraging a formula field in the report to arrive at the all important target percentage i would then pass to my device.

You can then define a LittleBits Report Trigger to tell the connector about the Salesforce Report and some details of where information can be found in the report. The Test button can be used to run the report immediately, so you can check everything is working fine. Finally use the Schedule button on the List View to schedule the job to run hourly.

Responding to Devices with Salesforce Visual Flow

Once again inspired by Cory Cowgill‘s sample here, this declarative feature allows you to connect LittleBits sensors (moving, sound, buttons etc) and any LittleBits input bit to Salesforce. Events sent to Salesforce are handled by Salesforce Visual Flow, or more specifically a Autolaunched Flows that you create. This is a very powerful #clicksnotcode tool, meaning the possibilities are practically endless in terms of what you can do in Salesforce in response to events from your latest device!

Once you have configured your org to receive device events, you can setup a LittleBits Device Subscription to start listening to specific events from your devices and routing them to your chosen Flow. You can read more about how to configure your org and these events on the wiki here.

You will have to have some experience with Visual Flow, but don’t be scared its quite easy to use and i’ll walk you through some examples to get you started in my Dreamforce session! Plus there are many many great resources in the Salesforce Community to help you.

The following Flow has only one step, Record Create, that simply echo’s the information passed from the device to a custom object as a kind of device event log. However you can of course do anything you like in Flow with its many conditional and data elements at your disposal!

Summary

I’m really very excited to see what happens next in the community with this latest release. There have already been some exciting devices from my fellow MVP’s in the community, what will you build next?!!

Like this:

As those of you following my blog will know i’ve been exploring Invocable Methods. Having submitted a session abstract to this years Salesforce1 World Tour London event and had it selected. I set about building out some more use cases to demonstrate them. This blog goes into more detail into one of two i had the pleasure of presenting alongside fellow Force.com MVP Simon Goodyear. Simon presented an awesome Twillio integration, allowing the sending of SMS messages from Process Builder! You can view the slide deck here.

In the end the use case I developed for the session attempts to fill a current Admin gap i came across on Ideas Exchange. The idea to provide Universal Picklists has been around a while and looks like its finally getting some attention given some encouraging comments by the Product Manager recently. Still please help further by up voting!

In the meantime, here is my part code and part declarative solution to the problem via Process Builder! Which also gives you a template for perhaps creating other Invocable Methods around the Apex Metadata API.

What problem do Universal Picklists solve?

As you’ll read on the Idea Exchange posting, often as Admins it can be time consuming to maintain picklist entries when they are effectively duplicated across several fields and objects in a large Salesforce organisation. Process Builder is designed to allow us to automate business processes and make our day to day lives easier on the platform, so why can it not help automate Admin processes under the Setup menu as well?

Custom VF Page vs Invocable Method?

Now i know i could have done this all via a dedicated Visualforce page and controller, which presents the user with a list of objects and Picklist fields to select. And then leverage the Apex Metadata API to update the fields accordingly, and maybe this might still be a good approach. Though as i said in my earlier blog, even if you do build fully custom UI’s, you really should give some thought to exposing Invocable Methods as well…

Anyway i wanted to see how well Metadata API would work when exposed as an Invocable Method and thus give Admins the power to build their own automated processes rather than depend completely on an Apex/VF developer now and in the future. Using Invocable Methods is an ideal way to get the best out of both the clicks and code worlds without having to sacrifice one over the other.

Introducing the Add Picklist Item Action Invocable Method

The method itself is pretty small as it delegates its work to an Apex job, this is because the context Process Builder executes your method in, is within a Trigger context. Thus due to the Apex Metadata API being a wrapper around SOAP API and callouts not being permitted in Triggers a job is used.

As per best practices i explain in the session and my previous blog, i’m using the annotations to help make the method as easy to use as possible for the Admin, ideally without to much help. The resulting UI in Process Builder looks like this (I will show the rest of the Process Builder setup in a moment).

Also per best practices, the method implementation must be bulkified. Fortunately the Metadata API itself is also designed to support bulk requests. The following code determines the Custom Fields to readMetadata, bulks the pick list items to add together and calls the Metadata APIupdateMetadata method.

Since this is happening in the background we need to think about our batch best practices here as well. How will we report errors? Currently error reporting is handled by the platform in this code sample so will appear on the Apex Jobs page under Setup, but could be routed via an email or a Chatter post perhaps.

Doing the Clicks not Code bit…

Once this method is written and deployed, its over to clicks not code to finish the work!

Here the Admin can choose how to use the method. Which actually could be via a Visual Flow UI they have built if they preferred a more wizard UI based experience. The Admin decides to create a new Custom Object who’s records will represent the Univeral Picklist values. Whenever a new record is added to this object Process Builder will respond and perform actions that invoke the above Invocable Method to add the Picklist Items to each Picklist field as desired…

The full Process Builder process created by the Admin is shown below, leveraging the Apex Action type to call the Invocable Method wrapping the Apex Metadata API defined above. Note that you can call multiple actions per event to be processed by Process Builder.

Implementation Note: Having implemented the Invocable Method as i have done, this does require multiple invocations of it per Action (resulting in a Apex job for each). Another option would have been to pass a list of Custom Fields to it, however the Process Builder UI does not yet support this use case. The alternative might be then to ask the Admin to send a comma separated list in the single Action. Though this approach does erode the ease of use and makes it harder to manage. On balance given the likely low volume of such requests i’d personally be inclined in this case to leave this one as is, but interested to see what others think on this…

Summary

I believe Invocable Methods are a great way for any developer, be they developing code in a sandbox or for a AppExchange package to provide an even greater way for their solution to not only sit on the platform, but sit within it, and extend great tools such as Process Builder and Visual Flow.

As a community, i wonder if we can start to create a library of Invocable Methods of various kinds and perhaps provide a means to package or easily deploy them to Admins. How about an Invocable Method that exposes a means to automate Layout edits? If your interested please let me know your thoughts on this! In the meantime you can see the full source code for this blog here.

Finally, the slide deck does contain a few more links and resources so be sure to check it out also!

P.S. I also had another use case to show how to develop a kind of custom formula function approach to using Invocable Methods with Process Builder, however this hit a wall with a platform issue at the time. Which I now have a workaround for, so will likely blog about this further in the future…

I love empowering as many people to experience the power of Salesforce’s hugely customisable and extensible platform as possible. In fact this platform has taught me that creating a great solution is not just about designing how we think a solution would be used, but also about empowering how others subsequently use it in conjunction with the platform, to create totally new use cases we never dream off! If your not thinking about how what your building sits “within” the platform your not fully embracing the true power of the platform.

So what is the next great platform feature and what has it go to do with writing Apex code? Well for me its actually two features, one has been around for a while, Visual Workflow, the other is new and shiny and is thus getting more attention, Lightning Process Builder. However as we will see in this blog there is a single way in which you can expose your finely crafted Apex functionality to users of both tools. Both of them have their merits and in fact can be used together for a super charged clicks not code experience!

IMPORTANT NOTE: Regardless if your developing building a solution in a Sandbox or as part of packaged AppExchange solution, you really need to understand this!

What is the difference between Visual Workflow and Lightning Process Builder?

At first sight these two tools look to achieve similar goals, letting the user turn a business process into steps to be executed one after another applying conditional logic and branching as needed.

One of the biggest challenges i see with the power these tools bring is educating users on use cases they can apply. While technically exposing Apex code to them is no different, its important to know some of the differences between how they are used when talking to people about how to best leverage them with your extensions.

UI based Processes. Here the big difference is that mainly, where Visual Workflow is concerned its about building user interfaces that allow users to progress through your steps through a wizard style UI, created by the platform for you based on the steps you’ve defined. Such UI’s can be started when the end user clicks on a tab, button or link to start the Visual Workflow (see my other blogs).

Record based Processes. In contrast Process Builder is about steps you define that happen behind the scenes when users are manipulating records such as Accounts, Opportunities an in fact any Standard or Custom object you choose. This also includes users of Salesforce1 Mobile and Salesforce API’s. As such Process Builder actually has more of an overlap with the capabilities of classic Workflow Rules.

Complexity. Process Builder is more simplistic compared to Flow, that’s not to say Flow is harder to use, its just got more features historically, for variables, branching and looping over information.

Similarities. In terms of the type steps you can perform within each there are some overlaps and some obvious differences, for example there are no UI related steps in Process Builder, yet both do have some support for steps that can be used to create or update records. They can both call out to Apex code, more on this later…

Power up with both! If you look closely at the screenshot above, you’ll see that Flows, short for Visual Workflow, can be selected as an Action Type within Process Builder! In this case your Flow cannot contain any visual steps, only logic steps, since Process Builder is not a UI tool. Such Flows are known as Autolaunched Flows (previously known as ‘Headless Flows’), you can read more here. This capability allows you to model more complex business processes in Process Builder.

You can read more details on further differences here from Salesforce.

What parts of your code should you expose?

Both tools have the ability to integrate at a record level with your existing custom objects, thus any logic you’ve placed in Apex Triggers, Validation Rules etc is also applied. So as you read this, your already extending these tools! However such logic is of course related to changes in your solutions record data. What about other logic?

Custom Buttons, Visualforce Buttons, If you’ve developed a Custom Button or Visualforce page with Apex logic behind it you may want to consider if that functionality might also benefit from being available through these tools. Allowing automation and/or alternative UI’s to be build without the need to involve a custom Visualforce or Apex development or changes to your based solution.

Share Calculations and Sub-Process Logic, You may have historically written a single peace of Apex code that orchestrates in a fixed a larger process via a series of calculations in a certain order and/or chains together other Apex sub-processes together. Consider if by exposing this code in a more granular way, would give users more flexibility in using your solution in different use cases. Normally this might require your code to respond to a new configuration you build in. For example where they wish to determine the order your Apex code is called, if parts should be omitted or even apply the logic to record changes on their own Custom Objects.

Design considerations for Invocable Methods

Now that we understand a bit more about the tools and the parts of your solution you might want to consider exposing, lets consider some common design considerations in doing so. The key to exposing Apex code to these tools is leveraging a new Spring’15 feature known as Invocable Methods. Here is an example i wrote recently…

NOTE: The use of global is only important if you plan to expose the action from an AppExchange package, if your developing a solution in a Sandbox for deployment to Production, you can use public.

As those of you following my blog may have already seen, i’ve been busy enabling my LittleBits Connector and Declarative Lookup Rollup Summary packages for these tools. In doing so, i’ve arrived at the following design considerations when thinking about exposing code via Invocable Methods.

Design for admins not developers. Methods appear as ‘actions’ or ‘elements’ in the tools. Work with a few admins/consultants you know to sense check what your exposing make sense to them, a method name or purpose from a developers perspective might not make as much sense to an admin.

Don’t go crazy with the annotations! Salesforce has made it really easily to expose an Apex method via simple Apex annotations such as @InvocableMethod and @InvocableVariable. Just because its that easy doesn’t mean you don’t have to think carefully about where you apply them. I view Invocable Methods as part of your solutions API, and treat them as such, in terms of separation of concerns and best practices. So i would not apply them to methods on controller classes or even service classes, instead i would apply them to dedicate class that delegates to my service or business layer classes.

Apex class, parameter and member names matter. As with my thoughts on API best practices, establish a naming convention and use of common terms when naming these. Salesforce provides a REST API for describing and invoking Invocable Methods over HTTP, the names you use define that API. Currently both tools show the Apex class name and not the label, so i would derive some kind of way to group like actions together, i’ve chosen to follow the pattern [Feature]Action[ActionName], e.g. LittleBitsActonSendToDevice, so all actions for a given feature in your application at least group together.

Use the ‘label’ and ‘description’ annotation attributes. Both the @InvocableMethod and @InvocableVariable annotations support these, the tools will show your label instead of your Apex variable name in the UI. The Process Builder tool currently as far as i can see does not presently use the parameter description sadly (though Visual Workflow does) and neither tool the method description. Though i would recommend you define both in case in future releases that start to use it.

NOTE: As this text is end user facing, you may want to run it past a technical author or others to look for typos, spelling etc. Currently, there does not appear to be a way to translate these via Translation Workbench.

Use the ‘required’ attribute. When a user adds your Invocable Method to a Process or Flow, it automatically adds prompts in the UI for parameters marked as required.

Bulkification matters, really it does! Play close attention to the restrictions around your method signature when applying these annotations, as described in Invocable Method Considerations and Invocable Variables Considerations. One of the restrictions that made me smile was the insistence on the compiler requiring parameters be list based! If you recall this is also one of my design guidelines for the Apex Enterprise Patterns Service layer. Basically because it forces the developer to think about the bulk nature of the platform. Salesforce have thankfully enforced this, to ensure that when either of these tools call your method with multiple parameters in bulk record scenarios your strongly reminded to ensure your code behaves itself! Of course if your delegating to your Service layer, as i am doing in the examples above, this should be a fairly painless affair to marshall the parameters across.

NOTE: While you should of course write your Apex tests to pass bulk test data and thus test your bulkification code. You can also cause Process Builder and Visual Workflow to call your method with multiple parameters by either using List View bulk edits, Salesforce API or Anonymous Apex to perform a bulk DML operation on the applicable object.

Separation of Concerns and Apex Enterprise Patterns. As you can see in the examples above, i’m treating Invocable Actions as just another caller of the Service layer (described as part of the Apex Enterprise Patterns series). With its own concerns and requirements.

For example the design of the Service method signatures is limited only by the native Apex language itself, so can be quite expressive. Where as Invocable Actions have a much more restricted capability in terms of how they define themselves, we want to keep these two concerns separate.

You’ll also see in my LittleBits action example above, i’m delegating to the Service layer only after wrapping it in an Async context, since Process Builder calls the Invocable Method in the Trigger context. Remember the Service layer is ‘caller agnostic’, thus its not its responsibility to implement Aysnc on the callers behalf.

I have also taken to encapsulating the parameters and marshalling of these into the Service types as needed, thus allowing the Service layer and Invocable Method to evolve independently if needed.

Finally as with any caller of the Service layer i would expect only one invocation and to create a compound Service (see Service best practices) if more was needed, as apposed to calling multiple Services from the one Invocable Method.

Do I need to expose a custom Apex or REST API as well? So you might be wondering that since we now have a way to call Apex code declaratively and in fact via the Standard Salesforce REST API (see Carolina’s exploits here). Would you ever still consider exposing a formal Apex or REST API (as described here)? Well here are some of my current thoughts on this, things are still evolving so i stress these are still my current thoughts…

If your data structures of your API are such that they don’t fall within those defined by Invocable Methods (such as Apex types referencing other Apex types, use of Maps, Enums etc..) then you’ll have to expose the Service anyway as an Apex API.

If your parameters and data structures are no more complex then those required for an Invocable Method, and thus would be identical to those of the Apex Service you might consider using the same class. However keep in mind you can only have one Invocable Method per class, and Apex Services typically have many methods related to the feature or service itself. Also while the data structure may match today, new functional requirements may stress this in the future, causing you to reinstate a Service layer, or worse, bend the parameters of your Invocable Methods.

In short my current recommendation is to continue to create a full expressive Service driven API for your solutions and treat Invocable Methods as another API variant.

Hopefully this has given you some useful things to think about when planning your own use of Invocable Methods in the future. As this is a very new area of the platform, i’m sure the above will evolve further over time as well.

Like this:

This tool has had a steady number of releases last year, containing a few bug fixes and tweaks. This Spring’15 release contains a few enhancements i’d like to talk about in more detail in this blog. So lets get started with the list…

Support for Count Distinct rollups

Support for Picklist / Text based rollups via Concatenate and Concatenate Distinct operations

Support for Rolling up First or Last child records ordered by fields on the child such as Created by Date

Support for Lightning Process Builder

UPGRADE NOTE: The Lookup Rollup Summaries object has some new fields and pick list values to support the above features. If you are upgrading you will need to add these fields and pick list values manually. I have listed these in the README.

The following sections go into more details on each of the features highlighted above.

Support for Count Distinct rollups

If you want to exclude duplicate values from the Field to Aggregate on the child object select the Count Distinct option. For example if your counting Car__c child records by Colour__c and it has 4 records, Red, Green, Blue, Red, the count would result in 3 being stored in the Aggregate Result Field. You can read more about the original idea here.

Support for Picklist / Text based rollups

The rollup operations Sum, Min, Max, Avg,Count and CountDistinct operations are still restricted to rolling up number and date/time fields as per the previous releases of the tool.

However this version of the tool now supports new operations Concatenate and Concatenate Distinct that support text based fields. Allowing you to effectively concatenate field values on children into a multi-picklist or text field on the parent object record.

By default children are concatenated based on ascending order of the values in the Field to Aggregate field. However you can also use the Field to Order By field to specify an alternative child field to order by. You can define a delimiter via the Concatenate Delimiter field. You can also enter BR() in this field to add new lines between the values or a semi-colon ; character to support multi-picklist fields. You can read more about the original idea here.

Support for Rolling up First or Last child records

By using the new First and Last operations you can choose to store the first or last record of the associated child records in the parent field. As with the concatenate feature above, the Field to Aggregate is used to order the child records in ascending order. However the Field to Order By field can also be used to order by an alternative field. Original idea here.

Support for Lightning Process Builder

To date the tool requires a small Apex Trigger to be deployed via the Manage Child Trigger button. With added support for Lightning Process Builder actions. This allows rollup calculations to be performed when creating or updating child object records. Sadly for the moment Process Builder does not support record deletion, so if your rollups require calculation on create, update and delete, please stick to the traditional approach.

To use the feature ensure you have selected Process Builder from the Calculation Mode field and specified a unique name for the rollup definition in the Lookup Rollup Summary Unique Name.

Once this is configured your ready to add an Action in the Process Builder to execute the rollup. The following Process shows an example configuration.

As you’ve seen from some of my more recent blogs, i’m getting quite excited about Process Builder. However i have to say on further inspection, its got a few limits that really stop it for now being really super powerful! Having support for handling deletion of records and also some details in terms of how optimal it invokes the actions prevent me from recommending this feature in production. Please give me your thoughts on how else you think it could be used.