What it does

Every Dataverse column has a data type, and most types carry a format that changes presentation and validation without changing storage. The naming differs between the modern designer, solution explorer and the API, which is a recurring source of confusion.

Key facts

• Once a column is saved, the data type can't be changed. The one exception is converting a text column to autonumber.
• Text formats — Text, Text Area, Email, URL, Ticker Symbol, Phone — are all StringType underneath. The format only affects rendering and validation.
• Decimal stores exactly what you give it; floating point stores a very close approximation. Use decimal when you compare for equality or need reporting accuracy, float when you're doing greater-than/less-than comparisons on fractions.
• Big integers (BigInt) go up to 9,223,372,036,854,775,807 but aren't supported in canvas or model-driven apps. Canvas apps don't support the decimal type either.
• Browsers handle up to 15 digits precisely. A 16-digit value can be silently altered by the client before it ever reaches Dataverse — that limit is the browser's, not the platform's.
• Adding the first currency column to a table also adds a Currency lookup and an Exchange Rate decimal column. Every currency column then gets a paired _Base column holding the value converted to the organisation's base currency. Both the exchange rate and base columns are read-only on forms.
• Currency precision comes from one of three sources: the organisation-wide pricing decimal precision, the precision defined on the currency row, or a specific value between 0 and 4.
• Dataverse stores all date and time values in UTC. Behaviour options are User local (converted to the user's time zone), Time zone independent (no conversion) and Date only (no time portion stored at all).
• Date only is the default behaviour for the Date only format; User local is the default for Date and time. Behaviour can be changed from User local to one of the others exactly once, and only affects values written after the change.
• Older Than X Minutes, Older Than X Hours, Last X Hours and Next X Hours all throw an invalid operator exception against a Date only behaviour column.
• The user's time zone comes from their personal options in the app, not from the operating system.

When to use / skip

Pick the number type on how it'll be queried, not on how it looks: decimal for money-adjacent and equality comparisons, float for measurements and ranges, whole number for counts. Use Time zone independent for anything where the wall-clock time is the fact — hotel check-in, shop opening hours, a scheduled slot in a fixed location. Use Date only for dates that have no time at all: birthdays, contract dates, invoice dates. Reserve User local for genuine moments in time that different people in different places should see differently. Multi-currency is worth enabling only when the client actually transacts in more than one; the extra columns and the base-currency arithmetic are permanent overhead otherwise.

Configuration decisions

• Decimal versus float versus whole number, decided on query patterns rather than on the sample data.
• Date behaviour per column, which is the single most consequential formatting decision and is effectively one-way.
• Currency precision source — organisation pricing precision, per-currency precision, or a fixed value.
• Whether the value belongs in a text column with a format or a properly typed column, because Email format on a string is validation, not a data type.
• Text maximum lengths, set with room to grow, since lowering them later doesn't truncate but does reject.

Gotchas

• Date only format combined with User local behaviour is the classic bug: the time is set to midnight in the entering user's time zone, and a colleague elsewhere sees the previous or next day. Microsoft explicitly warns against this combination and it's still everywhere.
• Changing an existing date column's behaviour leaves the historical values in UTC. New rows behave one way, old rows another, and reconciling them needs developer work.
• After changing date behaviour you have to reopen and re-save every dependent business rule, workflow, calculated column and rollup column, or they keep using the old behaviour.
• The 15-digit browser precision limit means long numeric identifiers stored as numbers can be corrupted before Dataverse sees them. Store identifiers as text.
• The base currency column is calculated at the time of the write using the exchange rate then in force. Updating an exchange rate doesn't retrospectively fix historic rows, which is correct accounting and a constant source of "the report's wrong" tickets.
• Daylight saving transitions produce times that don't exist or happen twice, and different clients handle that differently — some reject, some shift, some just don't offer the times.

Consultant notes

• Do a date behaviour walkthrough with the client for every date column. Ask "if someone in another country opens this record, should they see the same date?" — the answer picks the behaviour and takes about ten seconds per column.
• Warn that data types are permanent. A column that's the wrong type gets replaced and migrated, and it's always more work than anyone budgets.
• Multi-currency needs a named owner for exchange rates before go-live. Nobody volunteers for this afterwards and the base currency values quietly stop meaning anything.
• If canvas apps are in scope, flag the Big and decimal limitations at design time rather than letting a developer discover them mid-sprint.

---

Worth another look if canvas app support for decimal and big integers changes, or if date behaviour becomes reversible.