4.3 View Configuration, System Views, Personal Views & Filters

4.3 View Configuration, System Views, Personal Views & Filters

In Microsoft Dataverse, Views define how sets of records for a specific table are queried, structured, filtered, sorted, and displayed. Rather than writing raw SQL queries or building bespoke table components, customizers and end users leverage Dataverse views to present data consistently across entity home grids, subgrids, lookup search modals, and interactive dashboards.

For a functional consultant preparing for the PL-200 exam, understanding the architectural classifications of views, configuring the five special-purpose System Views, mastering the Modern View Designer, and constructing advanced FetchXML filter conditions are essential skills.

---

1. Architectural View Classifications: Public, System & Personal Views

In Dataverse, views are stored as structured query definitions in two distinct database tables: savedquery (for System and Public Views) and userquery (for Personal Views).

+-----------------------------------------------------------------------------------+
|                         DATAVERSE VIEW TAXONOMY                                   |
|                                                                                   |
|   +---------------------------------------------------------------------------+   |
|   | 1. PUBLIC VIEWS (Stored in `savedquery` table)                            |   |
|   |    - General-purpose shared views accessible to all users in an app       |   |
|   |    - Solution-aware; authored in Maker Portal and deployed via ALM        |   |
|   |    - Examples: 'Active Accounts', 'My Open Opportunities', 'Inactive Leads'|   |
|   +---------------------------------------------------------------------------+   |
|   | 2. SYSTEM VIEWS (Special-Purpose Platform Views in `savedquery`)          |   |
|   |    - Built-in views required for core platform behavior                   |   |
|   |    - Cannot be deleted; customized to tailor lookup and search behavior   |   |
|   |    - [Default Public]  [Quick Find]  [Lookup]  [Associated]  [Adv Find]   |   |
|   +---------------------------------------------------------------------------+   |
|   | 3. PERSONAL VIEWS (Stored in `userquery` table)                           |   |
|   |    - Created by individual end users using 'Edit filters' / 'Save as View'|   |
|   |    - Stored in user space; not solution-aware                             |   |
|   |    - Can be explicitly Shared or Assigned to other Users / Teams          |   |
|   +---------------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------------+

In-Depth View Classification Comparison

---

2. The 5 Special-Purpose System Views

Every standard and custom table in Dataverse is automatically provisioned with five specialized System Views that power platform-level interactions:

+-----------------------------------------------------------------------------------+
|                      THE 5 SPECIAL-PURPOSE SYSTEM VIEWS                           |
|                                                                                   |
|   1. DEFAULT PUBLIC VIEW  ====> Primary landing grid when user opens entity       |
|   2. QUICK FIND VIEW      ====> Powers grid search box: Find Columns & View Cols  |
|   3. LOOKUP VIEW          ====> Layout displayed in lookup search dropdown/modal  |
|   4. ASSOCIATED VIEW      ====> Rendered when viewing records via 'Related' nav   |
|   5. ADVANCED FIND VIEW   ====> Default template loaded during ad-hoc querying    |
+-----------------------------------------------------------------------------------+

Detailed Analysis of Special System Views

1. Default Public View:

   • The primary view displayed when a user navigates to an entity home page via the Site Map.
   • Any Public View can be promoted to become the Default Public View via the Maker Portal. Only one view per table can serve as the default.

2. Quick Find View (Search Engine):

   • Powers the search box located in the upper-right corner of the entity grid.
   • Contains two distinct column configuration sets:
     • Find Columns (Indexed Attributes): The specific columns evaluated when a user types a search term (e.g., searching by Account Name, Account Number, or City). Adding too many text columns to Find Columns can degrade search performance.
     • View Columns (Display Attributes): The columns rendered in the search results grid when matching records are returned.
   • Quick Find filter criteria define the baseline query filter (e.g., only searching across statecode = Active).

3. Lookup View:

   • Defines the columns and sorting order displayed when a user clicks on a Lookup field search modal or dropdown on a form.
   • Typically configured to display primary identifier columns (e.g., Full Name, Email, Company) to help users disambiguate between records with similar names.

4. Associated View:

   • Rendered when a user opens a parent record, clicks the Related tab in the form navigation, and selects a 1:N related table.
   • Optimized to show related context without duplicating parent identifiers.

5. Advanced Find View:

   • Serves as the default base template when users open Advanced Find or export data queries.

---

3. Modern View Designer & Column Configuration

The Modern View Designer in the Power Apps Maker Portal (make.powerapps.com) provides a visual WYSIWYG environment for customizing view columns, sorting, and widths.

