Creating and Customizing Views in Model-Driven Apps: Filters, Sorting, and Editable Grids

Introduction

Picture this: your sales team's model-driven app has a single "Active Accounts" view showing every account in the system — all 4,200 of them — sorted alphabetically by account name. Every morning, reps scroll endlessly looking for their assigned accounts in the Pacific Northwest region, past hundreds of records they'll never touch. Meanwhile, the operations manager is asking why the app feels slow and why her team keeps making data entry errors when updating renewal dates one record at a time.

Views are the primary lens through which users interact with data in a model-driven app. They're not just filters on a list — they're the difference between a tool that helps people work efficiently and one that generates daily frustration. A well-designed view surfaces exactly the right records in the right order, with the right columns visible, scoped to exactly what a given user needs to see. A poorly designed view dumps everything in the user's lap and calls it a day.

By the end of this lesson, you'll be able to build views that do real work: filtered down to meaningful subsets of data, sorted strategically, and enabled for direct inline editing through editable grids — so your users can update records without ever leaving the list.

What you'll learn:

• The different view types in model-driven apps and when to use each one
• How to build and configure views using the Power Apps view designer, including column selection and ordering
• How to construct multi-condition filters using both simple criteria and FetchXML for complex scenarios
• How to configure multi-level sorting and understand its performance implications
• How to enable and configure the Editable Grid control for inline record editing
• How to create personal views and manage the relationship between system and personal views

---

Prerequisites

This lesson assumes you're comfortable with Dataverse fundamentals — specifically that you understand tables, columns, and rows in Dataverse and that you've already worked through building a basic model-driven app including the basics of forms and views. You should also have a working Dataverse environment with at least one table that has meaningful data or a realistic schema. The examples throughout this lesson use a Service Request scenario with related Account and Technician tables, but the patterns apply universally.

---

Understanding View Types Before You Build

Before you open the view designer, you need to understand that not all views are the same kind of object. Model-driven apps have several distinct view types, each with a specific role, and using the wrong type for the job creates problems down the road.

Public views (sometimes called System views) are the workhorses. They're visible to all users who have access to the table and appear in the view selector dropdown on list pages. When you create a new view in the designer and publish it, this is what you get by default. Your regional filters and role-based record sets should live here.

Default views are a subset of public views. Every table has one designated default view — the one that loads when a user navigates to that table's list page for the first time. Choosing the right default view matters enormously for first-run experience. The system-generated "Active [Table Name]" view is the default out of the box, but you should almost always replace it with something more contextually appropriate.

Quick Find views control what happens when a user types in the search box at the top of a list. Only one Quick Find view exists per table, and it defines both which columns are searched and which columns appear in the results popup. Getting this right dramatically improves your app's usability.

Lookup views control what records and columns appear when a user opens a lookup field popup — for example, clicking the magnifying glass next to the "Account" field on a Service Request form. These are separate from your main list views and deserve their own attention.

Associated views appear in subgrids and related record lists — for example, the list of Service Requests you see at the bottom of an Account form. These typically show a narrower set of columns relevant to the context of the parent record.

---

Navigating the View Designer

Open the Power Apps maker portal (make.powerapps.com), select your solution, then navigate to your table. Under the Views tab, you'll see all existing views for that table. Click New view or open an existing one.

The view designer gives you a canvas-style layout with two primary working areas: the column list on the left showing all available columns, and the column display area across the top representing what will actually appear in the grid. Below the column display area is the filter panel and the sort settings.

To add a column, either drag it from the left panel or click its name and select Add column. The order you add them determines the left-to-right order in the grid. You can reorder columns by dragging the column headers in the display area.

Column width matters more than most makers realize. The default width of 100px is too narrow for most text fields and too wide for most date or status fields. Click a column header in the display area and set an explicit width — 150px for short text, 200-250px for names and descriptions, 90px for dates and status fields. Users notice immediately when columns are badly sized.

The columns available in the view designer include not just direct columns on the table, but also related columns from parent lookups. If your Service Request table has a lookup to Account, you can pull in the Account's Industry or Primary Contact directly into the view. These "related columns" are powerful but come with a performance cost we'll discuss in the sorting section.

---

Building Filters That Actually Mean Something

Filters are where views go from "a list of records" to "the right records for this context." The view filter editor is a visual query builder — no code required for most scenarios — but you need to understand the underlying logic to use it well.

