Questions on the Salesforce Answers Community have always been a great source for my blog post ideas/content. Here is another one that made me brainstorm the possible solutions and I finally ended up using Process Builder and the @InvocableMethod annotation (Apex) since that seemed to be the most convenient and elegant method to accomplish the requirement. This is the question that triggered my thought process:
Business Requirement: I am attempting to compile all states (existing picklist value where they select one state) from a series of child records, and then combining them into a single text line of states a record covers.
Solution: I was tempted to go with the Process Builder and Flow combo first but de-duplication of States would have been slightly convoluted to handle within the Flow. The Flow could call Apex but then why even get into Flows when I can invoke Apex directly from the Process Builder. I set up the needed schema in my developer org which is basically the following:
Account object (parent):
Aggregated State Info (Text Area): This field will store the concatenated state values (unique) from the Child object records.
Location Information (child to Account):
State (Picklist): This field stores US state values like CO, ID, AL, FL, CT etc.
Let’s say an Account has 5 Location Information child records with state values of: CT, NY, NJ, NY, CT , the Aggregated State Info field on related Account should show: CT, NY, NJ after the de-duplication. Such automation can come in handy if you want to get a bird’s eye view of all child records’ field values on the parent record in a certain field. Without further ado, let’s get down to implementing this. There will be two main pieces in this automation:
This class will get invoked via the Process and accept the Account Id related to the Location Information record. It will handle the heavy lifting of looping through the related Location Information records, extracting the state field values, de-duping them and updating the parent Account record’s Aggregated State Info with comma separated unique State field values extracted and de-duped earlier. This is what it looks like:
The Process is our declarative counterpart of an Apex trigger. Now why are we not using an Apex trigger instead? That is because the rule of thumb should always be: Clicks Over Code. Also, if you want to read more about the advantages of using a Process instead of an Apex trigger when dealing with similar scenarios, this is a must-read. The Process gives an admin full control over when the automation should fire and also allows for one-click activation/de-activation whenever needed. Isn’t that great?The Process will fire when the State value on the custom object record is filled out for the first time or when it’s changed. This is what it looks like:
See how simple it is to set that up? Even if you deem yourself a beginner with Apex, that Apex class shouldn’t be too tough to write. You can tweak it to meet a similar but different requirement. Let’s see the magic happen.
This is the Account record and the Location Information records before we created or updated a child Location Information record:
Now let’s change the State on one of the Location Information records and check what happens:
Note: Since Processes don’t fire retroactively, you will have to use dataloader to run a quick update on all existing records (Location Information) which will then trigger our Process and consequently update the related Accounts.
Hope it helps and if you know of another or a better way of doing this, feel free to share in the comments below.