Salesforce Automations and Scale: A Cautionary Tale

Whenever you create solutions, it’s very easy to miss the long game and not consider the full future state of the system. This oversight can be costly for the team that has to come behind you for maintenance. I want to share a story about an issue a developer was having with the use of automation tools related to a single object. What should have been a fairly straightforward enhancement turned into a fairly substantial needle hunt (within a haystack), and then a significant rework of the overall solution. Now, the developer also has the tools to watch out for this type of scenario in the future. And I’m going to pass those tools on to you.
TL;DR : be very careful when it comes to utilizing multiple automation techniques on a single item, especially with respect to future scale. And know when to move on with just one as opposed to multiple.
The developer found this issue while trying to test a simple calculation on a record page that had a VisualForce component. Should have been simple, right? Developer makes his change, loads up the screen, and put-put-clank: Exception. Except there wasn’t really anything that should have thrown an exception. So, he reloads the page and put-put-clanka different exception! A lot of lather-rinse-repeat here, because the more he tried, the more issues he uncovered!
The flow was quite simple:
  • User loads list of records
  • User selects a record from a list
  • Prior to VF Page load, a custom value is calculated each time
  • Page loads and the user can see the details of the record
The underlying issues, however, were not:
  1. Intermittent Record -lock exception(s)
  2. SOQL 101 (intermittent)
  3. CPU Timeout (consistent, give neither 1 nor 2)
Load Page: kaboom.
Something was clearly not right. We started to peel back the layers of the onion, and this is what we learned:
  • The page load executed a DML statement
  • There were multiple triggers on the object.
  • Some of the trigger executions pulled in child records
  • There was a queueable class being executed from one of the triggers
  • Automation no-no-superstorm:
    • Workflow Rule (s)
    • Process Builders
    • Flow(s)
No wonder the page load went kaboom! I posted a joke on LinkedIn about moving everything to the trigger, but this is definitely a scenario where the answer was to move it all to the trigger.
I didn’t investigate far enough to know if there was any data archival or purging, or if there were any other automation associated with this object. I also did not investigate how pervasive issues like this were throughout the org; we only got so far down the well before determining that we needed to go in a different direction.
This process could not continue to exist with the amount of automation involved on the object The trigger was the way forward because of the amount of redundancy we found between the processes. Additionally, the amount of rework and the potential for significantly more technical debt for the project team was contributing factor.
I would have been more inclined to leverage the automation if not for the existing trigger code, not to mention the complexities found in some of those classes. The entire ordeal is definitely a lesson in designing for the future, as well as, phased development to clean up the technical debt.
To close:
  • Be thoughtful about your technology selection, and how you mix them…even on the platform.
  • Ask questions about expected scale/growth over time and build for the future.
  • When you encounter an issue, walk it backward
  • Load Testing in the Enterprise is critical, and we often bypass it. Don’t.


In the next post, I’ll talk in more detail about some considerations for automation vs. trigger, especially with respect to scale.

Have you ever encountered an issue that made you scratch your head? Tell me about it in the comment section? 

Chris Mattison

Hi, I'm Chris: husband, father, fitness fanatic, geek, and coffee addict with close to 20 years of IT experience. I am a Salesforce Technical Architect on the #journeyToCTA.

1 Comment

  1. […] this post, I shared a story where an implementation mixed a number of automation techniques with a trigger […]

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: