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
Troubleshooting
Field Update
A field is being updated with a value - you don't know where it's coming from. How to track it down:
- Set history tracking on that field if you can (if you don't have 20 fields already)
- Alternatively set Feed Tracking for that field (probably turn it off after you find it).
- Does it have a default value
- If it's a picklist,is that value checked as default.
- Search for the field in the Setup Search
- https://instance.salesforce.com/ui/setup/SetupSearchResultsPage?setupSearch=Field%20Name
- Look in the Field Updates list of Workflows to see if any active workflow is updating the field.
The next ones are a bit harder.
- Is a Process Builder updating the field - good luck with finding which process is updating the field - you will have to look through each and every process.
- Is a Flow updating the field - again you will have to look through each and every Flow - but look for the Record Update and Record Create panels.
- Finally it may be a trigger. Use tricks like MavensMate and Git for Non Developers to export the Salesforce configuration to a text file so you can search through the files for the field name (search on the API name).
Changing API Names
OK, so I just needed to change an API Name - I HATE doing this because you don't know what it's going to break, BUT it's worse than having old outdated field names - HINT try to not name API Names as business processes. Eg this one was Workshop Name, and I needed to change it to a more generic name Marketing Name (the label can still say Workshop Name if that is what you want, but this client started doing more than Workshops so the word Workshop is not relevant anymore).
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.
BUT did you know that:
"Go to Workbench > Info > Metadata Types & Components > then choose 'Flow' from the dropdown > click Expand All. Then do a browser Find to search for your ID." (This was a process that updated a record that made another process action, and the ID was in the flow error message from the first process).
Also check in Paused and Waiting Flows to make sure something is not stuck in there.
Also check any other integrations you have!
This is a fabulously detailed post from Johan (@simplysfdc) on this topic http://www.simplysfdc.com/2016/09/salesforce-rename-field-name_4.html
Now to clean up this mess.