Dataverse Form Security For Model Driven Apps

In this training session, Matt Peterson from Pragmatic Works explains how to implement form security within model-driven applications using Dataverse. This feature is essential when different users require different form views and levels of control within the same application.

Why Form Security Matters

Model-driven apps often serve multiple user groups with different roles. For example:

• Intake users may need a simple read-only form for initial data submission.
• Administrators may need full edit rights to review and update records.

Without proper form security, users may gain access to forms or functions they should not use, leading to errors, inconsistencies, or data breaches.

Building Separate Forms

Matt demonstrates this by creating a student enrollment application. The process begins with two distinct forms:

1. Intake Information Form: Default status is set to “Submitted,” with the enrollment status field locked as read-only.
2. Admin Board Information Form: Created as a copy of the first form, but with the enrollment status made editable.

This allows intake users to submit applications while administrators can manage and update them.

Creating Security Roles

Next, Matt explains how to create and assign security roles in Dataverse solutions. Security roles define what users can see and do with tables and forms:

• Initial Intake Role: Users can only see and edit the records they create.
• Admin Role: Users can view, edit, and manage all records across the organization.
• Basic User Role: A standard Dataverse role that ensures access to core data like contacts.

Sharing the Application

Once roles are created, the application is shared with users. When a user logs in, their assigned role determines which forms they see:

• A user assigned the Intake Role will only see the Intake Information Form.
• A user assigned the Admin Role will be able to see the Admin Board Information Form.

However, Matt highlights a common issue: the default form behavior may override security expectations.

Default Form Behavior Explained

An important discovery Matt shares is how default form settings work:

• Main forms are visible to all users by default, regardless of roles.
• Copied forms (using “Save As”) are restricted to specific roles until updated.

This means that unless specific roles are explicitly assigned to a copied form, no user will see it—even if they have the correct role in the app.

Configuring Form Security Rules

To fix this, administrators must:

1. Open the form in the solution editor.
2. Go to Form Settings → Security Roles.
3. Select which security roles are allowed to access the form.
4. Save and publish the changes.

Once roles are linked to the correct forms, users will see only the forms they are authorized for. For example, when Lab Admin 12 was assigned both roles, refreshing the app displayed both the Intake and Admin forms.

Key Takeaways

• Create separate forms for different user groups to control data access.
• Set up distinct security roles to define privileges at the table and record level.
• Understand that default forms are visible to all, while copied forms require explicit role assignments.
• Always configure form security under Form Settings to ensure correct access control.

By following these steps, organizations can streamline their model-driven applications, ensuring users only see and interact with forms relevant to their role. This not only improves security but also simplifies the user experience.

Matt Peterson’s walkthrough provides a clear, practical guide for anyone managing Dataverse form security. Whether handling student enrollments or other business processes, understanding form security is critical to keeping applications efficient and secure.
Don't forget to check out the Pragmatic Works' on-demand learning platform for more insightful content and training sessions on Model Driven Apps and other Microsoft applications. Be sure to subscribe to the Pragmatic Works YouTube channel to stay up-to-date on the latest tips and tricks.