Tag Archives: Fields

Considerations When Adding A New Field



The Sales division just asked for one new field.  Before you go off to your sandbox to get started, you have some questions to ask.

1) What is the Data Type, Name, Description, & Help Text? 

  • After you know the name and purpose of this field, search the object for existing fields that may already serve the same purpose, but perhaps worded differently
  • Depending on data type and purpose, it might need to be unique, external, or encrypted


2) Is this data already available somewhere else, like the parent record?

  • If yes, why is the same data also needed on this object?   (You should mind object limits)
  • If determined a separate field is indeed needed, would a user ever need to edit it?
    • If yes, create the field
    • If no, create a formula field to display value from parent record (default read only)


3) Who Can Access It?  Who Can Edit It?

  • Don’t expect a list of profile names, you may have to figure that out on your own.
  • Confirm user list with the requestor.  What if a profile contains users who should not see/edit this field?


4) Should this field be required?

  • If so, for all records? Or just on certain page layouts?


5) Is it required for certain conditions?  

  • If yes, you’ll need a validation rule.


6) Should it have a certain format?  Or prevent certain words or characters? 

  • If yes, you’ll need a validation rule


7) Which Page Layouts should it be added to?  And where?

  • Same as profiles, don’t expect your end users to know page layout names, but they should know record types.  You can then find the page layout name by viewing Page Layout Assignments.


8) Are you going to report on this field? 

  • If so, it will need to be added to the custom report types that are in use by the requestor & team.  Otherwise expect a frustrated requestor wondering why they can’t report on their new field.

A Design Decision: Case or Custom Object?