Salesforce Lazy Clicks / Codes and Spooky Sudoku – Admin vs Dev Challenge 4

You hear the door slam and realise there is nowhere left to run. You close your eyes and hope that this is just imagination. The terror of seeing lazy hacks and bad config is gonna thrill you tonight. But then it becomes apparent that you’re not stuck in a Thriller scene and all the lazy clicks and codes can be prohibited / rectified. Phew!

Now that you have an ear worm to see you through this blog post, let us continue.

Salesforce, when configured using best practice, can be an absolute dream to use for Admins, Devs and Users alike. However, I’m sure we can all hold our hands up to doing lazy clicks and code at some point. The result? Hair pulling Michael Jackson Salesforce Thriller hallucinations! AKA, hours trying to decode fields, profile permissions and code!

So stick around to see how you can stop your Salesforce build from becoming a horror story for all users.

Jenny: Consultants, Admins and Users, this one is for you. Now we all like a bit of a mystery. You know like which colour M&M you are going to pick from the bag, whether Leonardo DiCaprio is still in a dream within a dream or where Will disappeared to in Stranger Things. But when it comes to trying to understand what fields do in Salesforce, it is less gripping for the imagination. So Admins help your future self, Users and Consultants out by entering a Field Description on creation. You could even go one step further and add Help Text. It’s a great alternative to head scratching.

Simon: One act of laziness that really grinds my gears is people who just “leave all the ticks defaulted” as they are creating fields, apps, tabs and the like. You are often so focused on the process of getting through their creation – you can convince yourself that you will “come back and do permissions later”. But how often do all those checkboxes just remain ticked – leaving irrelevant fields scattered across page layouts, or opening access to information in the data layer people shouldn’t have.

Once this actually broke a Change Set of mine – as my Change Set contained a custom “App” – with my 3 specific tabs in, and then another user came along, created a Visualforce Tab – left the visibility to “Default On” – in all apps and wandered off… so when I promoted my Change Set, my App tried to deploy including this tab (which didn’t exist and wasn’t in my

Change Set) and so it failed, meaning I had to go back, remove this new tab from my app and Clone/Upload/Deploy again. Thanks Lazy Larry you just cost me an hour – and now your tab is on everyone’s tab bar in every app.  

Jenny: So what counts as too many fields on one page layout? 30, 50, 60? Well how about 420! *Screams heard across the Community*. Yes this is way too much obviously, but terrifyingly it has been witnessed.

A simple way to rectify this is to 1) Streamline your process. This means chopping down those data fields, adding approval processes, validations and even workflow automation. 2) Introduce sections to your page layout. Those fields splurged all over your layout aren’t going to make much sense. Sections enable you to group related fields for an easier user experience e.g. User Information, Address, etc. 3) Define different page layouts and record types and then 4) assign those to the correct profiles. This will ensure that users are only seeing information that they need to see.

The result? Better user adoption and reporting! This is also a great alternative to scrolling finger ache.

Simon: I appreciate that lazing around can be a nice thing to do, trust me, I did a Computer Science degree. But as nice as it is to take the odd shortcut, in your code is not one of them. Here are some things that will make me snap your fingers off if I find them in your code:

No-one knows what that does.

In a code review, I would probably just delete these three definitions and send your work back telling you it doesn’t even compile.

A very common naming pattern, but to people outside your own head it’s a bit like sending your friend to the shop to “get you four, please”.

But finally, probably the most common problem with lazy coders, is utterly useless test code.. I’ll send £5 to whoever can correctly guess what functionality this test was testing, and what change in conditions might cause it to fail:

This week we go through the mind boggling task of trying to complete a Sudoku in the fastest time. Who will turn out to be Frankenstein and the other the monster…..

The winning time was 16 minutes and 29 seconds. Who do you think won this week?

See you next week.