Configuring Model-Driven App Column Properties: Data Types, Required Fields, and Display Settings for Dataverse Tables

Introduction

You've built a Dataverse table — maybe it's for tracking service requests, managing client accounts, or logging project milestones. The table exists, a handful of columns are in place, and you've got a form running in your model-driven app. But something feels off. Users are saving records with half the fields blank. Date fields are accepting text. A column labelled "Contract Value" shows no currency symbol. The dropdown for "Priority" shows internal code values instead of readable labels. What you're experiencing is the gap between a table that technically exists and a table that's been properly configured.

Column properties in Dataverse are the fine-grained settings that turn a raw schema into something that actively guides users, enforces data quality, and makes your app feel professional. Every column has a data type, a set of validation rules, and a collection of display settings — and every one of those settings is a choice you make as the maker. Get them right, and the form practically fills itself correctly. Get them wrong, and you'll spend your afternoons cleaning up dirty data or answering support tickets from confused users.

By the end of this lesson, you'll be confident navigating column property settings in both the Dataverse table designer and the model-driven form designer. You'll understand how to choose the right data type for your scenario, how to make fields required or optional at the right layer, and how to control what users see and interact with on a form — all without writing a single line of code.

What you'll learn:

• How Dataverse data types map to real-world data scenarios, and how to pick the right one
• The difference between required at the column level versus required at the form level
• How to configure display settings like labels, tooltips, column widths, and read-only behavior
• How field-level constraints (min/max values, max length, format options) work in practice
• Where column properties interact with business rules, views, and security

---

Prerequisites

You should have a working familiarity with the basics of Dataverse tables. If you haven't already, read Dataverse Fundamentals: Tables, Columns, and Rows Explained for Power Apps Makers before continuing — it covers what tables, columns, and rows are, and how data is stored. You should also have access to Power Apps (make.powerapps.com) with at least a maker license in an environment that supports Dataverse.

---

Understanding Column Properties: The Two Places They Live

Before diving into specific settings, you need to understand a structural reality that trips up almost every beginner: column properties exist in two places, and they do different things.

The first place is the Dataverse table designer (sometimes called the column editor). This is where you define the column's fundamental characteristics — its name, its data type, whether it's required at the data layer, and constraints like maximum length or minimum value. These settings apply everywhere the column is used: in model-driven apps, canvas apps, Power Automate flows, the Dataverse API, and direct database operations. Think of this as the column's DNA.

The second place is the model-driven form designer. When you add a column to a form, you can override certain display behaviors — the label shown on the form, whether the field appears read-only, whether it's visible by default, and how many columns wide it spans. These settings only affect that specific form. The underlying column data type and database-level constraints don't change.

