The pattern: think through the precision requirement before creating the field, set Decimal Places to match, document the choice for integrations. Changing later is restricted; the upfront thought is much cheaper than the migration workaround.
- Identify the precision requirement
Currency for commercial: 2. Currency for forex: 4 or 6. Quantity: 0. Percentages: 2 or 4. Scientific measurements: 6 to 8. Pick based on the field's actual use case.
- Set Length and Decimal Places together
Length is total digits; Decimal Places is digits after the decimal. Length must accommodate the largest expected value plus the decimal places.
- Verify the storage behavior with test data
Save a value with more precision than configured. Confirm the rounding matches expectation. The rounding is half-up; values exactly halfway round up.
- Configure related formula fields to match
Formula fields reference the source but have their own precision. Set formula precision based on the calculation's actual need, not just the source's precision.
- Document the precision in the integration contract
Integrations that read or write the field need to know the precision. Document in the integration spec; mismatches produce silent data loss.
- Test with locale variations if multi-currency or international
Different locales display differently. Confirm the display matches expectation for the user populations that will see the field.
- Plan the migration path if precision needs change
Changing Decimal Places on a field with data requires create-migrate-retire. Document the workaround if you anticipate the field's precision needs evolving.
0 to ~16 depending on field type. Match to precision requirement.
Total digits including decimals. Must accommodate largest value plus decimal precision.
Number, Currency, or Percent. Each has slightly different behavior around defaults and currency-specific precision.
Currency fields respect per-currency precision defaults; custom precision overrides.
Independent of source precision; set per calculation need.
- Decimal Places changes after creation are restricted on fields with data. The migration workaround is operationally heavy.
- Rounding is silent; the original precision is gone after save. A 0-decimal-place field saving 1234.5678 stores 1235 and the .5678 is unrecoverable.
- Per-currency precision defaults vary in multi-currency orgs. JPY uses 0 by default; configuring 2 overrides the traditional precision.
- Integration precision mismatches produce silent data loss. Document field precision as part of the integration contract.
- Formula precision is independent of source. A formula on a 4-decimal source with 2-decimal formula precision loses the fractional precision before downstream consumers see it.