+-----------------------------------------------------------------------------------+
|                    MODERN VIEW DESIGNER ARCHITECTURE                              |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | VIEW: Active Accounts | Filter: Status = Active | Sort: Created On (Desc)   |  |
|  +-----------------------------------------------------------------------------+  |
|  | [Account Name ^] | [Primary Contact] | [Email (Contact)]* | [Annual Revenue] |  |
|  | (Width: 200px)   | (Width: 150px)    | (Width: 180px)     | (Width: 120px)   |  |
|  |------------------+-------------------+--------------------+------------------|  |
|  | Contoso Ltd      | John Doe          | john@contoso.com   | $1,500,000       |  |
|  | Fabrikam Inc     | Jane Smith        | jane@fabrikam.com  | $4,200,000       |  |
|  +-----------------------------------------------------------------------------+  |
|  * Email (Contact) is a RELATED COLUMN added via 1:N / N:1 Table Traversal!       |
+-----------------------------------------------------------------------------------+

Key View Configuration Capabilities

• Adding Related Table Columns: Customizers can add columns not only from the primary table but also from any table linked via an N:1 Lookup Relationship (e.g., displaying the Parent Account's Credit Limit directly on a Contact view).
• Column Width Configuration: Column widths can be specified in exact pixels (e.g., 150px) or adjusted visually by dragging column borders.
• Multi-Level Sorting: Views support primary and secondary sorting criteria (e.g., sort primarily by City Ascending, then secondarily by Annual Revenue Descending).
• App-Level View Selection: Inside the Modern App Designer, makers can selectively include specific public views in a model-driven app while excluding others, ensuring users are not overwhelmed by unnecessary views.

---

4. Filter Criteria & FetchXML Logic

Every view in Dataverse is powered by a FetchXML query that encapsulates the filtering criteria and table joins.

+-----------------------------------------------------------------------------------+
|                       FETCHXML QUERY FILTER LOGIC                                 |
|                                                                                   |
|   LOGICAL OPERATOR: [AND]                                                         |
|     +---> Condition 1: Status Equals 'Active'                                     |
|     +---> Condition 2: Annual Revenue Is Greater Than '$1,000,000'               |
|     +---> LOGICAL OPERATOR: [OR] (Nested Group)                                   |
|             +---> Sub-Condition A: Address 1: City Equals 'Seattle'               |
|             +---> Sub-Condition B: Address 1: City Equals 'Portland'              |
|                                                                                   |
|   RELATED TABLE FILTER (Link-Entity Join):                                        |
|     +---> Related Table (Contact): Contains Data                                  |
|             +---> Contact Status Equals 'Active'                                  |
+-----------------------------------------------------------------------------------+

Modern Edit Filters Panel Capabilities

• Standard Comparison Operators: Equals, Does Not Equal, Contains, Does Not Contain, Begins With, Contains Data (not null), Does Not Contain Data (null).
• Date & Time Relative Operators: Today, Yesterday, This Week, Last Month, Older Than X Days, Next X Months.
• Grouping Conditions (AND vs OR): Makers can select multiple conditions and group them using AND (all conditions must evaluate to true) or OR (any single condition evaluates to true).
• Hierarchical & Relationship Joins: Querying across relationships using "Under" / "Not Under" (for self-referencing hierarchies) or filtering based on attributes in related 1:N or N:1 tables.

---

5. Personal View Lifecycle: Creation, Sharing, Assigning & Pinning

End users can create personalized views to track their daily work without requiring administrator intervention.

+-----------------------------------------------------------------------------------+
|                     PERSONAL VIEW LIFECYCLE MANAGEMENT                            |
|                                                                                   |
|   1. CREATE: User opens Public View -> Clicks 'Edit filters' -> Adds criteria     |
|              Clicks 'Save as new view' -> Names it 'My High Priority Leads'       |
|                                                                                   |
|   2. PIN:    User clicks View Selector -> Clicks Pin icon next to personal view   |
|              View becomes the user's personal default landing view!               |
|                                                                                   |
|   3. SHARE:  User clicks 'Manage and share views' -> Selects 'Share'              |
|              Grants Read/Write permissions to 'Sales Team' Owner Team             |
|                                                                                   |
|   4. ASSIGN: User transfers complete ownership of the view to another manager   |
+-----------------------------------------------------------------------------------+

Personal View Governance Rules

1. Sharing Personal Views:
   • The owner of a personal view can share it with individual users or teams.
   • Granular permissions can be granted during sharing: Read, Write, Delete, Assign, and Share.
   • If a personal view is shared with an Entra ID Group Team or Owner Team, all team members immediately gain access to the view in their view selector.
2. Assigning Personal Views:
   • Assigning a personal view permanently transfers ownership (ownerid in userquery) to the recipient user or team. The original creator loses administrative control unless granted access by the new owner.
3. Pinning Views:
   • Any user can pin any Public or Personal view as their personal default view. This preference is stored per user and does not alter the system-wide Default Public View for other users.