This distinction matters enormously in practice. If you want a field to be required no matter what, set it as required in the table designer. If you only want it required in a specific context (say, required when a record moves to "Active" status but not when it's a draft), that logic belongs in a business rule or the form designer.

---

Choosing the Right Data Type

The most consequential column property decision is choosing the correct data type. Dataverse offers over a dozen types, and picking the wrong one creates problems that are painful to fix later — you can't easily change a column's data type once records exist.

Let's walk through the most important types and when each one is appropriate.

Text Columns

Text (Single line of text) is the workhorse. Use it for names, codes, addresses, email addresses, URLs, phone numbers, and any short free-form string. When you select this type, you also choose a format:

• Text — generic single-line text, no special validation
• Email — validates that the value looks like an email address; also renders as a clickable mailto link in the form
• URL — validates URL format; renders as a clickable hyperlink
• Phone — no strict validation, but renders with click-to-call behavior on supported devices
• Ticker Symbol — renders with a link to financial data

Always set the format appropriately. A column named "Primary Email" should use the Email format, not the generic Text format, because the Email format gives users immediate feedback if they type something that doesn't look like an address.

Max Length is the other key setting for text columns. The default is 100 characters. A client name might be fine at 100, but a description field probably needs 500 or more. Be generous but not reckless — unnecessarily large max lengths can affect performance at scale. Multiline Text is a separate type for longer free-form content like notes or descriptions; it supports up to 1,048,576 characters.

Whole Number and Decimal Number Columns

Use Whole Number for counts, quantities, and integer values — number of items ordered, a customer's age, an invoice line number. You can set a minimum value and maximum value to constrain the acceptable range. A "Star Rating" field with minimum 1 and maximum 5 will reject anything outside that range before it even hits your business logic.

The format for Whole Number includes options like "None," "Duration" (which renders as hours/minutes), "Time Zone," and "Language." For most scenarios, leave it on None.

Use Decimal Number when you need fractional precision for non-currency values — GPS coordinates, weight in kilograms, a percentage with two decimal places. You control the number of decimal places (0–10). Don't use Decimal for money values.

Currency Columns

When you add a Currency column — say, "Contract Value" or "Invoice Total" — Dataverse automatically creates a companion Decimal column behind the scenes to store the base-currency equivalent (used for currency conversion). You set the precision (number of decimal places) at the column level. On the form, the field renders with the currency symbol pulled from the record's currency field.

Choice Columns

Choice (formerly called Option Set) is one of the most powerful types in Dataverse. It stores a fixed set of allowable values — think of it as a dropdown with a defined list. Each option has a numeric integer value stored in the database and a human-readable label displayed in the UI. This is why, in a poorly configured app, you might see "100000001" in a field instead of "Pending Approval" — the label was never set properly.

You can create a Local Choice (values only available to that column on that table) or use a Global Choice (a reusable option set used across multiple tables and columns). If "Priority" with values High/Medium/Low will appear on multiple tables in your app, make it a Global Choice so you only maintain it in one place.

Choice (Allow multi-select) lets users pick more than one value — useful for things like "Industries Served" or "Skills Required."

Lookup Columns

A Lookup column creates a relationship to another table. Instead of storing a raw value, it stores a reference to a specific row in a related table. A "Primary Contact" field on a Project record is a Lookup to the Contact table. These are covered in depth in Designing a Dataverse Data Model: Relationships, Lookups, and Choice Columns, but the key property to understand here is the related table — you must specify which table the lookup points to when creating the column.

Yes/No (Boolean) Columns

A Yes/No column stores a true/false value. By default it renders as a toggle or checkbox. You configure what the "Yes" label and "No" label say — "Active/Inactive," "Approved/Pending," "Billable/Non-Billable." Always set these labels to something meaningful for your context rather than leaving the defaults.

Date and Time Columns

The Date and Time type has two important sub-settings: format (Date Only vs. Date and Time) and behavior.

• Date Only shows just a calendar picker, no time component
• Date and Time shows both date and time pickers

The behavior setting is critical and often misunderstood:

• User Local — the stored value is UTC, displayed adjusted to the current user's time zone. Use this for timestamps like "Created On" or "Meeting Start Time."
• Date Only — stores the date with no time zone conversion. Use this for birthdays, contract start dates, or any date that should display the same regardless of where the user is.
• Time Zone Independent — stores a specific date/time without any conversion. Rare; use only when the time zone information is encoded in the value itself.

File and Image Columns

File allows attaching an arbitrary binary file. Image stores an image file and can optionally display it as the table's primary image (the thumbnail shown in views and forms). Image columns have a max size setting in kilobytes.

---

Setting Required Fields: Column Level vs. Form Level

"Required" in Dataverse means two different things depending on where you configure it.

Database-Level Requirement (Column Properties)

In the Dataverse table designer, every column has a Required property with three options:

• Optional — the field can be saved blank
• Business Required — the field must have a value before a record can be saved, enforced by the model-driven form UI
• Business Recommended — the field is flagged as recommended but not enforced; it displays with a blue dot indicator on the form

Business Required is enforced at the form level in model-driven apps — a user cannot click Save if this field is blank. However, it's important to know that this enforcement happens in the UI. If a record is created programmatically via the Dataverse API or Power Automate without the field populated, the save will still succeed (unless you've enabled server-side enforcement). For true database-level constraints that no integration can bypass, you'd use server-side plugins — but that's out of scope for a foundation lesson.

Form-Level Requirement Override

In the form designer, you can change the requirement level for a specific field on that form. This is useful when the same column should be required in some contexts but optional in others. For example, "Delivery Address" might be Required on the Sales Order form but Optional on the Opportunity form.

To access this, open your form in the model-driven form designer (go to make.powerapps.com, open your app or table, navigate to the form). Click on the field in the form canvas. In the right-hand properties panel, find the Required dropdown. You can override it to Optional, Business Required, or Business Recommended just for this form.