The Filter Editor Fundamentals

In the view designer, click Edit filters in the right panel. You'll see a condition group with an And/Or operator and a list of conditions. Each condition has three parts: a column, an operator, and a value.

For our Service Request scenario, a useful starting filter might be:

• Status equals Active
• Created On is in the last 30 days

But here's a subtlety that trips up many makers: the And/Or at the top of the filter group applies to all conditions in that group. If you want "Status = Active AND (Region = Pacific Northwest OR Region = Mountain West)", you need nested groups — a parent AND group containing the Status condition and a nested OR group containing the two region conditions.

To create a nested group, click Add group inside the filter editor. This inserts a sub-group with its own And/Or operator. Drag conditions into it or add new conditions directly inside the group.

Here's what the logic looks like for a "My Region's Active Requests" view:

AND
  ├── Status = Active
  └── OR
       ├── Region = Pacific Northwest
       └── Region = Mountain West

Dynamic Filters with Special Values

The real power of view filters is dynamic values — conditions that evaluate at runtime based on the current user or the current date, rather than being hardcoded strings.

The most important dynamic value is [Current User] (sometimes shown as "Current User"). When you set a filter like "Assigned Technician equals [Current User]", each person who uses the view sees only their own assigned records. You don't need a separate view per person — one view adapts to everyone.

Other dynamic values available include:

• Today / This Week / This Month — for date conditions
• Current User's Business Unit — filters to all records owned by anyone in the user's business unit
• Current User's Teams — records owned by any team the current user belongs to

For a service management app, combining these gives you high-signal views immediately:

• "My Open Requests" → Status = Active AND Assigned Technician = [Current User]
• "This Week's Completions" → Status = Completed AND Completed On = This Week
• "High Priority Unassigned" → Priority = High AND Assigned Technician = null

Going Deeper with FetchXML

The visual filter editor covers maybe 80% of real-world filtering needs. For the other 20% — complex date range comparisons, aggregate-based conditions, or filters involving many-to-many relationships — you need FetchXML.

FetchXML is the XML query language that Dataverse uses internally. Every view filter compiles to FetchXML under the hood. You can access and edit the raw FetchXML by downloading it from the view's advanced settings, editing it externally, then uploading it back.

A practical example: suppose you need a view of Service Requests where the SLA deadline is within 48 hours and the status is still Active. The visual editor can't express "within 48 hours of now" — that's a relative calculation. In FetchXML, you can use the olderThan / within operators:

<fetch>
  <entity name="new_servicerequest">
    <attribute name="new_requestnumber" />
    <attribute name="new_title" />
    <attribute name="new_status" />
    <attribute name="new_sladeadline" />
    <attribute name="new_assignedtechnicianid" />
    <filter type="and">
      <condition attribute="new_status" 
                 operator="eq" 
                 value="1" />
      <condition attribute="new_sladeadline" 
                 operator="next-x-hours" 
                 value="48" />
    </filter>
    <order attribute="new_sladeadline" descending="false" />
  </entity>
</fetch>

The next-x-hours operator evaluates dynamically at runtime — every time the view loads, it recalculates based on the current timestamp. No hardcoded dates, no manual maintenance.

To use FetchXML with a view, the most reliable workflow is:

1. Build as much of the filter as possible in the visual editor
2. Export the view's solution component as an unmanaged solution
3. Unzip the solution, find the SavedQuery XML file for your view
4. Edit the <fetch> element directly
5. Rezip and import back into your environment

---

Sorting: Strategy and Performance

Sorting in a view serves two purposes: it controls the default presentation order when the view first loads, and it hints to Dataverse how to optimize the query. Both matter for production systems with meaningful data volumes.

Configuring Sort Order

In the view designer, click a column header in the display area to sort by that column. A small arrow indicator shows the sort direction. Click again to reverse direction. To add a secondary sort, hold Shift while clicking a second column.

Alternatively, open the Sort panel (accessible from the command bar in the view designer) to set sort orders explicitly and manage priority. You'll see a numbered list where 1 is the primary sort, 2 is the secondary, and so on. Drag to reorder priority.

For our service management scenario, a well-considered multi-level sort might be:

1. Priority (descending — Critical first, then High, Medium, Low)
2. SLA Deadline (ascending — most urgent first within each priority)
3. Created On (ascending — oldest first when priority and deadline are equal)

