Tag: PowerApps

Filtered Record Ownership: A New Approach to Row-Level Security (Dataverse / Dynamics 365)


Dataverse has traditionally provided User/Team and Organization ownership. Filtered Record Ownership (Preview) introduces another approach: access can be determined by filter conditions on the data rather than by a record owner.

What is Filtered Record Ownership?

With traditional ownership, we ask: “Who owns this record?” With filtered ownership, we can ask: “Which records should this user be allowed to access?”

For example, a Store table could contain City values such as Auckland, Wellington, and Christchurch. A security filter could grant an Christchurch user access only to records where City = Christchurch.

Conceptually:

Record → Filter → Security Role → User → Access

Microsoft documents filter privileges for Create, Read, Write, Delete, Append, and Append To operations. Filtered ownership tables do not have record owners and therefore cannot use normal Assign or Share operations.

Our Example

We will use a simple custom table called Demo Store (created with Record Ownership = Filtered)

Configuration Steps

1. Create the table

Go to Power Apps → Solutions → New table → Table (advanced properties). Set Record ownership to Filtered (preview), then save the table.

2. Add sample records

Create a few records with different City values. For example: Auckland, Wellington and Christchurch.

3. Create the Record Filter

Create a Record Filter with a FetchXML condition such as City = Christchurch. The Record Filter defines which rows qualify for access. We can use Advanced Find or Fetch XML Builder to generate the FetchXML.

Below we have specified the filter as City = Christchurch.

 4. Create the Entity Record Filter

Create an EntityRecordFilter and associate the Record Filter with the Demo Store table.

5. Configure the Security Role

Grant the required filter privilege, such as Read, to a security role. Select the Entity Record Filter created earlier.

We can see our City Filer for Store along with out of the box All Records filter. Also there is no Assign and Share option as these are not user or team owned.

6. Assign the role

Now let us assign the Filter Security Role to the test user 1.

As expected, we can only have 1 record of Christchurch city showing up for the test user 1 against the System Administrator user, who can see all the records irrespective of city.

If we remove our Filter Security Role from the testu user 1, the user will get the following error message.

A Few Important Points

  • There is no record owner on a filtered ownership table.
  • Records cannot be assigned or shared using the traditional ownership model.
  • Access is controlled through filter privileges and security roles.
  • Access from multiple authorized filters is cumulative.
  • The System Administrator receives the global All records filter.
  • The ownership type cannot be changed after the table is created.
  • Filtered Record Ownership is currently a Preview feature.
  • Every query applies the filter permissions, so filter design can affect performance.

Filtered Ownership vs. Views

A view controls what records are displayed. Filter-based security controls what records the user is allowed to access.

Where Could This Be Useful?

This model is particularly interesting when access is naturally determined by attributes such as:

  • Region or City
  • Department
  • Business Area
  • Classification
  • Other business attributes

Filtered Ownership vs. Existing Tables

Microsoft also supports filter-based security on existing User/Team-owned and Organization-owned tables. In those scenarios, the filters supplement the existing security model. For a Filtered Record Ownership table, filter privileges are the primary mechanism for record access.

Conclusion

Filtered Record Ownership introduces a different way of thinking about Dataverse security. Instead of building access around record ownership, access can be based on the values stored in the record.

It is not a replacement for User/Team ownership. It is another option for scenarios where records do not need an owner and access is better described by business attributes such as location, department or classification.

Because the feature is currently in Preview, it is best evaluated in a non-production environment before considering it for a real solution.

Microsoft References

Hope it helps..

Drawer Lookup Control in Dynamics 365 (A better lookup experience on mobile)


I recently came across a small but useful addition to the Dynamics 365 / Power Apps lookup experience: the Drawer Lookup Control.

With the standard lookup, selecting a value typically opens the familiar lookup experience.

With Drawer Lookup, the records are displayed in a bottom-sheet style drawer, making it easier to search and select a record on a phone or tablet.

This is how it would look on Web –

How to Configure It

The configuration is quite simple. Open the form in Power Apps, select the lookup field, and go to Components.

Select:

  • + Component → Drawer Lookup Control