If you want requirement levels to change based on conditions — for instance, requiring a "Rejection Reason" field only when Status is set to "Rejected" — that's where business rules come in. They can dynamically change requirement levels at runtime based on other field values.

---

Configuring Constraints on Column Values

Beyond data type and requirement level, several column types support additional constraints that enforce data quality before a record is saved.

Text Columns: Max Length and Format

Set the Maximum Length on text columns to the realistic maximum. If you're storing US phone numbers in a Text (Phone) column, 20 characters is more than enough. If you're storing a free-form description, maybe 2000. Setting this appropriately prevents users from pasting entire documents into a field that's meant for a brief title.

Number Columns: Min and Max Values

For Whole Number and Decimal columns, set Minimum Value and Maximum Value whenever the business logic calls for it. A "Discount Percentage" column should have min=0 and max=100. A "Quantity Ordered" column should have min=1. These constraints are enforced on save and display a clear error message when violated.

Text: Input Validation with Format

Choosing the Email, URL, or Phone format on a text column does light format validation. It won't catch every invalid email, but it will catch obvious mistakes — someone typing "john.doe" with no domain, for instance, won't pass the Email format check.

For more complex patterns — validating that a field matches a specific code format like "PROJ-0001" — you'd typically use a business rule with a regular expression check, or handle this in a plugin.

---

Display Settings on the Form

Once your column is properly typed and constrained, the form designer is where you shape how users interact with it. Here are the key display settings you'll configure.

Label and Description

By default, a field on the form shows the column's display name as its label. In the form designer, you can change the label text for this specific form without renaming the underlying column. This is useful when the same column serves different audiences — the column might be named "Opportunity Score" at the table level, but a simplified label like "Lead Score" makes more sense to the sales team who use a particular form.

The Description (or tooltip) field lets you add helper text that appears when users hover over the label. Use this to explain what a field means, what format is expected, or where the data comes from. A description like "Enter the contract value in USD before any discounts are applied" eliminates a whole category of data quality questions.

Read-Only and Locked

In the form designer, you can mark a field as Read-Only — users can see the value but cannot edit it. This is useful for:

• Auto-calculated fields that users shouldn't manually override (though for true calculated fields, you'd use formula columns or rollup columns)
• Fields populated by an automated process that shouldn't be changed manually
• Status fields that are managed by workflow

The Locked property is slightly different — it prevents the field from being removed from the form by other customizers, useful for protecting critical fields in managed solutions.

Visibility

You can set a field to be hidden by default on the form. The field is still part of the form — it can be shown/hidden programmatically by business rules — but it doesn't clutter the UI for typical scenarios. This is a common pattern: hide "Rejection Reason" until the Status is set to "Rejected," then make it visible and required via a business rule.

Column Width and Row Span

In section-based form layouts, fields can span one or two columns and one or multiple rows in height. For most standard fields, the default one-column, one-row layout is fine. For multiline text fields used for notes or long descriptions, increasing the row span to 3 or 4 gives users more visible editing space.

Column Span in Views

While we're thinking about display settings broadly, it's worth noting that columns in views also have a display width. When you add a column to a view in the view designer, you can set how wide it appears in the grid. A "Description" column with thousands of characters only needs to show 150–200 pixels wide — users can expand it if needed. The "Status" column with short option values can be narrower. Setting sensible column widths makes your views significantly more readable. Learn more about view configuration in Creating and Customizing Views in Model-Driven Apps: Filters, Sorting, and Editable Grids.

---

Hands-On Exercise

Let's put all of this together with a realistic scenario. You're building a Project Tracker model-driven app. The Projects table needs a new column, and you'll configure it from scratch.

Scenario: You need a "Estimated Completion Date" column that must be filled in before a project moves out of Draft status, and a "Project Budget" column that tracks the planned spend in currency.

Step 1: Create the Estimated Completion Date column