This creates a meaningful automatic triage order where the most urgent work is always at the top.

Sorting on Choice Columns

Sorting on choice columns (option sets) sorts by the underlying numeric value, not the label alphabetically. This means you control the sort order by controlling the values you assigned when you designed the column. If you want Critical = highest priority, assign it value 100 (or whatever your highest number is), and sort descending.

If you inherited a schema where the values weren't designed with sort order in mind — say, Critical = 1, High = 2, Medium = 3, Low = 4 — then sorting ascending will actually give you the right order. The key is to verify this with real data before publishing.

Performance Implications of Sort Columns

Sorting on related columns (columns pulled in from a parent table via lookup) is significantly more expensive than sorting on direct columns. When you sort on "Account.Industry" in a Service Request view, Dataverse has to join the Account table in the query, and that join happens at query time for every page load. On tables with tens of thousands of records, this can cause noticeable delays.

The practical rule: sort on indexed columns on the primary table. Status, created on, modified on, owner, and the primary key are all indexed by default. Custom columns you create are not automatically indexed — you need to explicitly enable indexing in the column's settings if you plan to sort or filter on them heavily.

---

Enabling and Configuring Editable Grids

Here's where views go from read-only lists to interactive data management surfaces. The Editable Grid control lets users update field values directly in the list — no need to open individual records, make a change, save, and navigate back to the list. For bulk updates to a common field (updating status on 20 records, adjusting renewal dates, reassigning ownership), it cuts the time required by an order of magnitude.

What the Editable Grid Actually Does

By default, model-driven app views display a read-only grid. The Editable Grid is a separate control that you configure at the table or view level. When enabled, users can:

• Double-click a cell to edit it inline
• Tab between cells to edit multiple fields in sequence
• Select multiple rows and update a shared field across all selected records simultaneously
• Open a quick form in a side panel for more complex edits without full navigation

