Mastering User Experience: Form and View Types in Dataverse

Introduction: The Foundation of Data Interaction

When we talk about building applications on the Microsoft Power Platform, we are essentially building interfaces for data stored in Dataverse. While the back-end architecture—tables, relationships, and business logic—is the engine of your application, the user experience (UX) is the steering wheel and dashboard. If the interface is confusing, cluttered, or inefficient, users will struggle to input data accurately, leading to poor data quality and low adoption rates.

In Model-Driven Apps, the primary tools we use to manage this interface are Forms and Views. Forms are where users create, read, and edit individual records. Views are where users see lists of records, filter them, and perform bulk actions. Understanding the nuance of different form and view types is not just a technical requirement; it is a fundamental skill for anyone designing effective business solutions. This lesson will guide you through the intricacies of these components, ensuring you can design interfaces that are intuitive, performant, and tailored to specific user roles.

Part 1: Deconstructing Form Types in Dataverse

Forms in Dataverse are not "one size fits all." Because a salesperson needs different information than a customer service representative, and a mobile user needs a different layout than a desktop user, Dataverse provides specific form types to handle these diverse requirements.

The Main Form

The Main form is the primary interface for users interacting with records. It is the most flexible form type, supporting the full range of controls, subgrids, business rules, and client-side scripting. When you open a record in a Model-Driven App, you are almost certainly looking at a Main form.

• Customization: You can add tabs, sections, and columns. You can also embed web resources, iframes, and specialized controls like the Timeline or the Business Process Flow (BPF).
• Security: You can assign specific Main forms to security roles. For instance, you can create a "Finance" form for the Accounting team and a "Sales" form for the Sales team.
• Performance: Because these forms can become complex, it is important to avoid over-loading them with too many subgrids or heavy scripts, as this will increase page load times.

The Quick Create Form

Quick Create forms are designed for speed. They allow users to create a new record without navigating away from their current page. You will often see these when clicking the "+" button in the top navigation bar of a Model-Driven App.

• Use Case: These are ideal for scenarios where you need to enter minimal data to get a record into the system quickly, such as "Quick Add Lead" or "Log New Task."
• Limitations: Quick Create forms do not support complex features like subgrids, web resources, or business process flows. They are meant to be light and fast.

The Quick View Form

Quick View forms are read-only components that you embed into other forms. They allow you to pull data from a related record and display it on the current record's form.

• Scenario: Imagine you are on a "Case" record. You want to see the contact's phone number and email address without opening the "Contact" record. By adding a Quick View form for the Contact entity onto the Case form, you display that related information right there.
• Behavior: These forms update automatically when the lookup field they are linked to changes.

The Card Form

Card forms were designed specifically for mobile and tablet interfaces. They provide a concise, readable view of record information in a list format on smaller screens.

• Design: They are limited in terms of space, so you should only include the most critical information, such as a title, a status indicator, and a primary date or value.
• Usage: These appear when a user views a list of records on the Power Apps mobile app.

Callout: Form Types at a Glance

Form Type	Primary Purpose	Best For
Main	Full record interaction	Data entry, editing, complex logic
Quick Create	Fast, minimal data entry	Creating records without leaving the context
Quick View	Read-only reference	Viewing details of a related record
Card	Mobile/Tablet list display	Compact summaries on mobile devices

Part 2: Working with Views: Data Exploration and Organization

Views are the windows through which users see the data in your database. A well-configured view can make the difference between a user finding what they need in seconds or spending minutes scrolling through irrelevant records.

System Views

System views are created by administrators and are available to all users who have access to the table. They are the backbone of the application's navigation.

• Default View: This is the view that appears when a user clicks on an entity in the sitemap.
• Personal Views: Users can create their own personal views based on system views. These are private by default but can be shared with others.
• Public Views: These are the standard views provided by the system or created by admins (e.g., "Active Accounts," "Inactive Contacts").

The View Designer

When you build a view, you are essentially defining the columns (the data points) and the filter criteria (the logic).

