Menu
One of the first things you learn to do when configuring a Salesforce instance, is create new Custom Fields and new Custom Objects. Setting up your data structure is the cornerstone of tailoring that off-the-shelf software feeling into a comfy suit that snugly fits your business needs. Custom fields lend us an awful lot of power and functionality by themselves, with Formula fields, Rollup Summaries and Parent/Child relationship. But as always, it’s important to know when to wield this power and when to perhaps use alternative tools.
Simon: One of the most popular posts I’ve made on the Salesforce Stack Exchange was back at the start of my Salesforce career where I asked about “Refreshing Formula Fields Dynamically (without save)”. It’s had nearly 10,000 views and the concept was indeed so popular, Salesforce have actually fixed the issue I was asking about! But what had happened?
I wrote an incredibly involved price calculation system which populated hundreds of fields on a Custom Object. There were dozens of Formula fields doing amazing maths between many of these fields. Part way into the project though it turned out I needed to put these values on the page, and have them respond to changes on the page. This was not easily possible with Formula fields, as they are only calculated on their load from the database layer (as of Summer ‘15).
It turns out Formula fields are not a good idea for transient values in calculations or user flows. Even with the post-Winter’16 fix, they are not dynamic or particularly dependable values. I personally think of Formula fields as a good tool for making presentation features for page layouts and user interfaces. For example combining text fields, formatting numbers, displaying iconography, doing cool stuff with links and percentages. I’d try generally to avoid using them for business critical mathematics and instead put that stuff in testable Apex triggers.
Jenny: Want a real *face to palm* kind of moment? Well how about when you log into an org to get your admin thang on and then realise that there are custom contacts and report objects. You may laugh, but it’s actually quite popular to see such sights. The reason? Well I hate to say it but it generally comes down to inexperienced Admins and Consultants.
I recently came across a scenario where there was a Location object which was pretty much identical to the Accounts objects. Locations looked up to Accounts. The relationship? Accounts where the parent of Locations and Contacts existed on both Account and Location Objects The result? Messy data, money spent on Consultants to fix the problem and an Admin with a bruised ego. Our Solution? You know what I am thinking – Account Hierarchy! Simple and standard functionality.
My tip. Know what exists in the org before you get click happy. It is going to save you bags of time and money in the future.
Simon: Another interesting interaction between developers and Custom Objects/Fields is when we think about data in the scope of our code.
I have seen a massive increase in the prevalence of Apex Inner Classes to represent data structures, much more like old school OOP. I think we use this a lot behind Lightning Components as custom return types for @auraEnabled methods. It’s also a really good idea to consider whether you can use them to augment Standard and Custom Objects in your code. This is without having to create loads of fields when you are doing complex code processing.
Consider for example if you needed to “hold” a couple of values against Account objects during a transaction in which the List of Accounts was bounced around a number of (code) flows. You might consider using a Map to marry each Account to it’s values. But you might then end up with a lot of Maps. Alternatively you might consider just adding fields to the Account object so you can just reference Account.Transient_Value__c in all your code. Even though at the end of the day it doesn’t need to live in the Database (what is 3 extra fields on an object?!!). Or you could do this instead:
And then just work with lists of this more complex data structure whilst you need those values. But save yourself confusing Custom Fields when you don’t need them.
Jenny: Let’s move on to custom fields. More specifically, Address Fields. Standard addresses built into standard objects in Salesforce are accessible in the SOAP and REST APIs as a structured “compound” data type, as well as individual address elements. This is a big help for our beloved Devs as they can reference addresses directly.
However, if custom address fields are added to objects you lose this ability. Therefore Devs have to reference each individual component field. Not the end of the world, but the most user friendly either!
Having said that there are some obvious needs for additional custom address fields on objects e.g. invoice address, Opportunity site addresses etc. And while the only option at the moment is to create individual text fields for each component field, it looks like a standard address field is on the horizon. Check out this 10 year old idea for more information.
Admin vs Dev challenge 5: Zombie Dice!
This week we determine who has more brains by playing a swift game of Zombie Dice. 
It was a close one, kinda 😉
See you next week.
Jenny and Simon.
Our independent tech team has been servicing enterprise clients for over 15 years from our HQ in Bristol, UK. Let’s see how we can work together and get the most out of your Salesforce implementation.