The editable grid supports most column types: text, numbers, dates, choice columns, yes/no fields, lookups, and currency. It does not support calculated columns (they're read-only by nature), rollup columns, or file/image columns.

Configuring the Editable Grid Control

To enable the Editable Grid for a table in your model-driven app:

1. Open your app in the app designer (make.powerapps.com → Apps → Edit your model-driven app)
2. Select the table in the Pages panel where you want to enable the editable grid
3. In the table properties, look for Controls and click Add control
4. Select Editable Grid from the control list
5. Choose which form factors to enable it on: Web, Phone, Tablet — you can enable different controls for different form factors
6. Save and publish

Alternatively, you can configure the Editable Grid at the individual view level rather than the table level, which gives you finer control. To do this:

1. Open the view in the view designer
2. Select the Components or Controls option in the right panel
3. Add the Editable Grid control to this specific view
4. Configure the properties (described below)

The view-level configuration is more precise but requires per-view setup. The table-level approach applies the editable grid to all views on that table, which is simpler but less targeted.

Key Editable Grid Properties

Once you've added the Editable Grid control, you'll see a property panel with several important settings:

Enable Filtering — When set to Yes, users see an inline filter row at the top of each column where they can type to filter the visible records. This is separate from the view's built-in filter and operates on the client side (within the already-loaded records). For views with large datasets, remind users that client-side filtering only applies to loaded records, not the full dataset.

Enable Grouping — Allows users to drag a column header to a grouping zone, collapsing records by that column's value. Useful for summary-style views. Note that grouping disables multi-record editing.

Show Tooltip — Controls whether cell-level validation messages appear as tooltips on hover.

Enable Pre-Grid Filtering — When enabled, users see filter options before the grid loads, which can prevent unnecessary data loading for large tables. This is especially valuable for tables with millions of rows.

Grouped Controls — You can specify related records to show in nested rows — essentially an inline subgrid — but this is an advanced feature best approached after you're comfortable with the basic editable grid.

Here's a realistic configuration for a "Service Request Triage" view in a service management app — the configuration you'd set in the control properties:

Enable Filtering: Yes
Enable Grouping: No
Show Tooltip: Yes
Enable Pre-Grid Filtering: No
Form Factor: Web, Tablet

Grouping is disabled because the view already has meaningful sorting by priority and SLA deadline, and grouping would interfere with that ordering. Pre-grid filtering is off because this view is already heavily filtered by the view's own conditions and the dataset is manageable.

Multi-Record Editing

The crown jewel of the Editable Grid is multi-record editing. Here's how it works in practice:

1. Users check the checkbox column on the left to select multiple rows (or check the header checkbox to select all records on the current page)
2. They double-click a cell in any of the selected rows in a column they want to update
3. A value entry appears — when they commit the value, it applies to all selected records simultaneously

This is genuinely powerful for scenarios like:

• Reassigning all open requests from a departing technician to a replacement
• Marking a batch of requests as "Pending Parts" when a supplier delays
• Updating the renewal period on a cohort of accounts

The underlying mechanism fires a separate update call per record — it's not a true bulk update in the database sense — so very large selections (hundreds of records) can be slow. For actual bulk database operations at scale, that's a job for Power Automate or a plugin. But for the 5-50 record range that a user would realistically select manually, it works well.

---

Designing Views for Different User Roles

Role-based security in model-driven apps determines which records users can see at the data layer. But views determine what they see at the interface layer. These two mechanisms work together.

A common pattern is creating role-optimized views that pair with security roles. Consider a service management app with three roles: Technician, Team Lead, and Operations Manager.

Technician views:

• "My Open Requests" — filtered to assigned technician = [Current User], status = Active
• "My Completed This Week" — same filter plus Completed On = This Week
• Default view: "My Open Requests"

Team Lead views:

• "My Team's Open Requests" — filtered to assigned technician is in [Current User's Teams], status = Active
• "Unassigned High Priority" — Priority = High or Critical AND Assigned Technician = null
• Default view: "My Team's Open Requests"

Operations Manager views:

• "All Active Requests by SLA" — no ownership filter, sorted by SLA deadline
• "Aging Requests" — open for more than 7 days with no status update
• "This Week's Volume" — all requests created this week, grouped by region

Notice that none of these views require different security configurations — they're all public views visible to anyone with access to the table. The filtering is purely about presenting the right slice of data for each role's workflow. If security needs to restrict which records a role can access at all, that's configured in the security role definition, not in views.

---

Managing the Quick Find View

The Quick Find view deserves its own discussion because it controls one of the most frequently used features: the search box. When users type in the search bar on a list page, Dataverse runs a "starts with" query against specific columns defined in the Quick Find view.

Every table has exactly one Quick Find view. Open it from the Views list — it's labeled "Quick Find Active [Table Name]" by default.

The Quick Find view has a different structure from regular views. It has two distinct column sections:

Find Columns — The columns that are actually searched. When a user types "Smith", Dataverse checks all Find Columns for records starting with "Smith". Add the columns users are most likely to search by: request number, title, customer name, technician name.

View Columns — The columns that appear in the search results popup. Keep this to 3-4 highly identifying columns so the popup is scannable.

A common mistake is adding too many Find Columns, thinking it makes search more powerful. In practice, each additional Find Column adds a query condition joined with OR, which increases query cost. Stick to 4-6 genuinely useful search columns.

For the Service Request Quick Find view, a well-designed setup:

Find Columns:

• Request Number (primary key string)
• Title
• Account Name (related, from Account lookup)
• Assigned Technician (related, from Technician lookup)

View Columns:

• Request Number
• Title
• Status
• Assigned Technician

This lets users search by any of those four fields and immediately see the key identifying information in the results.

---

Hands-On Exercise

Let's build a complete, production-ready view for a service management scenario. If you're following along with your own environment, substitute your actual table name and column names.

Scenario: You're building a "High Priority Escalation Queue" view for team leads in a field service organization. This view should show all active service requests that are high or critical priority, were created more than 24 hours ago, and are either unassigned or assigned to technicians who haven't updated them in the last 8 hours.

Step 1: Create the view

• Navigate to your Service Request table in the maker portal
• Click Views → New view
• Name it "High Priority Escalation Queue"
• Set the description: "Active high/critical requests requiring team lead attention"

Step 2: Add and arrange columns Add these columns in order, with suggested widths:

• Request Number (90px)
• Title (250px)
• Priority (100px)
• Assigned Technician (160px)
• Created On (120px)
• Last Modified On (120px)
• Account (160px)
• SLA Deadline (120px)

Step 3: Build the filter

Create an AND group with:

• Status equals Active
• Priority is in [High, Critical] (use the "In" operator to select multiple values)
• Created On is older than X hours — value: 24

Then add a nested OR group for:

• Assigned Technician does not contain data
• Modified On is older than X hours — value: 8

The full logic reads: "Active + (High or Critical) + created over 24 hours ago + (unassigned OR not updated in 8 hours)."

Step 4: Set the sort

1. Priority, descending (Critical before High)
2. SLA Deadline, ascending (nearest deadline first)
3. Created On, ascending (oldest first within same deadline)

Step 5: Enable Editable Grid

• Add the Editable Grid control at the table or view level
• Enable Filtering: Yes
• Enable Grouping: No
• Form Factor: Web only (this is a desktop workflow for team leads)

Step 6: Test Save and publish. Open the app, navigate to Service Requests, and select your new view. Verify that:

• The filter is working by checking a record — does it meet all three conditions?
• The sort order is correct — Critical before High, nearest SLA at top within each priority
• Editable Grid is active — can you double-click a cell and edit it?
• Multi-select works — select 3 records and update the Assigned Technician to a specific user in one operation

This view gives team leads a self-updating escalation queue that requires zero manual sorting or filtering every morning. It's the kind of view that makes people thank you for building the app.

---

Common Mistakes & Troubleshooting

"My filter isn't showing the right records." First, check the And/Or logic. Most filter errors are due to incorrect group logic — an OR where you needed an AND, or conditions in the wrong group. The visual editor can be misleading; recreate the filter from scratch if you're unsure, adding conditions one at a time and testing after each addition.

"The view loads slowly." Check your sort columns. If you're sorting on a related column (from a lookup), switch to sorting on a direct column. Also check your filter — are you filtering on an unindexed custom column? Enable indexing on that column in the column settings, or restructure the filter to use an indexed column. Views with many related columns (pulling in 4+ joined table columns) are also slower — consider denormalizing by creating direct columns populated via Power Automate.

"The Editable Grid control doesn't appear, even though I added it." The Editable Grid control requires that the Read-Write form factor you selected matches the user's actual form factor. If you enabled it for Web only but a user is on a tablet browser, it won't appear. Also verify you've published the app after adding the control — unpublished changes don't reach users.

"Users can see the view but can't edit fields in the editable grid." This is almost always a security role issue. Check the user's security role for field-level security on the columns they're trying to edit, and confirm they have the Write privilege on the table. The editable grid doesn't grant permissions — it just exposes the editing interface for permissions you already have.

"My Quick Find search isn't returning results I expect." Quick Find uses "starts with" semantics, not "contains." If users search "Smith" they'll find "Smith Plumbing" but not "John Smith." This is by design for performance reasons. If you need contains-style search, enable Relevance Search (Dataverse Search) in your environment settings — it provides full-text search across all searchable tables and columns.

"I published a new view but users see the old one." Views are cached on the client. Ask users to do a hard refresh (Ctrl+Shift+R / Cmd+Shift+R) or clear their browser cache. In some cases, users need to sign out and back in. In enterprise environments with aggressive caching, it can take up to an hour for published changes to propagate to all users.

---

Summary & Next Steps

Views are the primary interface between your data and your users in a model-driven app. Done well, they reduce cognitive load, speed up common workflows, and make users feel like the app was built specifically for them. Done carelessly, they create noise and frustration that undermine the entire application.

Here's what you've built in this lesson:

• A mental model of view types — public views, default views, Quick Find views, lookup views, and associated views each serve a specific purpose
• Practical filter construction skills — including nested group logic, dynamic values like [Current User], and FetchXML for advanced scenarios the visual editor can't handle
• Informed sorting strategy — understanding that sort column choice has real performance implications, not just presentational ones
• Editable Grid configuration — enabling inline editing, multi-record updates, and understanding what the control can and can't do
• Role-based view design — creating purpose-built views for different user personas rather than one-size-fits-all lists

The logical next area to explore from here is forms — specifically designing model-driven forms with sections, tabs, subgrids, and quick view forms, since views and forms are the two halves of a complete record interaction experience. When a user clicks through from your carefully designed view, the form they land on needs to be equally thoughtful.

You should also revisit your data model design with your new view knowledge in mind — specifically whether any columns need indexing enabled, whether denormalized "cached" fields would help view performance, and whether your choice column values are ordered in a way that sorts correctly.

Finally, if your organization has multiple security roles with meaningfully different data access needs, the interaction between security roles and what users see in views deserves dedicated attention — especially the difference between view-level filtering (presentation) and security-role filtering (data access enforcement).