The successful pattern: pick the right type for the semantic, name per convention, write clear help text, set FLS deliberately, add validation where appropriate, document the field's purpose. The failed pattern: build the field, drop it on a layout, never revisit, accumulate confusion.
- Confirm the data semantic and pick the matching type
Date for dates, Picklist for controlled values, Lookup for relationships. The type drives every other design choice; changing later is restricted.
- Name per the org's convention
Team or domain prefix, consistent casing, no ambiguous abbreviations. If the org has no convention, propose one before building the first custom field.
- Write help text explaining what to enter
One sentence on what the field captures. Users with clear help text fill fields correctly; users guessing from the label do not.
- Set field-level security per profile and permission set
Default Read for everyone is rarely right. Tighten before saving; default broad FLS is a common compliance gap.
- Add Validation Rules where format or value matters
Email format, numeric range, picklist dependency. The validation rule is the data quality enforcement; help text is the guidance.
- Enable Field History Tracking for compliance-relevant fields
Up to 20 per object. Track Owner, Stage, Amount on Opportunity; track sensitive fields on Account. Skip tracking for fields with no audit need.
- Add to page layouts, list views, and reports as appropriate
The field exists but is invisible until surfaced. Add to the layouts that need it; resist the urge to add it everywhere.
- Document the field's purpose and owner
Spreadsheet, ticketing system, or wiki. The documentation is what saves future admins from reverse-engineering intent.
Text, Number, Picklist, Lookup, Master-Detail, Formula, Roll-Up Summary, Auto Number, and others. Drives everything.
Per the org's naming convention. The API name is hard to change cleanly later.
Per-profile Read and Edit access. Default Read for everyone; tighten before saving.
Tooltip explanation. Cheapest data quality investment available.
Per-field audit trail. Up to 20 per object.
- Field type changes after creation are limited. Text to Picklist is allowed but most others require delete-and-recreate.
- Default field-level security is Read for every profile. Tighten before saving; default broad access is a common compliance gap.
- Master-Detail relationships cascade delete and cannot be undone easily. Pick Master-Detail only when the tight coupling is genuinely required.
- Field History Tracking has a 20-fields-per-object cap. Plan which fields matter most for audit before hitting the cap.
- Custom Fields accumulate. Without quarterly cleanup, mature orgs end up with hundreds of unused fields per object.