Try Serpent Free

How to fix NUMBER_OUTSIDE_VALID_RANGE in Salesforce deployments

A numeric field value on a record being saved exceeds the digits or decimal places defined for that field.

Surfaces during: runtime DML, in data loads, Apex tests, and formula or rollup evaluation

What it means

NUMBER_OUTSIDE_VALID_RANGE fires when a value written to a Number or Currency field has more digits, or more decimal places, than the field's precision and scale allow. Salesforce defines those limits on the field itself, so any value outside them is rejected at save time regardless of where it came from.

Precision and scale are set at field creation and are notoriously hard to widen later without a support case in some editions, so this error often points at a field definition that was undersized for the data it now needs to hold, not just a one-off bad value.

Diagnosis

Common causes

Migrated data carries more precision than the field allows
Source data has more decimal places than the destination field's scale, often from a system with looser numeric formatting.
A formula or rollup output exceeds the field's digit limit
A calculated value grows past the maximum number of digits the destination field was defined to hold.
Currency conversion introduced extra decimal precision
Multi-currency conversion produces a value with more decimal places than the field's defined scale after rounding.

The fix

  1. Round or truncate values before loading
    Adjust the migration or transform step to match the destination field's exact precision and scale before insert.
    Decimal rounded = rawValue.setScale(2, System.RoundingMode.HALF_UP);
  2. Widen the field if the extra precision is legitimate
    Increase the field's decimal places or digit count in Setup if the business genuinely needs that level of detail.
  3. Check formula outputs against the field definition
    Confirm any formula or rollup summary feeding the field can't produce a value that exceeds its numeric limits.
In practice

How Serpent prevents this

Serpent's pooled scratch orgs share the same field definitions as the branch under test, so a migration script producing out-of-range values fails fast in an isolated environment instead of during a shared sandbox load. See the Salesforce deployment error library.

Metadata and data in one deployment flow in Serpent

Prevention

Size number and currency fields for the largest realistic value upfront
Estimate the true maximum magnitude and precision a field needs at design time, since widening precision and scale later is disruptive on some field configurations.
Round explicitly at every write path into a scaled field
Apply setScale() at the point of assignment in Apex and in ETL transforms, rather than relying on the platform to round silently for you.
Profile source data ranges before a migration
Check the min, max, and decimal precision of the actual source data against the destination field's definition before running a bulk load.
Common questions

NUMBER_OUTSIDE_VALID_RANGE, answered

Does this only affect Currency fields?
No. It applies to any Number or Currency field; the trigger is the field's precision and scale definition, not the field type specifically.
Can I widen a Number field's precision without losing existing data?
Usually yes, increasing precision or scale is generally safe for existing records, but always confirm in a sandbox first since some field configurations and very large existing datasets can behave differently.
Does Salesforce round silently instead of rejecting, in any case?
No. Unlike some databases that truncate silently, Salesforce always rejects a value that exceeds the field's defined precision and scale rather than rounding it for you.

Start free. No credit card, no install, no commitment.

Set up in under 15 minutes. No DevOps hire needed.

Curious about faster shipping before you dive in? Let's talk

Commitment free!