1. Go to make.powerapps.com and navigate to your environment
2. Open Dataverse → Tables → select your Projects table
3. Click + New column (or navigate to the Columns section and add from there)
4. Set Display Name to "Estimated Completion Date"
5. Set Data Type to "Date and Time"
6. Set Format to "Date Only" (project dates don't need time)
7. Set Behavior to "Date Only" (so there's no time zone conversion — a project ending December 31st should show December 31st to every user)
8. Set Required to "Optional" (you'll handle requirement via a business rule triggered on status change, not as an absolute database requirement)
9. Click Save

Step 2: Create the Project Budget column

1. Click + New column again
2. Set Display Name to "Project Budget"
3. Set Data Type to "Currency"
4. Set Precision to 2 (dollars and cents)
5. Leave Required as "Optional"
6. Click Save

Step 3: Add both columns to the Main form and configure display settings

1. Navigate to your Projects table's Forms area
2. Open the Main form in the form designer
3. Drag "Estimated Completion Date" onto the form in a relevant section (perhaps near "Project Start Date")
4. Click the field to select it, then open the Properties panel on the right
5. Change the Label to "Target Completion Date" (more user-friendly phrasing for this form)
6. Add a Description (tooltip): "The expected date this project will be fully delivered and signed off"
7. Leave Required as Optional — you'll create a business rule separately
8. Now drag "Project Budget" onto the form
9. In the Properties panel, add a Description: "Planned total spend in USD before any approved change orders"
10. Click Save then Publish the form

Step 4: Verify

Open the Projects app, create a new Project record. You should see "Target Completion Date" with a date picker (no time selector) and "Project Budget" with a currency input. Hover over the label — the tooltip descriptions should appear.

---

Common Mistakes & Troubleshooting

Mistake: Using Text instead of a specialized type A common beginner habit is reaching for Text for everything. If you store email addresses in a plain Text column, you lose the clickable mailto link and format validation. If you store numbers in Text, you can't do arithmetic in views, rollup fields, or Power Automate calculations. Always use the most specific type that fits the data.

Mistake: Setting everything as Business Required at the column level Making too many fields required at the database level creates a nightmare for data imports and API integrations. When you bulk-import records via Excel or dataflows, required fields without values will fail. Reserve hard Business Required for the absolute minimum — usually Name, Status, and Owner — and handle contextual requirements through business rules.

Mistake: Changing data types after data exists Dataverse prevents many data type changes once a column has data. You cannot change a Text column to a Whole Number, for example, because existing text values can't automatically become numbers. If you realize you've used the wrong type, you often have to create a new column, migrate the data, update all forms and views to use the new column, and delete the old one. The lesson: plan your types carefully upfront.

Mistake: Forgetting to publish after form changes If you update display settings in the form designer and don't click Publish, your changes don't appear in the live app. This is a frequent source of "I made the change but nothing happened" confusion. Always save and publish.

Troubleshooting: A required field isn't blocking saves If you've set a field as Business Required but users can still save without it, check whether the field is actually present on the form they're using. A Business Required field only blocks saves if it's on the active form. If users are on a different form (Quick Create form, a mobile form), the requirement may not be enforced there. Also check whether a business rule is overriding the requirement back to Optional.

Troubleshooting: Currency field shows wrong symbol Currency fields display the symbol based on the "Currency" field on the record, which itself defaults to the organization's base currency. If a user changes the Currency field on the record to EUR, the currency column will display in Euros. This is correct behavior, not a bug — but it can surprise users if they don't expect multi-currency support.

---

Summary & Next Steps

Column properties are the foundation of a well-functioning model-driven app. You've now learned how to navigate the two layers where column properties live — the Dataverse table designer for data-level settings and the form designer for display-level settings. You understand how to choose the right data type for real-world scenarios, how to configure requirement levels appropriately, how to add constraints that catch bad data early, and how display settings like labels, tooltips, visibility, and read-only behavior shape the user experience.

The key mental model to carry forward: configure the column for integrity, configure the form for experience. A column's data type and database constraints are your first line of defense against dirty data. Form display settings are how you guide users toward entering good data in the first place.

From here, there are several natural directions to deepen your skills:

• Business rules let you make requirement and visibility settings dynamic — showing or hiding fields, making them required or optional, based on other field values at runtime. See Business Rules in Dataverse: Validation and Field Logic Without Code.
• Formula and rollup columns let you create columns whose values are automatically calculated from other columns — great for totals, age calculations, and derived metrics. See Formula Columns and Rollup Columns in Dataverse: Calculated Data Without Code.
• Column-level security lets you restrict which users can see or edit sensitive columns like salary or personal identification numbers. See Column-Level Security and Record Sharing in Dataverse.
• Form layout — now that your columns are configured, learn how to arrange them into intuitive tabs and sections in Designing Model-Driven Forms: Sections, Tabs, Subgrids, and Quick View Forms.