We can then configure the lookup click-through behavior:

  • Enable lookup clickthrough
  • Disable lookup clickthrough

The control can also be enabled for the Web, Mobile, and Tablet experiences.

This is especially useful when we have forms that are frequently used from mobile devices, and users need to select records from lookup lists like leads, contacts, accounts, work orders etc.

The Disable lookup clickthrough option can also help prevent users from accidentally navigating away from the current form when interacting with a lookup value.

It is a relatively small UI enhancement, but for mobile-heavy Dynamics 365 implementations, these small improvements can make the experience noticeably cleaner. If we have forms that are heavily used on phones or tablets, Drawer Lookup Control is definitely worth trying.

References

Hope it helps..

How to Enable Microsoft 365 Copilot in Model-Driven Apps


Microsoft 365 Copilot brings conversational AI directly into Model-Driven Apps, allowing users to ask natural language questions about Dataverse data, quickly locate records, and improve productivity without leaving the application.

In this post, we walk through the steps we follow to enable Microsoft 365 Copilot in a Model-Driven App, covering the tenant, environment, and application-level configuration required before the feature becomes available.

What We Need Before We Start

  • Microsoft 365 Administrator permissions for tenant-level Copilot settings.
  • Power Platform Administrator access to the target environment.
  • Dataverse Search enabled for the environment (Default or On).
  • Sufficient Dataverse database capacity — Microsoft 365 Copilot for Model-Driven Apps relies on Dataverse Search indexing, and turning it on can increase capacity consumption.
  • Appropriate licensing (covered in Step 4 below).

Step 1: Enable Dataverse Data in Microsoft 365 Copilot (Tenant Level)

Sign in to the Microsoft 365 Admin Center → Copilot → Settings, and locate Dataverse data available in Microsoft 365 Copilot.

Turn it on and choose either All Users or Specific Groups, then Save.

This is a tenant-level setting; it must be enabled before users can access Dataverse data through Microsoft 365 Copilot.

Step 2: Enable Dataverse Search for the Environment

Go to Power Platform Admin Center → Environments → select the environment → Settings → Product → Features, and set Dataverse Search to On, then save.

Dataverse Search is what powers the indexing behind Copilot’s answers, so this has to be on before Copilot can ground its responses in your table data.

Step 3: Verify Dataverse Capacity

Since Microsoft 365 Copilot for Model-Driven Apps relies on Dataverse Search indexing, make sure the environment has enough Dataverse database capacity to support indexing, semantic search, and the Copilot queries themselves. Check this under Power Platform Admin Center → Licensing → Capacity add-on for the environment before rolling this out to a production environment with a large dataset.

Step 4: Verify Licensing

Licensing depends on where the app lives:

  • Power Apps (Custom Model-Driven Apps) — users need a Power Apps Premium license together with a Microsoft 365 Copilot license.
  • Dynamics 365 apps — users need a qualifying Dynamics 365 Enterprise or Premium license. A Microsoft 365 Copilot license is also required to unlock advanced Work IQ capabilities beyond standard Dataverse grounding.

Worth confirming this with your licensing/procurement team before you promise the feature to end users — a missing Microsoft 365 Copilot license is one of the most common reasons Copilot doesn’t show up for a user even after everything else is configured correctly.

Step 5: Enable Microsoft 365 Copilot for the Environment

Go to Power Platform Admin Center → Copilot → Settings. Under Power Apps, expand Copilot in Apps, choose Microsoft 365 Copilot, select the environment (or environment group), select Edit Setting, turn it On, and Save.

Step 6: Enable It for the Model-Driven App

Open the app in the Power Apps Maker Portal → Settings → Features, set M365 Copilot in model-driven apps to On, then Save and Publish the app.

Enable It for All Model-Driven Apps in an Environment

If you’d rather turn this on once instead of app by app, open the Default Solution → Objects → Settings, locate Enable M365 Copilot in model-driven apps, add the value if it doesn’t already exist, set it to 2, Save, and Publish the change.

What Users Will See

Once everything is configured, users can open Copilot → Chat from the top-right corner of the Model-Driven App and start asking natural language questions about Dataverse records.