1. Columns: Select only the columns necessary for the user to identify the record. Too many columns create horizontal scrolling, which is a major UX friction point.
2. Sort Order: Always define a default sort order. Sorting by "Created On" (newest first) or "Name" (alphabetical) is usually standard practice.
3. Filter Criteria: This is where you determine which records appear in the list. Use "Active" statuses to keep the view clean by default.

Advanced Find and Filter Logic

Users often need to manipulate views on the fly. The "Advanced Filter" (formerly Advanced Find) feature allows users to build complex queries using "AND/OR" logic without needing to understand SQL or database structures.

Note: Always enable the "Allow users to edit filters" option in your view configurations. This empowers users to customize their own data analysis without requiring you to build dozens of static, hard-coded views.

Part 3: Implementing Best Practices for User Experience

Designing for Dataverse requires a shift in mindset. You are not just organizing fields; you are mapping out a business process. Here are the industry standards for keeping your forms and views clean and effective.

Form Design Best Practices

1. Keep it Simple: If a form has more than 30-40 fields, it is likely too complex. Consider using multiple tabs to group related information.
2. Use Sections Wisely: Sections allow you to organize fields into logical groupings (e.g., "Contact Information," "Financial Details," "Internal Notes").
3. Mandatory Fields: Only mark fields as "Business Required" if they are absolutely essential for the business process. Over-using required fields leads to users entering "N/A" or garbage data just to save the form.
4. Field Labels: Use clear, human-readable labels. Avoid technical jargon or abbreviations that might confuse a new employee.

View Design Best Practices

1. Limit Columns: Stick to 5-8 columns maximum. If a user needs to see more, they should open the record.
2. Use Meaningful Names: Instead of "View 1," name your views clearly, such as "High-Priority Open Cases" or "Accounts Created This Month."
3. Consistent Sorting: Ensure that views are sorted in a way that makes sense for the business. A list of sales opportunities should probably be sorted by "Estimated Close Date" rather than by "Name."

Part 4: Practical Implementation: A Step-by-Step Guide

Let us walk through creating a custom form for a "Project" table.

Step 1: Create the Main Form

1. Navigate to make.powerapps.com and open your Solution.
2. Locate your "Project" table and select Forms.
3. Click New Form and select Main Form.
4. Use the drag-and-drop editor to add a tab named "General Information."
5. Add two columns to this section: "Project Name" and "Start Date."
6. Add a second tab named "Financials" and add the "Budget" and "Actual Cost" fields there.
7. Save and Publish.

Step 2: Configure a Quick View Form

1. In the same "Project" table, click New Form and select Quick View Form.
2. Add a section and include the "Project Manager" lookup field.
3. Add the "Manager Email" and "Manager Phone" fields from the related User record.
4. Save and Publish. Now, when you are on a "Task" record that is linked to a "Project," you can drop this Quick View form onto the Task form to see the Manager's details instantly.

Step 3: Create a Custom View

1. Under the "Project" table, select Views.
2. Click New View. Name it "Upcoming Projects."
3. In the filter criteria, set "Start Date" to "Next 30 Days."
4. Add columns: "Project Name," "Start Date," and "Project Status."
5. Set the sort order to "Start Date" (Ascending).
6. Save and Publish.

Part 5: Common Pitfalls and How to Avoid Them

Even experienced developers fall into traps when designing forms and views. Here are the most frequent mistakes and how to steer clear of them.

Pitfall 1: The "Kitchen Sink" Form

Developers often try to put every single field on the Main form because they are afraid the user might need one of them. This creates a cluttered, overwhelming interface.

• Solution: Use Tabs and Sections to hide complexity. Better yet, use Business Rules to show or hide fields based on the context of the record.

Pitfall 2: Ignoring Mobile Users

A form that looks great on a 27-inch monitor might be unusable on a smartphone.

• Solution: Always test your forms on the Power Apps mobile app. Ensure that the fields most needed by field staff are at the top of the form. Use Card Forms to ensure lists are readable on small screens.

