function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
lightlight 

hard coding LOV [List of Values] into FF/VR/WF -- really salesforce.com design Best Practice???

I am new to "force.com" coding and declarative toolset.
FF = Formula Field
VR = Validation Rules
WF = Workflow

so can someone please ase my mind as I feel I am going against the programming best practice of "you make sure your code has no hard-coded values".  So though Formula fields are PR'd as declarative.  they are strictly still 1 line of code.  (I love the tool, just not feeling comfortable with bp advocated)

about 10 years ago, when i was coding Object Orientated in another CRM.. (yes that was possible back in those days...), the work around was:
1 create a custom object to store the List of Values LOVs
2 reference that object/field in any of the business logic syntax e.g.. Formula, workflow rules, validation rules etc..

but in SF ADM201 and DEV401 material, it demonstrates to hard code the value in the formula editor.
so is this really the best practice?

---
is the a reason why we don't create a custom object to store the LOVs
e.g.. means extra overhead somewhere???

thankyou for your time
cheers

bob_buzzardbob_buzzard
Formula fields aren't code, so the best practice advice of avoiding hard coded values doesn't apply to those.  The reason you want to avoid hard coded values in code is that you can't easily change them - instead you have to go through a deployment. In that case you'd use custom settings or similar to hold the values so that you can change them as you need to.  Formula fields can be changed directly in production, so there's no great benefit to moving the information out to a custom setting unless you are using it from multiple places and it is likely to change regularly.