The current experience is read-only by default: Copilot can find and summarize data, but it can’t make changes on the user’s behalf unless you’ve customized it with an agent. It’s also worth knowing that Microsoft 365 Copilot for Model-Driven Apps isn’t available in the Power Apps mobile app yet.

Microsoft 365 Copilot vs. Copilot Chat: What’s Changing?

If you’ve previously enabled Copilot Chat in Model-Driven Apps, you’ll now see two options in the Copilot menu: Chat and App Skills. This is part of Microsoft’s transition to Microsoft 365 Copilot, which is becoming the standard AI experience across Power Apps and Dynamics 365.

AreaMicrosoft 365 Copilot (Chat)Copilot Chat (App Skills)
StatusRecommended, actively evolvingBeing deprecated
AvailabilityPower Apps and Dynamics 365Preview in Power Apps
Dataverse queriesYesYes
NavigationYesYes
Future directionMicrosoft’s strategic platformTransitioning out

Deprecation Timeline

Microsoft has announced that Copilot Chat in Model-Driven Apps, for Power Apps environments not enabled for Dynamics 365 apps, began its deprecation starting in January 2026. During the transition period, organizations can enable either one or both experiences while users migrate.

What Users Will See During the Transition

  • Chat opens Microsoft 365 Copilot.
  • App Skills opens the legacy Copilot Chat experience.
  • Both experiences can coexist during the transition.

Recommendation

For new implementations, enable Microsoft 365 Copilot rather than investing further in the legacy Copilot Chat experience. Since Microsoft is standardizing AI experiences across Power Apps and Dynamics 365 around Microsoft 365 Copilot, adopting it now saves you a migration later and gives users access to the latest Dataverse-grounded capabilities, including Work IQ where licensed.

Reference Links

Hope it helps..

Advertisements

Why SQL4CDS Record Counts May Not Match Advanced Find for Date Filters (Dataverse / Dynamics 365)


While validating some Dynamics 365 Field Service data recently, we came across an interesting scenario where SQL4CDS and Advanced Find returned different record counts even though the date filters appeared to be identical.

At first glance it was surprising to see different record counts being returned despite using what appeared to be the same date range. After investigating further, we found that the difference was related to time zone handling and the behavior of User Local date fields.

In this post, we’ll walk through the issue, explain why it happens, and show how to get matching results between Advanced Find and SQL4CDS.

The Scenario

We had a user in Auckland, New Zealand running the following Advanced Find query against Work Orders.

Date Window Start

  • On or After 01/01/2026
  • On or Before 02/01/2026

Advanced Find returned:

5,755 records

The generated FetchXML looked like this:


To validate the result, we ran the following query in SQL4CDS:

SELECT COUNT(*)
FROM msdyn_workorder
WHERE msdyn_datewindowstart >= ‘2026-01-01 00:00:00’
  AND msdyn_datewindowstart <= ‘2026-01-02 00:00:00’;

The results were unexpected.

Query MethodTime Zone UsedResult
Advanced Find (Auckland User)Auckland (NZDT)5,755
SQL4CDSUTC Mode3,027
SQL4CDSLocal Mode (India)3,026

At this point, it was clear that Advanced Find and SQL4CDS were evaluating different date boundaries, even though the filters appeared very similar. The next step was to understand why.

Understanding the Date Window Start Field

The key detail was the configuration of the Date Window Start field.

The Date Window Start field is configured as a Date Only field with User Local behavior.

Although users only see a date value, Dataverse stores an underlying UTC datetime value and performs time zone conversion based on the user’s personal settings.

To better understand what was happening, we queried some of the underlying values directly.

SELECT msdyn_workorderid,
       msdyn_datewindowstart
FROM msdyn_workorder
WHERE msdyn_datewindowstart >= ‘2026-01-01 00:00:00’
  AND msdyn_datewindowstart <= ‘2026-01-02 00:00:00’;

When running SQL4CDS in UTC mode, many records had values such as:

2026-01-01 11:00:00

This initially looked unusual because users only see a date value in the application.

However, the explanation becomes clear when we consider the Auckland user’s time zone.

In January, Auckland operates on New Zealand Daylight Time (NZDT), which is UTC+13.