Pitfall 3: Not Using Security Roles

Providing access to every form to every user is a security risk and a UX disaster. A clerk does not need to see the "Profit Margin" fields that a manager needs.

• Solution: Assign specific forms to specific security roles. This keeps the interface clean for each user group.

Pitfall 4: Performance Bottlenecks

Adding too many subgrids or web resources to a single form will slow down the load time significantly.

• Solution: Only include essential data on the primary form. If you have "nice to have" data, move it to a secondary tab so it only loads if the user specifically clicks on that tab.

Warning: Never use JavaScript to manipulate the DOM (Document Object Model) directly. This is a common practice in web development but is strictly unsupported in Dataverse and will likely break when Microsoft updates the platform. Always use the formContext API for client-side scripting.

Part 6: Advanced: Client-Side Scripting

Sometimes, standard configuration isn't enough. You may need to change a field's visibility or value dynamically. Here is a simple example using the formContext API.

// Example: Hide the "Discount" field if the "Project Type" is "Internal"
function filterDiscountField(executionContext) {
    var formContext = executionContext.getFormContext();
    var projectType = formContext.getAttribute("new_projecttype").getValue();

    // 1 = Internal, 2 = External
    if (projectType === 1) {
        formContext.getControl("new_discount").setVisible(false);
    } else {
        formContext.getControl("new_discount").setVisible(true);
    }
}

Explanation:

• executionContext is passed automatically by the form event.
• getFormContext() gives us access to the form's data and controls.
• getAttribute retrieves the value of the field.
• getControl allows us to modify the UI element (in this case, hiding it).

Part 7: Comparison of View Options

When building views, you have several choices. Understanding the difference is key to providing the right data at the right time.

• Subgrid View: This is the view you see inside a form when looking at related records (e.g., all Contacts associated with an Account). You should create a specific, slimmed-down view for these to ensure the form remains responsive.
• Lookup View: This is what appears when a user clicks the search icon on a lookup field. Keep these views very simple—usually just the name of the record and perhaps one identifying column (like an ID number or email).

Part 8: Accessibility and Inclusion

Accessibility is not an afterthought; it is a core requirement of modern software design. When you design your forms and views, ensure they are usable by everyone.

• Color Contrast: Avoid using colors that make text hard to read. Use the default styling provided by Microsoft as much as possible.
• Keyboard Navigation: Ensure your form tab order is logical. Users should be able to move through the form fields using the "Tab" key in the order that data is typically entered.
• Screen Readers: Always provide descriptive labels for fields. A field labeled "Date" is less helpful than a field labeled "Project Start Date."

Summary and Key Takeaways

Mastering forms and views is the most direct way to impact user satisfaction in your Dataverse applications. By moving away from "everything everywhere" designs and moving toward structured, role-based, and performant interfaces, you enable your users to work faster and with fewer errors.

Key Takeaways:

1. Select the Right Form Type: Use Main forms for detailed work, Quick Create for rapid entry, and Quick View for read-only reference.
2. Prioritize Clarity: Limit the number of fields on a form and the number of columns in a view to prevent cognitive overload.
3. Leverage Security Roles: Assign forms based on job functions to ensure users only see the data and controls relevant to their role.
4. Optimize for Performance: Avoid overloading forms with too many subgrids or heavy scripts; if a feature isn't essential, move it to a secondary tab.
5. Empower Users with Views: Always allow users to edit filters on their views, and provide them with well-named, pre-configured system views to save them time.
6. Test for Mobile: A form that works on a desktop might be a nightmare on a phone; always verify your layout on mobile devices using Card forms.
7. Follow Standards: Use official Microsoft APIs (formContext) for scripting and avoid unsupported DOM manipulation to ensure your app remains stable through platform updates.

By applying these principles, you will transition from simply "building apps" to "designing solutions" that users actually enjoy using. Remember that the best interface is the one that gets out of the way, allowing the user to complete their task as quickly and accurately as possible.