Length is a one-line decision that has long-term consequences. Spend the few minutes to size it right at field-creation time.
- Identify the data source
Where does this field''s data come from? Customer input? External system? Computed value? Each source has typical lengths to design for.
- Pick a generous initial length
Increasing later is free; decreasing is painful. Default to a length comfortably above the expected maximum.
- Cross-check against standard field limits
If the field maps to a standard field downstream, match or undercut its length. Don''t make a custom Name longer than Account.Name (255).
- Choose Text vs. Long Text Area deliberately
The 255 boundary is meaningful. Text is searchable and formula-friendly; Long Text Area is not. Pick based on the downstream usage.
- Add validation rules if needed
For data-quality control, add a validation rule with LEN() to enforce minimum or maximum lengths beyond what the field itself enforces.
- Document in the data dictionary
Record the chosen Length and the reasoning. Future admins inheriting the field will thank you.
Text, Long Text Area, Number, Currency, etc.
Maximum characters or digits.
Precision for numeric fields.
Whether the field acts as an alternate key.
Whether the field enforces uniqueness.
- Decreasing field length requires data validation. Production decreases can fail if any row exceeds the new shorter length.
- Long Text Areas are not indexed by default. Searches against them are slow until indexing is enabled.
- Standard field lengths cannot be changed. Integration code must respect them or DML fails with STRING_TOO_LONG.
- Multibyte characters count as one each in LEN() but consume more bytes in storage. Database storage estimates need to account for the multibyte multiplier.