Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Checkboxes

Checkboxes, like Multi-select picklists, should be used with care, and used very sparingly. 

Issues:

  • There is no NO value, only yes. Well there is a no, but how do you know it's No or just blank - use a Yes / No picklist instead - define a global picklist with Yes/No values. 
  • You can't tell when something happened. Yes, the document was received, but when was it received? Unless you put field history tracking on that field, you just don't know. Use a date field instead. 
    • You do not want to be wasting your twenty precious field history tracking fields on checkbox fields - that is no value at all. 
    • Or you could use Chatter Field Tracking but people always get annoyed with that as there is no way to filter out automated posts from the feed. 
    • Go vote for this idea https://success.salesforce.com/ideaView?id=08730000000azcgAAA no, it's not an idea to allow automated posts to be filtered from the feed, but that idea was merged into this one - yeah, I don't know why either, they are two different things. 
  • They are annoying to set with workflows - you have to do one workflow for yes, and one workflow for no. 
    • At least Process Builder is better, you can do a formula to update Boolean values.
  • If they are used for a milestone that something has been done - nope, use a status picklist instead.
  • It's hard to change your business logic - what if the thing that you have set as a checkbox needs to have a "maybe" option or a "pending" option what do you do then? 

When it's OK to use a checkbox:

  • When they are set by an automated process and hidden from users:  
    • Helpful when trying to overcome the 5000 character compile limit on formulas - set the checkbox in a process builder based on a long formula and then use the checkbox value in another formula. 
  • When they are used to avoid using Multi Select Picklists where you need to do frequency reporting. 
    • But I would still use the multi select picklist and automate checking and unchecking the checkboxes.
  • When they are a formula:
    • Checkboxes are great for formulas. 
    • I create many Boolean formulas to return true or false depending on if other fields are filled in the way they need to be. Eg instead of a milestone checkbox, create it as a formula IF(MyField__c = "ABC" && MyField2__c = 123) returns true. 
    • I create these formulas for most business logic and name them something like isActive__c, isLive__c, isCustomer__c, then my reports are really easy to build - isActive__c and isCustomer__c in a report criteria, then if the definition of what a customer is changes, I only need to change it in the formula rather than on ALL the reports. I call these "helper formulas" but beware, you can often come unstuck with the 5000 character compiled limit on formulas. 

So, what to do instead...

Use a Date:

  • Wherever you want to do a checkbox, try using a date instead. 
  • Don't name the date field Materials Sent Date, you know it's a date, so just name it Materials Sent. 
  • Then if you really want it as a checkbox for some other reason, do a formula of NOT(ISBLANK(MaterialsSent__c)) Or MaterialsSent__c <= Today()

Or use a picklist:

  • Is Yes / No really adequate values for a picklist? 
  • Maybe use Received, Validated, Submitted or Sent or similar verbage. 
  • Using picklists helps for when the business process changes. First it was Yes and No only, now they want Yes, Maybe, Possible and No. Easy just to add some picklist values.

See Also

...

So, we KNOW that field names are not changed on any integrations. I have Drawloop - (formerly Nintex Document Generation) installed for this client. So I stuck all the drawloop files in one folder on my PC and searched in that folder for the old field API Name - easy. 

...