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.
Keep the related term in your library so you can find this topic again.