For a User Local Date Only field, Dataverse converts the user’s local date into UTC before storing it.

Date Seen by Auckland UserStored UTC Value
01-Jan-202631-Dec-2025 11:00 UTC
02-Jan-202601-Jan-2026 11:00 UTC
03-Jan-202602-Jan-2026 11:00 UTC

This explains why so many records appear with a value of 11:00 UTC when viewed in SQL4CDS running in UTC mode.

Why Advanced Find Returned More Records

When the Auckland user enters:

01/01/2026
to
02/01/2026

Advanced Find interprets those dates using the user’s personal time zone.

The actual UTC boundaries become:

>= 2025-12-31 11:00:00 UTC
<  2026-01-02 11:00:00 UTC

This represents two complete calendar days for the Auckland user.

Our original SQL4CDS query was searching a different range entirely:

>= 2026-01-01 00:00:00 UTC
<= 2026-01-02 00:00:00 UTC

Although the dates appear similar, the actual UTC boundaries are very different.

Finding the Correct SQL4CDS Query in UTC Mode

To reproduce the Advanced Find results, we converted the Auckland user’s date range into UTC and updated the SQL4CDS query accordingly.

SELECT COUNT(*)
FROM msdyn_workorder
WHERE msdyn_datewindowstart >= ‘2025-12-31 11:00:00’
  AND msdyn_datewindowstart <  ‘2026-01-02 11:00:00’;

This returned:

5,755 records

which matched Advanced Find exactly.

What If SQL4CDS Is Running in Local Mode?

The example above used SQL4CDS running in UTC mode. However, SQL4CDS can also be configured to use Local Time mode.

In our scenario, SQL4CDS was running on a machine configured for India Standard Time (IST), which is UTC+5:30.

To match the Advanced Find results in Local Mode, we need to convert the Auckland UTC boundaries into the local time zone used by SQL4CDS.

Earlier we determined that the Auckland user’s date range:

01-Jan-2026 to 02-Jan-2026

corresponds to the following UTC boundaries:

31-Dec-2025 11:00 UTC
to
02-Jan-2026 11:00 UTC

When SQL4CDS is running in Local Mode on an India machine, those UTC values need to be converted to IST.

UTC BoundaryIST Boundary
31-Dec-2025 11:00 UTC31-Dec-2025 16:30 IST
02-Jan-2026 11:00 UTC02-Jan-2026 16:30 IST

The equivalent SQL4CDS query becomes:

SELECT COUNT(*)
FROM msdyn_workorder
WHERE msdyn_datewindowstart >= ‘2025-12-31 16:30:00’
  AND msdyn_datewindowstart <  ‘2026-01-02 16:30:00’;

This query also returned:

5,755 records

matching Advanced Find exactly.

The results can now be summarized as follows:

Validation MethodQuery BoundaryResult
Advanced Find (Auckland User)User Time Zone5,755
SQL4CDS UTC Mode31-Dec-2025 11:00 UTC → 02-Jan-2026 11:00 UTC5,755
SQL4CDS Local Mode (India)31-Dec-2025 16:30 IST → 02-Jan-2026 16:30 IST5,755

References

For a deeper understanding of how SQL4CDS handles date and time values, I highly recommend Mark Carrington’s article:

https://markcarrington.dev/2021/05/21/date-time-handling-in-sql-4-cds

This article explains how SQL4CDS interprets date and time values in both UTC and Local Time modes and was a useful reference while investigating this scenario.

Key Takeaways

The investigation highlighted that there may be three different time zones involved when validating results:

  • The Dataverse user’s personal time zone used by Advanced Find.
  • The SQL4CDS Local Time setting.
  • UTC when SQL4CDS is configured to use UTC mode.

Even when the same date values are entered, the actual UTC range being queried may be different.

For the most reliable comparison:

  1. Identify the time zone of the user who ran Advanced Find.
  2. Convert the date boundaries to UTC.
  3. Run SQL4CDS in UTC mode.
  4. Use explicit UTC values in your query.

We also recommend using an exclusive upper boundary:

WHERE Field >= StartBoundaryUTC
  AND Field < EndBoundaryUTC

instead of:

WHERE Field <= EndOfDay

This avoids potential issues with milliseconds and provides more predictable results.

SQL4CDS can match Advanced Find in either UTC Mode or Local Mode. The important requirement is that the date boundaries represent the same moment in time. We generally prefer UTC Mode because the query behaves consistently regardless of the machine or user executing it.

Hope it helps..

Advertisements

Finding Dirty / Unsaved Fields on the Form Using JavaScript / Browser Console (Dynamics 365 / Dataverse)


Sometimes while debugging forms in Dynamics 365, we need to know which fields have been modified but not yet saved. These are called dirty fields, and they can be quickly identified by running a small JavaScript snippet directly from the browser console.

We can open the form, press F12 to bring up the developer tools, go to the Console tab, and paste the following code

(function () {
    var dirtyFields = [];
    var attributes = Xrm.Page.data.entity.attributes.get();

    attributes.forEach(function (attribute) {
        if (attribute.getIsDirty()) {
            dirtyFields.push(attribute.getName());
        }
    });

    if (dirtyFields.length) {
        alert("Dirty fields: " + dirtyFields.join(", "));
    } else {
        alert("No dirty fields found.");
    }
})();

This script loops through all the attributes on the form and checks if they are dirty using getIsDirty(). If it finds any, it shows their names in an alert, otherwise it shows a message saying no dirty fields are found.

For example, if we modify First Name and Email on the Contact form without saving, it will pop up an alert showing:

A screenshot of a computer AI-generated content may be incorrect.

Here we are using Xrm.Page even though it is deprecated, because it is still the quickest way to test such snippets directly from the console for debugging purposes. In actual form scripts, we should always use formContext.

Hope it helps..

Advertisements

Use Security Roles to manage access to views (preview)– Dataverse / Dynamics 365


Sometimes, we might create a new view for a table, and not everyone in our organization needs to see it — or maybe, only a specific team should have access to the existing views, now we can achieve it through security roles.

This feature is governed by the EnableRoleBasedSystemViews property, which we can manage through the OrganizationSettingsEditor tool.

Download and install the managed solution.

https://github.com/seanmcne/OrgDbOrgSettings/releases

A black background with white lines AI-generated content may be incorrect.

Before we set the property as true, let us apply security roles to some of our views.

To apply it, select the view in the PowerApps Maker Portal and click on View Settings.

A screenshot of a computer AI-generated content may be incorrect.

From the View Settings window, we can choose Specific security roles to apply to the views. Here we have selected the Vice President of Sales role for the All Leads Views. Save and publish the change.

A screenshot of a computer AI-generated content may be incorrect.

Here we have repeated the same steps for the below remaining views.

A screenshot of a computer AI-generated content may be incorrect.

Now if we open the leads view as System Admin, we can see all the views. This is because we have not yet set the EnableRoleBasedSystemViews to true.

Now let us set the property as true.

A screenshot of a computer AI-generated content may be incorrect.

As soon as we set the property as true, we can see the views getting filtered for the System Admin user.

Only the below public view is visible. (along with the 2 private views at the top)

A screenshot of a computer AI-generated content may be incorrect.

Now if we assign the “Vice President of Sales” role to the same user, he can then see the views on which security roles were applied.

A screenshot of a computer AI-generated content may be incorrect.

The user can still see the remaining views through the “Manage and share views” option.

A screenshot of a computer AI-generated content may be incorrect.
A screenshot of a computer AI-generated content may be incorrect.

The records that the user can see in the views are still governed by security privileges.

Although the documentation mentions, that this feature only filters views in the table list view selector and not in associated grids or subgrids, we can see the same filtering applied.

Below is the Lead Associated view in the Competitor table.

When we enable the EnableRoleBasedSystemViews setting using the OrganizationSettingsEditor tool, it takes effect immediately. All table views, except the default one, start getting filtered based on assigned security roles right away. Assigning security roles to a view is also effective immediately after we save and publish the view. However, if we change a view’s access from ‘Specify security roles’ to ‘Everyone’, it might take up to 24 hours for the change to fully apply across the system.

Get all the details here – Manage access to public system views (preview)

Hope it helps..

Advertisements