Numerical Field Types

Audience: Administrators, Developers, Solution Architects

Purpose: Explain how to use numerical field types to accurately capture quantitative data and select the correct field type when designing Object schemas.

Overview

Numerical field types are structured fields used to capture measurable values such as quantities, financial amounts, percentages, and projections.

These fields power:

• Accurate reporting and aggregation

• Mathematical operations and calculated values

• Forecasting and weighted projections

• Automation triggers and conditional logic

• API-based integrations and data pipelines

Selecting the correct numerical field type is a foundational schema decision that directly impacts data precision, validation behavior, formatting and display, reporting accuracy, and the reliability of downstream analytics and integrations.

Whenever numeric data will be aggregated, used in calculations, or evaluated by Automation, selecting the correct field type becomes critical.

Warning: Using the wrong numerical field type can introduce rounding issues, reporting inconsistencies, or unexpected Automation behavior.

The sections below explain each numerical field type and when to use it.

---

Number (Decimal)

The decimal field type supports fractional values and is designed for data that requires precision beyond whole numbers.

Common Use Cases

Use this field when values require fractional precision, such as:

• Percentages (for example, 12.5%)

• Rates (for example, 4.25% interest rate)

• Measurements (for example, 2.75 hours, 10.5 miles)

• Ratios and calculated outputs

• Financial values that are not currency-specific

Behavior Considerations

Decimal fields support fractional input and are optimized for calculations, aggregations, and threshold-based Automation. A decimal field:

• Accepts numeric input with decimal points, including negative numbers

• Supports mathematical operations in reporting and Automations

• Supports fractional values for reporting, calculations, and Automation logic

• Supports up to 15 total digits, with up to 4 digits displayed after the decimal point

Choose decimal fields if rounding errors may materially affect reporting accuracy, forecasts, or Automation logic.

If your data requires fractional accuracy, use decimal instead of integer to prevent truncation or rounding errors.

---

Number (Integer / Whole)

The integer field type captures discrete numeric values that do not require fractional precision. Integer fields require whole-number values when inputted into the UI and API calls.

Common Use Cases

Use this field when values must remain whole numbers, such as:

• Item counts

• Units in inventory

• Event attendance

• Number of employees

Behavior Considerations

Integer fields enforce whole-number input, supporting accurate counting, aggregation, and threshold-based Automation. An integer field:

• Restricts values to whole numbers

• Allows negative values

• Supports values from -2,147,483,647 to 2,147,483,647. Values are displayed with comma separation

• Prevents fractional input

• Ensures consistent reporting and aggregation

• Supports clear quantitative comparisons

Use integer fields when fractional values would introduce ambiguity or distort reporting. By restricting precision, the integer field enforces data consistency and avoids unintended decimal usage.

---

Money / Currency / Price

The money field captures monetary values and provide currency-aware handling to support financial reporting, forecasting, and operational workflows.

Common Use Cases

Use this field for monetary values such as:

• Revenue tracking

• Deal values

• Pricing

• Budgeting

• Cost analysis

• Commerce-related workflows

Behavior Considerations

Money fields are currency-aware and formatted according to the business’s configured currency settings. Depending on configuration:

• Values may use a single default currency

• Each Money field instance stores one monetary value in one currency

Currency configuration directly impacts reporting accuracy, forecasting, and financial integrations.

When designing financial schemas, confirm:

• Whether your organization operates in multiple currencies

• How currency conversion should be handled in reporting

• Whether downstream systems expect currency codes

Your currency strategy should be established before implementing financial fields.

Note: Money fields store currency values but do not perform currency conversion.

Why Not Use Decimal for Money?

Decimal fields store numeric values without currency context.

Money fields store numeric values with associated currency formatting and display the appropriate currency symbol based on business configuration.

Use Money fields when values represent financial amounts and should be displayed with currency formatting in the application.

---

% Chance to Close

The % Chance to Close field represents the probability that a pipeline Record will reach a successful outcome. It is a system field used in weighted pipeline forecasting calculations.

This field is available on pipeline-enabled Objects and interacts with stage-level probability settings defined in the Object’s pipeline configuration. The value may be influenced by stage changes or, if enabled, AI-driven predictions.

Common Use Cases

Use this field when managing probability-driven pipeline Records, such as:

• Tracking sales opportunities

• Forecasting projected revenue

• Weighting deal values based on probability

The % Chance to Close field is part of the Object’s workflow and forecasting logic. It should be used only within lifecycle-driven pipeline Objects where probability impacts forecasting.

---

Additional Information

Schema Design Best Practices

Before implementing numerical fields:

• Confirm required precision

• Identify reporting and aggregation needs

• Evaluate Automation triggers using numeric comparisons

• Consider API integrations and downstream systems

• Avoid retroactive schema changes that may affect calculations

Changing numerical field types after implementation can disrupt reporting and integrations. Design intentionally.

---

What’s Next

Review field-specific documentation before making schema changes to ensure consistent data behavior across Objects, Workflows, and integrations. To continue designing your schema, review our related topics.

Related Topics

• Date Field Types

• Selection Field Types

• Text Field Types

• Communication Field Types

• Special Field Types