Dataverse column

What is a Dataverse column?

A Dataverse column defines one data element for the records in a table. It has a display name, a logical schema name, a data type, and settings for input, validation and behaviour. Columns were called fields, or attributes, before Microsoft Dataverse updated its terminology in late 2020, and the API layer still uses the older attribute name.

Apps read the column metadata to render a suitable control, and APIs use the logical name and data type. So a column is both a user-facing field and part of a technical contract.

In a case table, examples might be Case number, Received date, Amount, Status and Owner.

Choosing a data type

Text columns have a maximum length and an optional format such as email or URL. Numbers split into whole, decimal, floating-point and currency values, each with its own storage and precision.

Date and time can be stored and shown as user-local, date-only, or time-zone independent. The choice changes what users in different time zones actually see, which matters for deadlines and audit.

Yes/No and choice columns limit input to a managed set of values. A lookup column points to a record in another table and forms the many-to-one side of a relationship.

Choice versus a separate table

A choice fits a small, stable list with no attributes of its own, like a simple priority band. Labels can be translated while the underlying numeric value stays put.

A separate reference table fits when the values carry an owner, a validity period, a code, a description or their own relationships. Those records can then be maintained without shipping a solution release.

Do not build a choice with hundreds of frequently changing values. That pushes business data into metadata and makes it harder to manage.

Required levels and validation

A column can be optional, business recommended, or business required. Business required is enforced by the platform interfaces, but integrations and special operations still have to be tested properly, since a save through the API can behave differently from a save through a form.

System-required applies to certain system columns and cannot be changed. For conditions more complex than presence, you need business rules, plug-ins or other server logic.

A red asterisk on a form is not a full data quality strategy. Record the allowed values, the source and the meaning as well.

Calculated and rollup columns

A calculated or formula column derives its value from other data using supported expressions, so each app no longer has to compute it separately. A rollup column aggregates related records, for example the total amount of the lines on a case.

Both are read-only and are computed by the platform under a system account, which means a rollup or calculated value can be based on records the current user cannot otherwise see. Rollups run on a schedule rather than instantly, so they are not always in step right after a change.

Use derived columns deliberately. Complex or time-critical logic often belongs in an explicit service or plug-in instead.

Column-level security and auditing

Column-level security can restrict read, create and write access to sensitive columns through field security profiles, while table access is still required on top. Use it for fields such as salary or a medical indicator when the wider record is more broadly accessible. Some column kinds, including lookups, formula columns and the primary name column, cannot be secured this way. As always, hiding a column on a form does not protect the API.

Auditing can record changes per column. Select what is genuinely audit-worthy and manage its retention rather than logging everything.

What to watch out for when changing columns

Logical names are durable and turn up in formulas, flows, code and integrations. A display name is easier to change than the schema contract behind it.

Changing a data type, a length or the set of choice values can break existing data and consumers. Plan a migration and test it with production-like data. Delete a column only after dependencies and retention needs are checked, because cleaning up the component during a solution upgrade can remove the physical data.