One of the biggest epidemics Salesforce orgs around the globe face is a poor data architecture. We all have been guilty of it (yes, I’ll admit I built a multi-select thinking it was a good idea). And as the amount of declarative developer tools continue to grow, so does the probability for poorly designed and implemented solutions. This comes from a number of different factors, but the two biggest are the inability to truly understand the long-term goal of the project and the tools available.
What exactly do I mean by that? Well, if you don’t understand the full picture then you possibly could end up backing yourself into a corner. You might have built out a really awesome Autolaunched Flow, but then you find out you’re solution doesn’t work because you needed it to be bulkified for your weekly data loads. Or perhaps you built a multi-select picklist to solve a problem that really should have been done with a Custom & Junction Object. Think about if your solution will be easy to maintain. If not, do you have a reason that you’re doing it that way? From the Consulting perspective, if you don’t build a good solution and the Client has problems scaling later, don’t expect them to come back to you again. If I’m the in-house Admin/Developer for a company, and I was to leave in 6 months, would my replacement turn into this guy?
Think about if your solution will be easy to maintain. If not, do you have a reason that you’re doing it that way? This is something that does not come easily to me. I have a tendency to be pretty impulsive and just want to start building things. Fortunately I have a good idea of what Salesforce’s capabilities are now, but this can be a bigger issue for someone new to the platform and new to development. The number of tools available is starting to become a bit overwhelming!
Now, lets talk about understanding your tool belt.
When Process Builder came out, it was touted as the latest and greatest thing. I’ll agree, its pretty darn powerful and I love it. However, I hate that they mentioned “you can replace your workflows with Process Builders” and “you’ll get to re-build your workflows into Process Builder since thats the future”. This currently isn’t the case in most situations, because Process Builder isn’t bulkified.
What do I mean by bulkified? In short, it means that your ‘code’ (which Process Builder/Flow technically is on the backend) can process more than one record at a time. Unfortunately Process Builder/Flow cant do this. Process Builder/Flow only fires on one record at a time, which makes it rather taxing on your limits. So, if you are doing a data load of 200+ Accounts, with Process Builder/Flow you’ll get “Too many SOQL queries: 101” as an error (depending on the Process Builder rule criteria). In short, it means that you’ve got over 100 SOQL queries firing (think of these as “Record Lookups”).
Because of this, most people should still keep their workflows or code because they work just fine! With Process Builder/Flow you’re often going to get an error for breaking governor limits. I am hopeful Salesforce will fix some of these issues, but I’m not sure how or when. Based on some of Salesforce’s comments it seems like this might not be coming as quickly as Declarative Developers would like.
Personally, I really enjoy using Flows when there is some direct user interaction. I know if I launch my Flow from a Button, then I’ll not have any issues with it being bulkified. While, I also love Autolaunched Flows, if you can’t replicate what you’re doing in Excel very easily, then you might want to look at doing it in code (so its bulkified). Typically the majority of my Autolaunched Flows are something that 2-4 data loads could replicate. This may or may not be a deal breaker, but that usually depends on the frequency of your data loads. Is this a daily task or a monthly one? If it is daily, you’d better spend some time over at SFDC99.com or at SFDC’s Trailhead and learn how to write a trigger!
RECAP: as an Admin or Developer you need to be extremely knowledgable about the tools available and the solution you’re attempting to implement to determine how you’re going to solve it. Take the extra time and build it out right, don’t take shortcuts!
Salesforce Sidekick 