Tutorial

Power Apps Code Apps in Practice: Recreating Model-Driven App Patterns

Axel — Wed, 11 Mar 2026 14:56:40 +0000

Power Apps Code Apps in Practice: Recreating Model-Driven App Patterns Axel Wed, 03/11/2026 - 15:56

Body

Power Apps Code Apps went from preview to general availability in record time. With that, Microsoft has sent a clear signal that it is taking this technology very seriously.

In fact, Code Apps are something of a small revolution. They allow pro-code developers to deliver custom web apps directly within a Dataverse environment without the need to implement authentication libraries.

But that is not all: Low-code developers can benefit from them as well. With tools like GitHub Copilot and Claude Code, you no longer necessarily need to understand a programming language such as React in order to build full-blown web application. Instead, you can simply describe the features you want in a prompt and have them implemented.

This will fundamentally change the way how apps will be implemented in the future. React Fluent UI components can be integrated into Code Apps and open up entirely new possibilities for designing user interfaces such as accordions, cards or TreeViews.

Motivation

There is, however, one important point to consider: At the time of writing, Power Apps Code Apps are stand-alone apps. That means they are not integrated into a model-driven app, but exist as independent applications, similar to canvas apps. There is also no custom page in a model-driven app to represent a code app.

But what if you still need the typical built-in functionality of a model-driven app upfront, such as filtering records in a data grid? One option would be to add a button to the model-driven app or try to integrate the app through an iframe.

This article explores another approach: recreating typical model-driven app functionality directly inside the custom app. The goal is to assess how much effort this requires and how quickly something like this can be implemented, not to reinvent the wheel, but to demonstrate the capabilities and the power of Code Apps. And of course also to show that, for many use cases, you no longer need a model-driven app as the entry point.

PoC: Table Browser App

The goal was to build an new code app "Table Browser" from scratch which demonstrates that a standalone Power Apps Code App can reproduce familiar Model-Driven-App-style functionality, such as filtered and searchable record lists with the same look and feel like Model-Driven-Apps. This can serve as an entry point and opens the door to building a fully fledged standalone app with a much richer user experience, including features such as tree views and other advanced interface patterns that are difficult to realize in a traditional Model-Driven App.

It is also a proof of concept: each feature was chosen to answer a specific question about what Code Apps can do. A secondary goal was to evaluate these two tools in a real-world scenario and gain hands-on experience with AI-assisted development.

The entire app was built in a single Saturday — using both GitHub Copilot and Claude Code as AI coding assistants. Fun fact: Claude Code estimated the development effort for the entire app at 12 to 15 days if implemented by a senior developer without the help of AI.

Proof Points

Performance: Can a Code App render large Dataverse record sets noticeably faster than a Model-Driven grid? Yes.
Infinite scroll: How much code does it take to implement demand-driven pagination? Very little — a scroll event plus a getAll call with top and skip.
Metadata access: How easy is it to read column metadata at runtime? One SDK call to retrieveMultipleRecordsAsync on EntityDefinition gives you full attribute detail.
View definitions: Can a Code App read the default system view and use it to determine which columns to show? Yes — savedquery records expose the column layout as XML, which the app parses to build its default column set.
Form definitions: Can a Code App reconstruct the default form layout — tabs, sections, fields — without hardcoding it? Yes — systemform records contain the full form structure as JSON and XML, which the app uses to render the record detail dialog.
Column persistence: Can user preferences be stored in Dataverse instead of localStorage — cross-device, without a custom table? Yes, via personal views (userquery).

Key capabilities

Browse records from multiple Dataverse tables with infinite scroll and client-side search
Inspect column metadata and field properties (schema view)
Customize visible columns per table — persisted as personal views (userquery records) in Dataverse
View full record details in a form-based dialog with tabs and sections
Switch between list (DataGrid) and card grid layouts
Light/dark mode, display density, and accent color theming (persisted to localStorage)

UI Features

The goal was to implement the same look and feel that we know from Model-Driven-App. This can easily be achieved by using the React Fluent UI components library. The following chapters show which features have been implemented.

List View

The app uses the metadata to look for the default view of the table and shows all columns defined there.
Columns width can be changed by drag and drop.
Columns can be sorted. If sorted, an api call is used for server side sorting
Smooth paging: Scrolling to the end of the list reloads the next page of data (e.g. the next 50 records)

Search and highlighting

Search was implemented with a single field which searches in all text fields
- This was easier to implement
- A filter below every column, as in model driven apps could be another option for the future.
Highlighting the matched text was very easy to implement, so this functionality was added as well, even though it does not exist in model-driven apps

Column selection and reordering

A modal dialog window can be used to select the columns to display
A drag and drop component can be used to reorder the columns. The @dnd-kit/sortable library was used to implement this feature
The adjusted view is updated in the Dataverse personal view

Card View

A Card View as an alternative to a List View was implemented
This was quite easy because a card already exists as a UI component in the React UI Components
This view is especially useful for data with images

Detail View Edit Dialog

A detailed review was implemented to show and edit the current record
The code dynamically parses the system form record to create the layout dynamically from the defaults form definition (including tabs)
Field types text, text area, option set, lookup, yes/no, date/time are supported and fully working
Of course, the form doesn't support PCF or sub grids.
An alternative approach approach for the future, could be to redirect to a detail view, like a Model-Driven-App does

Table Column Definitions

A column meta data list was implemented
It automatically shows all columns of the table with display name, data type, required, and description
It proves that metadata can easily be fetched by the @microsoft/power-apps/data lib (for code apps)
The column metadata can also be filtered
The screenshot shows the list in dark mode. Of course, dark mode is available for the whole application.

Settings dialog

A small settings dialog was implemented for the settings of dark mode, display density, and accent color
This was very easy to implement since dark mode, accent color and density are just properties in the React Fluent UI library
The settings are stored in the local storage of the browser for simplicity

Lessons learned with GitHub Copilot and Claude Code

The project was developed almost entirely in "interactive agent-driven mode".
Both GitHub Copilot and Claude Code were used as active development assistants during the entire process.

The agents were involved in:

Concept discussions
Implementation
Refactoring
Architectural decisions
Documentation improvements
Iterative improvements to the collaboration workflow

In addition to generating code, the agents were also used to discuss best practices and improve the documentation and structure of the project itself. Both agents used the same model (Claude Sonnet 4.6), but produced different results due to their overall architectural differences.

Claude Code

Overall, Claude Code produced more consistent and reliable results.

Strengths included:

Better architectural reasoning
More structured implementations
Clearer explanations
Higher-quality refactorings

Claude Code was particularly strong when working across multiple files or when performing larger structural changes in the project. In the beginning it introduced reusable UI components even before having instructions to do so.
When working with Claude Code, development sessions occasionally reached usage limits. This required temporarily switching back to GitHub Copilot until the session limit reset. As a result, the project naturally evolved into a mixed workflow where both tools contributed to the final implementation.

GitHub Copilot

GitHub Copilot performed well for smaller tasks but showed some weaknesses when acting as a full development agent.

Some common issues included:
- Guessing instead of reasoning
- Repeating the same incorrect approach multiple times
- Getting stuck in loops when a problem was not clearly defined

However, some of these issues were likely influenced by better instructions given to the agent (e.g. links to the official documentation, instructions to always look there first)

At the beginning of the project, important rules were not yet defined, for example:
- Asking for confirmation before large refactorings
- Explaining architectural changes before applying them
- Avoiding speculative changes

Once clearer rules were established, the results improved.

Architecture

The architecture naturally follows the architecture of Power Apps Code Apps. Services for accessing data and model classes were generated using the pac tool.

The following architecture diagram was generated with Claude Code. This no longer has to be done manually by hand either...

Conclusion

It is extremely impressive how quickly and easily a Power Apps Code App can be developed with GitHub Copilot or Claude Code. What makes development so fast and straightforward is the combination of coding agents with an intelligent framework for app development.

Throughout the entire development process, there was never any sense of working with an unstable product or with something that had only recently reached general availability. There were no crashes at all, and deploying the app via solution to another environment also worked flawlessly.

Only in a few places does the API appear to be not entirely complete yet. For example, RetrieveRecordAsync did not work, so a workaround had to be implemented using GetAll with a filter expression. However, the most important actions for loading, filtering, and saving data are already very stable.

Code Apps will fundamentally change the way we build apps in Dataverse environments and across the Power Platform. Canvas Apps may soon become obsolete and be replaced by Code Apps. There may also be more options in the future to integrate Code Apps into Model-Driven Apps. Until then, however, both can coexist peacefully side by side.

Image

/sites/default/files/2026-03/Power-Apps-Code-Apps-in-Practice_1.png

Use XRM type definition in your Javascript file

Nguyen Van Hao — Tue, 27 Jan 2026 12:12:09 +0000

Use XRM type definition in your Javascript file Nguyen Van Hao Tue, 01/27/2026 - 13:12

Body

We implement Javascript webresource for form scripting (form onload, field on change,...). Our code need to follow the official document Xrm object, execution context, form context,..

Javascript is not a strong type programing language, we don't have suggession/intellisense like C#, Typescript

In this article, I will show you how to get suggession/intellisense for your JS code

Step 1: Download the file xrm type definition here

Save it to a folder, for example Types\xrm.d.ts

Step 2. Add this line to the top of the JS file that you want to have intellisense

/// <reference path="../Types/xrm.d.ts" />

Step 3: Add type annotation for function param

Step 4. Enjoy the magic

You will have suggestions while typing like this

It also shows suggestions for Xrm.WebApi

That's all. Hope this help you.

Row Summary in Model-Driven Apps

Stephane Pelhatre — Tue, 14 Oct 2025 08:04:03 +0000

Row Summary in Model-Driven Apps Stephane Pelhatre Tue, 10/14/2025 - 10:04

Body

Introduction

In model-driven applications, forms often contain many fields spread across multiple tabs and sections, which can make it difficult and time-consuming to find key information. Navigating between these tabs slows productivity and increases the risk of missing important information. Finding key insights quickly can be a challenge.

The Row Summary feature solves this problem by displaying a clear and concise summary of the most important information. Makers can customize the columns to include and choose how the summary is presented (as bullet points or as a short paragraph). This allows users to get the necessary context at a glance, without having to scroll through the entire form.
Furthermore, the summary can include clickable links to related records.

At the time of writing this article, this feature is still in preview.
Summaries are currently only supported in the English language.
Preview features aren’t meant for production use and might have restricted functionality.

Enable Row Summary feature

Before you can configure a Row Summary, you need to enable the feature in your environment:

Go to Power Platform Admin Center
Select your environment
Go to Settings > Product > Features
Enable the feature AI Insight Cards

Once enabled, you’ll be able to access and configure the Row Summary feature in model-driven apps.

Configure Row Summary for a table

To configure a row summary for main forms for a specific table:

Open Power Apps Portal and select your environment
Select the table where you want to apply the row summary (e.g., Contact) from the left navigation pane and click on Row summary in the section Customizations

Another way is to select your table from the left navigation pane and click on Forms in the section Data experience

Then click on Row summary on the command bar and from the dropdown select Edit Summary to begin customization
Following window is displayed:
Now you have to define columns to include in the summary and write a prompt
- In the Prompt editor, click on +Add data or type "/" to choose the columns you want the AI to summarize (in my example: full name, job title, company name, marital status)
If you click on +Add data you can add several columns in one step which is not the case if you type "/"
- Write a custom instruction (prompt) describing how the summary should be generated
In my example below : Generate a concise summary using the selected fields. Use bullet points and return “No value” if a field is empty
Click on Test to preview the summary output (the most recently edited record is used to generate the test response)
Once satisfied, click on Apply to main forms to enable the summary across all main forms for your table

Display the list of forms : an AI icon is visible for forms where the summary is active (only main forms)

To modify an existing row summary:

In Power Apps Portal select your table where you want to modify the row summary
Click on Forms in the section Data experience
Then click on Row summary on the command bar and from the dropdown select Edit Summary

An alternative to the previous method (point 2) is to click on Row summary (applied) in section Customizations
Make your changes to the prompt or included columns and reapply

To remove a summary from all forms:

In Power Apps Portal select your table where you want to remove the row summary
Click on Forms in the section Data experience.
Then click on Row summary on the command bar and from the dropdown select Hide on all main forms

View Row Summary in Dynamics 365

Open your app in Dynamics 365 and navigate to the entity (e.g., Contact) where the row summary is configured.
Select a record in the view : an AI summary icon is displayed.

Click on this icon : AI-generated summary is displayed in a modal popup.

Note that you can copy the summary into the clipboard.

If you open a record (e.g., Contact) the summary is displayed at the top of the form in a collapsible bar (called Insights bar).

Image

/sites/default/files/2025-10/ChatGPT%20Image%20Oct%2020%2C%202025%2C%2006_24_24%20PM.png

Dataverse: Duplicate Detection Rules vs Alternate Keys

Stephane Pelhatre — Wed, 08 Oct 2025 15:57:17 +0000

Dataverse: Duplicate Detection Rules vs Alternate Keys Stephane Pelhatre Wed, 10/08/2025 - 17:57

Body

Introduction

Having clean data in Dataverse can be tricky. One of the challenges is detecting and managing duplicate records.
With out-of-the-box tools you can implement duplicate detection rules or create alternate keys.
If you are a developer, you can implement a custom validation in a plugin.
In this article we will focus on out-of-the-box features (duplicate detection rules and alternate keys) and compare them.

Duplicate detection rules

First step is to check if the feature Duplicate Detection is enabled in your environment (it is enabled by default):

Connect to Dynamics 365 and open Power Platform Environment Settings app
Click on Data Management on the left pane and select Duplicate detection settings
Check that the option Enable duplicate detection is enabled

There are 3 triggers that you can activate:

When a record is created or updated
When Microsoft Dynamics 365 for Outlook goes from offline to online
During data import

Second step is to make sure the feature is enabled for your table:

Open Power Apps Portal and select your environment
Select your table on the left pane and click on Properties
Expand Advanced options pane and ensure that Apply duplicate detection rules is checked

Then you can create duplicate detection rules:

Connect to Dynamics 365 and open Power Platform Environment Settings app
Click on Data Management on the left pane and select Duplicate detection rules
All out-of-the-box duplicate detection rules are displayed
Click on New on the command bar
Below an example with the out-of-the-box rule Contacts with the same first name and last name for Contact table

Provide a name and description for the rule and define the criteria for identifying duplicates:

Base Record Type: select the type of record the rule applies to (e.g., Contacts).
Matching Record Type: select the type of record to compare. Typically, this is the same as the base record type, but you can compare different types (e.g., Contacts and Leads).
Exclude Inactive Records: check this box if you want to exclude inactive records from the duplicate detection process.
Case-Sensitive: check this box if the rule should be case-sensitive.
Field Selection: for each criterion, select the fields to compare and the operator (e.g., Exact Match).
Ignore Blank Values: check this box if you do not want the rule to consider blank fields as equal.

You can add several criterions to your rule criteria:
For text fields you have 3 choices:
- Exact Match
- Same First Characters
- Same Last Characters
For Datetime fields you have 2 choices:
- Same date
- Same date and time
For whole number/decimal and lookup fields only Exact Match is available

5. After configuring the criteria, click on Save.
To make the rule active, select it and click on Publish.
Note that you can only publish up to five rules for the same base record type at a time.

Now let's try creating a duplicate record using Dynamics 365 UI. For example a contact with existing first name and last name.
You should see a pop-up dialog with the warning message Duplicate records found.

You have 3 possibilities:

Ignore and save : if you are certain the record is unique or requires a new entry despite the match, click "Ignore and Save" to create the duplicate
Merge : if you want to combine the information from both records into a single, primary record, select "Merge." You will typically be prompted to choose which record will be the primary one, and then you can select which fields to keep from each record
Cancel : do not create the duplicate record

Alternate keys

An alternative to duplicate detection rule is to create alternate keys.
This method is the same as creating unique-index(es) from the database perspective. Hence this method will be more strict compared to duplicate detection rules.
An alternate key can combine one or several columns.
It can contain multiple rows with NULL values. NULL values are not indexed.

Some limitations:

There can be a maximum of 10 alternate keys for a table in a Dataverse instance
Columns used in the key must not have field-level security applied
Alternate keys aren't supported in virtual tables
When a key is created, the system validates the key, including that the total key size doesn't violate SQL-based index constraints like 900 bytes per key and 16 columns per key. If the key size doesn't meet the constraints, an error message is displayed
Unicode characters in key value. If the data within a column that is used in an alternate key contains one of the following characters /,<,>,*,%,&,:,\\,?,+ then retrieve (GET), update or upsert (PATCH) actions won't work. If you only need uniqueness, then this approach works, but if you need to use these keys as part of data integration then it's best to create the key on columns that won't have data with those characters

To create an alternate key for a specific table:

Open Power Apps Portal and select your environment
Select the table into which you want to create an alternate key
Click on Keys
Provide a display name and select the columns to include in your key
In the example below I create an alternate key in table Contact for columns birthday and last name
Only columns of the following types can be included in alternate key table definitions:
- Decimal Number
- Whole Number
- Single line of text
- Date Time
- Lookup
- Option Set
Click on Save. The system will automatically create the index in the database.
If the system detects duplicate data in the table, the creation will fail and you need to delete data first.
If there are lots of existing records in your table, index creation can be a lengthy process.
During creation of the key status will be Pending. Once the creation is complete status changes to Active.

Now let's try creating a duplicate record using Dynamics 365 UI. To be consistent with the alternate key created previously, a contact with existing birthday and last name.
You should see a pop-up error with the message Duplicate record.

Therefore, it is impossible to create a duplicate record with the user interface. This makes sense as uniqueness is ensured at the database level.

Creating/Updating records programmatically

We have seen that behavior is different when we create a duplicate record with the UI using duplicate detection rules or alternate keys.
But what happens if we create duplicate records programmatically with Dynamics 365 SDK or Web API?

Duplicate detection rules

By default duplicate detection rules are not applied when you are creating or updating records using Web API or Dynamics 365 API. Therefore duplicate records will be created.
If you want Dynamics 365 to raise an error you must utilize an optional parameter.
With Web API use parameter MSCRM.SuppressDuplicateDetection in the header of your HTTP request (POST to create a record or PATCH to update a record) to avoid creation of a duplicate record of an existing record.
The value assigned to MSCRM.SuppressDuplicateDetection determines whether the Create or Update operation can be completed:

true: Create or update the record, if a duplicate is found.
false: Do not create or update the record, if a duplicate is found.

So ensure that MSCRM.SuppressDuplicateDetection is set to false in your Web API request to detect duplicates.
You will get the following error message if you try to create a duplicate record:

{
"error": {
"code": "0x80040333",
"message": "A record was not created or updated because a duplicate of the current record already exists."
}
}

Note that if you do not use MSCRM.SuppressDuplicateDetection duplicates will be created.
Below an example of POST request to create a contact named "John Doe" with activation of duplicate detection rules.

POST [Organization URI]/org1/api/data/v9.2/contacts
If-None-Match: null
OData-Version: 4.0
OData-MaxVersion: 4.0
Content-Type: application/json
Accept: application/json
MSCRM.SuppressDuplicateDetection: false

{
    "firstname":"John",
    "lastname":"Doe"
}

And below an example performed with XrmToolbox plugin WebAPI Launcher.
Note parameter MSCRM.SuppressDuplicateDetection in the header.

And the result of this Web API request if we try to create a duplicate:

With Dynamics 365 SDK you have to use SuppressDuplicateDetection optional parameter in your request (CreateRequest or UpdateRequest) if you want the configured duplicate detection rules to run and throw an exception while creating or updating a record.
So set its value to false in your code to trigger duplicate detection rules.
You will get the following error if you try to create a duplicate record:
A record was not created or updated because a duplicate of the current record already exists

Below a C# example to create with the SDK a contact named "John Doe" with activation of duplicate detection rules.

namespace CrmDuplicateDetection
{
    class Program
    {
        static void Main(string[] args)
        {
            CrmServiceClient.MaxConnectionTimeout = TimeSpan.FromHours(3);
            var connectionString = WebConfigurationManager.AppSettings["connectionString"];
            var client = new CrmServiceClient(connectionString);
 
            var contact = new Entity("contact")
            {
                ["firstname"] = "John",
                ["lastname"] = "Doe"
            };
 
            var createRequest = new CreateRequest { Target = contact };
            // Pass parameter 'SuppressDuplicateDetection' to trigger Duplicate Detection Rules
            createRequest["SuppressDuplicateDetection"] = false;
            var response = (CreateResponse)client.Execute(createRequest);
        }
    }
}

Alternate keys

If you try to create a duplicate record programmatically with Dynamics 365 SDK you will get an error even if you set parameter SuppressDuplicateDetection to false in your CreateRequest/UpdateRequest request (and same if you set MSCRM.SuppressDuplicateDetection to false in the header of your Web API request).

Below an example of Web API POST request to create a contact with last name and birthdate that already exist in Dataverse.

Conclusion

As we have seen alternate keys are a strict way to avoid duplicates creation and ensure data correctness.
It is not possible to create duplicate records using Dynamics 365 user interface or Web API/Dynamics 365 SDK.
But alternate keys have some limitations (10 alternate keys max per table, not supported in virtual tables, cannot include columns with field level security enabled, no operator Same First/Last characters in the criteria).
Duplicate detection rules are more flexible when creating duplicate records through the UI (ability to merge records or force the creation of duplicates).
And with Web API/Dynamics 365 SDK you can choose whether you want to apply duplicate detection rules when creating/updating records.
So the choice between duplicate detection rules and alternate keys will depend on whether you want to allow duplicates creation under certain circumstances.
If you never want to create duplicate records (either through the user interface or programmatically) alternate keys are a good solution because the check is done at database level.
But if you want to warn users when they try to create a duplicate record in the UI and allow them to confirm or not the duplicate creation (and use Merge feature) duplicate detection rules are a good choice.
The same is true if you have interfaces between a third-party system and Dynamics 365 (an Azure webjob or Azure function for instance) and want to allow or not creation of duplicates.
But if you have an existing interface that allows the creation of duplicate records and want to change this behavior, you will have to modify the source code of the interface to use SuppressDuplicateDetection parameter to trigger duplicate detection rules.

Image

/sites/default/files/2025-10/ChatGPT%20Image%20Oct%2020%2C%202025%2C%2006_26_53%20PM.png

Dataverse : Using bulk operation messages

Stephane Pelhatre — Mon, 01 Sep 2025 13:08:36 +0000

Dataverse : Using bulk operation messages Stephane Pelhatre Mon, 09/01/2025 - 15:08

Body

Introduction

As you may know plug-in messages have been introduced for bulk operations in Dynamics 365.

Bulk operations messages are:

CreateMultiple: Create multiple records of the same type in a single request.
UpdateMultiple: Update multiple records of the same type in a single request.
UpsertMultiple: Create or update multiple records of the same type in a single request.
DeleteMultiple : Delete multiple records of the same type in a single request. For elastic tables only.

Bulk operations are optimized to perform on multiple rows in a single transaction, so performance should increase overall as the number of operations per request increases.
This optimization allows for any plug-in step that is registered for the bulk operation to be more efficient.
Indeed, each time a plug-in is invoked for a single operation, some milliseconds are required to invoke the plug-in class containing the logic.
When a plug-in is registered for a bulk operation message, the class is invoked once and can process all the operations more efficiently.

Availability

Messages CreateMultiple and UpdateMultiple are available for all custom tables, but not all standard tables.
Message UpsertMultiple is available if the table supports both CreateMultiple and UpdateMultiple messages.
Message DeleteMultiple is not supported by standard and custom tables, it is available only for elastic tables.
All messages (CreateMultiple, UpdateMultiple, UpsertMultiple, DeleteMultiple) are available for elastic tables.

If you want to use messages CreateMultiple/UpdateMultiple with a standard table you first need to check that the message is available for the table.
You can execute the below fetchxml to get the list of tables that support UpdateMultiple message

If we adapt the fetchxml to get the list for message CreateMultiple we get the same list. So currently standard tables that support CreateMultiple also support UpdateMultiple.

You can also use the below static method to detect whether a given table supports CreateMultiple or UpdateMultiple.

What is changing in your code

Context

For bulk messages we need to use the new IPluginExecutionContext4 interface instead of IPluginExecutionContext, to get targets and entity images collections from the plugin context as explained below.

After retrieving IPluginExecutionContext4 object we can use new features (see below).

Targets entityCollection

For single Create/Update the input parameter Target is a single Entity.
For bulk message input parameter Targets is an EntityCollection.
The plug-in code loops through the entities in the collection and apply logic to each entity.
Below a simple piece of code that checks if the collection is a list of contacts and stores the ids:

Entity images

Entity images are configured in the plug-in step registration.
For single Create/Update we receive images PostEntityImages/PreEntityImages with type EntityImageCollection.

For messages CreateMultiple/UpdateMultiple entity images are an array of EntityImageCollection.
These entity images are available when you use IPluginExecutionContext4 interface, which provides PreEntityImagesCollection and PostEntityImagesCollection properties.

When you configure entity images for plug-in steps for CreateMultiple and UpdateMultiple you have to carefully select which columns to include.
It is not recommended to select the default option (all columns) : indeed data is multiplied by the number of entities passed in the Targets parameter and contributes to the total size of the message.
As a consequence you may hit the limit on message size.

Attribute filters

When you register a plug-in step on Update or UpdateMultiple message, you can specify filtering attributes in the step registration.

With Update, the plug-in runs when one of the selected attributes is included in the Target entity.
With UpdateMultiple, the plug-in runs when one of the selected attributes is included in any of the entities in the Targets parameter.
As a consequence for UpdateMultiple you can't assume that every entity in the Targets parameter contains attributes that are used in a filter.

Number of records

Officially there is no limit on the number of records you can send in a bulk operation.
However, as the number of records increases, the request size also increases and the payload is larger. As a consequence you may encounter the error "Message size exceeded when sending context to Sandbox".
You get this error when the total size of the request exceeds 116.85 MB. With bulk operation messages you're more likely to hit this limit as you send larger payloads.
In this case you have to reduce the number of records you send to the bulk operations.
Microsoft recommends to send 1000 records maximum if the size of the record data is small.
But for large entities like Contact or Account you will probably have to reduce to 100 or 200 records per bulk operation.
So to summarize there is no rule : you will have to experiment the maximum number of records you can process in a bulk operation, depending on the entity and also the configuration of pre/post images.

Behavior when on error occurs

As a single transaction is used for bulk operation, any error that occurs in a bulk operation causes the entire operation to roll back. It means that even if some records have been processed before the error occurs all changes will be cancelled.
So my advice is to use bulk operations when you have a high degree of confidence that all operations will succeed.
Moreover as you are more likely to get an unexpected error with bulk operation you have to take care of exception handling in your code.
Note that as there is no transaction with elastic tables a partial success is possible if you use an elastic table.

Do you have to migrate your code?

Microsoft recommends to use bulk operation CreateMultiple/UpdateMultiple when you develop a new plug-in as there is no drawback to use those new messages.
But what about existing plug-ins?
Of course it is not mandatory to migrate your plug-ins implemented with message Create/Update to bulk messages CreateMultiple/UpdateMultiple.

Each of the bulk operation message still has a corresponding message that operates on individual records: Create, Update.

Developers are not required to maintain custom logic in two places. To have the same custom logic and maintain it in one place the message processing pipelines for these messages have been merged.
What does it means?
When a bulk operation message CreateMultiple/UpdateMultiple is used, the respective Create/Update event occurs for each entity instance in the Targets parameter. Any plug-in for the corresponding individual event continue to work.
So you don't need to write new plug-ins to manage events raised by these messages.
When a single operation message is used, the respective bulk operation event occurs with an EntityCollection containing a single Entity instance passed in the Targets parameter. So you can move any logic that responds to a single operation event to the corresponding bulk operation event and the logic will be applied for both individual and multiple operations.

As a consequence, duplicate logic can potentially be applied on both single and bulk message of an event. Note that Dataverse will not try to prevent this.
So developers have to make sure that the same logic applied for the single message of an event is migrated to the multiple message of the event and removed from the single version of the event. If you do not take care the logic will be applied twice.

Benchmark

To evaluate the potential improvement in execution time I performed the following benchmark:

Creation and update of 100 contacts in a batch (C# console application).
To create contacts I set the fields 'first name' and 'last name'. And to update contacts I modify the first name.
I used the 4 following methods:

Method 1
Creation/Update of 100 records with the classic single message Create/Update (so 1 call for each record)
Method 2
Creation/Update of 100 records with a call for each of them to the bulk message CreateMultiple/UpdateMultiple
The goal is to check if using bulk message with only 1 record has an impact on performance
In this case we create a collection that contains only 1 record
Method 3
Creation/Update of 100 records with one call to the bulk message CreateMultiple/UpdateMultiple
Method 4
Creation/Update of 100 records with one call to ExecuteMultiple

Results:

Method 1
Create 100 records: 27.7 sec
Update 100 records: 29.2 sec
Method 2
Create 100 records: 27.5 sec
Update 100 records: 30.2 sec
Method 3
Create 100 records: 20.6 sec
Update 100 records: 15.6 sec
Method 4
Create 100 records: 22.4 sec
Update 100 records: 18.7 sec

To summarize the results:

Creating/updating records with classic single message or with bulk message for each record gives roughtly the same execution time
Creating/updating records with bulk message is faster than with single message called for each record
Creating/updating records with bulk message is slightly faster than with ExecuteMultiple

Globally if you have to create or update a single record, using the bulk message will not degrade/improve performance.
So for your future developments there is no reason to not use bulk message even if you create/update one record.

If you have to create/update several records you should use bulk message: you will get better performance.
Bulk message is a little bit faster than ExecuteMultiple.

But as explained previously you will have to experiment the maximum number of records you can process in a bulk operation.
Don't forget that plug-in has a timeout of 2 minutes.
For instance if I try to create 300 records with bulk message I get a timeout.

Image

/sites/default/files/2025-09/An%20octopus%20bot%20doing%20multiple%20operation%20on%20computer.%20Cyber%20punk%20style.%20.jpeg

Dataverse Functions Deep Dive

Stephane Pelhatre — Thu, 28 Aug 2025 12:38:15 +0000

Dataverse Functions Deep Dive Stephane Pelhatre Thu, 08/28/2025 - 14:38

Body

Introduction

Microsoft released in 2024 Dataverse low-code plugins. The promise was great : writing plugins using low-code tools. No need to have development skills and use a development environment as Microsoft Visual Studio, write C# code and register plugin in your environment.

There are two types of low-code plugins supported in Dataverse : instant and automated. The difference is the trigger. For instant low-code plugin the trigger is manual, the plugin must be explicitly called (for example from a Power Automate flow). Automated low-code plugins work like classic plugins : the trigger is a Dataverse table event. For example you can create an automated low-code plugin on Create event for Account table. Low-code plugin feature is still in preview.

Then Microsoft has introduced Power Fx functions (eventually renamed Dataverse functions). Functions are a low-code/no-code way to write reusable logic directly within Dataverse. Functions use Power Fx to execute a set of commands within Dataverse that run on the server-side. The trigger is also manual, so a function must be called explicitly .
The situation is therefore somewhat confusing as instant low-code plugins resemble Dataverse functions and both features are available in preview.
Technically functions and low-code plugins are 2 different tools, with their own Microsoft Learn Docs having their own sections.

Officially instant low-code plugins are deprioritized and are replaced with Dataverse functions. Automated low-code plugins are still available. You can find more information here : Use low-code plug-ins in Dataverse

In this article we will first briefly examine low-code plugins. We won't go into detail because, as we will see, they don't really work.
Then we will examine Dataverse functions in detail.

Low-code plugins

Let's briefly talk about low-code plugins.
To access low -code plugins interface you need to install a model-driven app called Dataverse Accelerator:

Go to Power Platform Admin Center
Click on Environments on the left pane.
Then click on the ellipsis (...) next to your environment, select Resources and then Dynamics 365 apps
Click on Install app on the command bar
Select Dataverse Accelerator in the list and click on Next
Check I agree to the terms of service and click on Install
Once the installation is complete Dataverse Accelerator app is available in the list of apps

Now you can play the app and you will see the interface below:

As explained in the introduction there are two types of plugins : instant plugins that must be called explicitly and automated plugins that are triggered by an event on a table.
There is a button to create an instant plugin and another to create an automated plugin. Note that it 's a bit strange to have the option to create an instant plugin as this feature is deprioritized and replaced by Dataverse functions.

Then if you click on either of the two buttons ... nothing happens and the screen remains blank. I tried with several Dataverse environments located in different regions (US, Western Europe) with the same result : a blank screen.

This problem is understandable for instant plugins as they are replaced by functions. But regarding automated plugin it's a problem : it's impossible to create an automated plugin.
It was working a few months ago (but buggy as hell), but as of the date of writing this article (October 2025), it no longer works.
Maybe it will work again in the future or maybe Microsoft will remove this feature.

Dataverse Functions

Introduction

Functions are a low-code/no-code way to write reusable logic directly within Dataverse (running server-side) without having to write C# code or deploying plugins.
Functions can have parameters: parameters allow you to pass information between the function and the context that runs it, making it easier to design business logic that can be reused in varying situations. Input parameters are used to provide data to the function, and allow you to control how the function behaves by passing in different values you specify in the Power Fx formula. Output parameters allow you to retrieve the results of a function for further use in your program.

How to create a function

Open Power Apps Portal and select your environment
Open the solution where you want to build a function
Click on New --> Automation --> Function

Provide the following details:
- Display name : The human-readable name of the function. Can't be changed once created.
- Description : provide additional context about the function, such as purpose, behavior, and so on. Can't be changed once created.
- Input parameters(s) : add required input parameters. Input paramerts are optional.
To add a parameter click on + New input parameter
Following types are supported: Boolean, Datetime, Decimal, Float, Integer, String
- Output result(s) : add output results parameters. Output results are optional. To add an output result click on + New output result
- Table references : used to associate functions to specific tables. You can select up to five tables to read or write from in your function’s formula.
- Formula: custom function that can be used to perform actions or calculations, defined using the Power Fx expression language

Let's create a simple function to sum two numbers.
I define my function CustomSum with two inputs parameters x and y and one output parameter z.The Power Fx formula to sum the 2 numbers is : {z:x+y}

Another example: let's implement a function that creates a contact from two input parameters firstname and lastname (both with string data type)
This time we need to access a table to create a record, so I select 'Contacts' table in Table references
I also define an output result message to indicate that the contact was created successfully
In the Power Fx formula I use the function Collect() to create the record
```
Collect(contact,  
   { 
   firstname: firstname, 
   lastname: lastname 
   } 
   ); 
{ 
   message: "New contact " & firstname & "," & lastname & " created"
}
```
Click on Save to create the function
Various components are created and added to the solution:
- a Custom API
- a Function
- a FxExpression
- a custom API Request Parameter for each input parameter (2 in my example)
- a Custom API Response Property for each ouput result (1 in my example)

How to test a function

If you expect to find a button in the command bar when you select your function wihtin the solution, forget it. It is not possible to test a function inside a solution.
To test a function:

Come out of the solution
Click on More on the left pane and then click on Discover all
Click on Functions
Select your function and click on Test on the command bar

Another way is to click on the ellipsis (...) and select Test in the menu
Enter a value for each input parameter and click on Play
Result is displayed in the text area at the bottom.
In my example with function CustomSum I set x = 10 and y = 5 and we can see that value assigned to output result is 15
Result is : {"@odata.context":"https://orgxxxxx.crm.dynamics.com/api/data/v9.0/$metadata#Microsoft.Dynamics.CRM.cr0de_CustomSumResponse","z":15}

For the second function Create Contact I set firstname = 'John' and lastname = 'Doe'. You can see the result below:

How to delete a function

You must be careful if you want to delete a function. If you delete the function component in your solution only the function itself will be deleted, but related components (Custom API, FxExpression, custom API Request Parameters, Custom API Response Properties) will not be deleted. Therefore, you will end up with orphaned components.
To delete the function and all related components you must follow the same steps as for testing a function (see above): come out of the solution, click on More then Discover all and select Functions.
Then you can click on Delete on the command bar or click on the ellipsis (...) and select Delete.

Trace logs

You can access Dataverse functions trace logs in the same place as classic plugins.
Open Power Platform Environment Settings app and click on Plug-in Trace Log on the left pane.

You have access to execution information (duration, message block, exception, ...)

Invoke a function

We now know how to create and test a function, but it's time to use it.
As explained previously, functions are only triggered manually, so you need to call them explicitly.
You can invoke functions in Dataverse from:

a canvas app
a custom page in a model driven app
a Power Automate flow
from another function
in your code (Web API)

You can obtain a code snippet of your function that you will then use to call that function:

Open Power Apps Portal and select your environment
Click on More on the left pane and then click on Discover all
Click on Functions
Select you function and click on Copy code snippet on the command bar

Another way is to click on the ellipsis (...) and select Copy code snippet in the menu

Below the code snippet for my functions CustomSum and Create contact

Environment.cr0de_CustomSum({x:Value,y:Value})
Environment.cr0de_Createcontact({firstname:Value,lastname:Value})

Invoke a function from the Dataverse Web API

You can invoke a Dataverse function from the Web API with a POST request
Example with the function CustomSum:

POST [Organization URI]/api/data/v9.2/cr0de_CustomSum
OData-MaxVersion: 4.0
OData-Version: 4.0
Content-Type: application/json; charset=utf-8

{
   "x":4,
   "y":5
}

Here the result I get with the plugin WebAPI Launcher in XrmtoolBox:

Invoke a function from within another function

You can invoke a function from any other function.
To invoke a function within another function, use the syntax: Environment.MyFunction({inputParam1: value1, inputParam2: value2, ... inputParamN: valueN}).
Since the output is always a record, use the dot notation to access the output parameters.
For example, if the function MyFunction has two output parameters defined as out1 and out2, you can access them in either of these two ways:

Environment.ExistingFunction({inputParam1: value1, inputParam2: value2, ... inputParamN: valueN}).out1
Environment.ExistingFunction({inputParam1: value1, inputParam2: value2, ... inputParamN: valueN}).out2

To demonstrate this, I create a new function CustomSum2 to add 2 and 3. To perform this operation I use the first function CustomSum.
The new function CustomSum2 has no input parameter and one output result result (Integer type).
Power Fx formula of the new function:
{
result:Environment.cr0de_CustomSum({x:2,y:3}).z
}

Invoke a function from a Power Automate cloud flow

To use a function in a cloud flow:

Add a step to your flow
select Microsoft Dataverse connector
select Perform an unbound action action
In Action Name, select the function (cr0de_CustomSum in my example) and provide values for the input parameters (x = 6 and y = 3 in my example)
Add a compose action using the output of the unbound action as an input so that you can access the results of the function as needed

Below the result:

Limitations with functions

Functions have some limitations:

Max 5 tables per function
Only manual trigger, cannot be automated (that's the goal of low-code plugins)
Cannot call external API, limited to Dataverse
Still in preview : may have bugs. Not suitable for production
The following Power Fx function aren't currently supported with functions in Dataverse

Image

/sites/default/files/2026-01/dataver_functions2.png

Dataverse / Dynamics 365 : Azure Managed Identities from Plugins. Step by Step.

julien.biedermann — Thu, 17 Jul 2025 12:47:18 +0000

Dataverse / Dynamics 365 : Azure Managed Identities from Plugins. Step by Step. julien.biedermann Thu, 07/17/2025 - 14:47

Body

Introduction

The days of storing Client ID and secret of your Key Vault in Dynamics are coming to an end. With Power Platform Managed Identity, Dataverse plug-ins can now connect to Azure resources that support managed identity without the need for credentials. Please note that at the time of writing this article, this feature is still in preview and is not intended for production use.

This marks a significant improvement in security and access management, eliminating the risks associated with storing credentials while simplifying integration between Dataverse and Azure. In this article, we’ll explore how this feature works and the process for implementing it.

How to implement it

Microsoft’s documentation is missing some details that can make the configuration process challenging. In this article, I’ll provide a clear, step-by-step guide with practical examples to help you set everything up quickly and efficiently. My goal is to simplify the process and ensure you have a smooth experience getting it to work.

Step 1 : Create a new app registration or user-assigned managed identity

Create new "User Assigned Managed Identity". You can follow this documentation to create it.

Copy and save the "Client ID" value of your managed identity to be used in step 6

Step 2 : Create Key Vault

Create a key vault
Create a secret with name "DynamicsChroniclesSecret" and with secret value = "Managed identity for Power Platform is working"
In "Access control (IAM)" of your key vault, add the role assignment "Key Vault Secrets User" to the User Assigned Managed Identity created in step 1

Step 3 : Create a certificate

Open Powershell to create a certificate using this script

# Generate a self-signed certificate
$cert = New-SelfSignedCertificate -Subject "CN=dynamicschronicles, O=corp, C=dynamicschronicles.ch" -DnsName "www.dynamicschronicles.ch" -Type CodeSigning -KeyUsage DigitalSignature -CertStoreLocation Cert:\CurrentUser\My -FriendlyName "dynamicschronicles"
# Set a password for the private key
$pw = ConvertTo-SecureString -String "complexpwd12345" -Force -AsPlainText
# Export the certificate as a PFX file
Export-PfxCertificate -Cert $cert -FilePath 'C:\temp\dynamicschronicles_certificate.pfx' -Password $pw
Write-Host "Self-signed certificate exported as C:\temp\dynamicschronicles_certificate.pfx."
# Display thumbprint
$cert.Thumbprint

Copy and save the "Thumbprint" value to be used in step 5

Step 4 : Create a plug-in assembly, sign it and register it

Create a new plug-in using Visual Studio. Here is an example of code :

using Microsoft.Xrm.Sdk;
using System;
using System.Collections.Generic;
using System.Net.Http;
using System.Net.Http.Headers;

namespace ManagedPlugin
{
    public class ManagedPlugin : IPlugin
    {
        public void Execute(IServiceProvider serviceProvider)
        {
            // Obtain the tracing service
            ITracingService tracingService =
            (ITracingService)serviceProvider.GetService(typeof(ITracingService));

            // Obtain the execution context from the service provider.  
            IManagedIdentityService managedIdentityService = (IManagedIdentityService)
                serviceProvider.GetService(typeof(IManagedIdentityService));

            // Obtain the execution context from the service provider.  
            IPluginExecutionContext context = (IPluginExecutionContext)
                serviceProvider.GetService(typeof(IPluginExecutionContext));
            
            // Initialize empty token
            string token = string.Empty;
            string[] scopes = new string[] { "https://YOUR-DYNAMICS-ORG-URL.crm4.dynamics.com/.default" };

            try
            {
                tracingService.Trace("Scopes in GetAccessTokenManagedIdentity: " + string.Join(", ", scopes));
                token = managedIdentityService.AcquireToken(scopes);
                tracingService.Trace($"MANAGED IDENTITY TOKEN : {token}");
            }
            catch (Exception ex)
            {
                tracingService.Trace($"Failed to acquire token {ex.Message}");
            }

            var keyvaultname = "YOUR-KEYVAULT-NAME";
            var secretname = "DynamicsChroniclesSecret";

            // Get Token
            var kv_scopes = new List<string> { "https://vault.azure.net/.default" };
            var kv_token = managedIdentityService.AcquireToken(kv_scopes);
            tracingService.Trace($"KV TOKEN : {kv_token}");

            var keyvaultsecretUrl = $"https://{keyvaultname}.vault.azure.net/secrets/{secretname}?api-version=7.4";

            try
            {
                using (HttpClient client = new HttpClient())
                {
                    client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", kv_token);
                    client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));

                    var request = new HttpRequestMessage(HttpMethod.Get, new Uri(keyvaultsecretUrl));
                    var response = client.SendAsync(request).Result;

                    string json = response.Content.ReadAsStringAsync().Result;

                    var keyVaultResponse = System.Text.Json.JsonSerializer.Deserialize<KeyVaultResponse>(json);

                    tracingService.Trace($"KV SECRET VALUE : {keyVaultResponse.value}");

                }
            }
            catch (Exception ex)
            {
                tracingService.Trace($"Failed to acquire token {ex.Message}");
            }

        }

    }
}
public class KeyVaultResponse
{
    public string value { get; set; }
    public string id { get; set; }

}

Replace the following values with yours
1. Line 27 => "https://YOUR-DYNAMICS-ORG-URL.crm4.dynamics.com/.default"
2. Line 40 => "YOUR-KEYVAULT-NAME" (name of the key vault created in step 2)
Build the plugin
Sign the plugin using signtool and the following Powershell command

.\signtool sign /f "C:\temp\dynamicschronicles_certificate.pfx" /p "complexpwd12345"  "C:\Path_to_your_plugin\bin\Debug\ManagedPlugin.dll"

Step 5 : Configure federated identity credentials

Open the User Assigned Managed Identity created in step 1
Navigate to "Settings/Federated credentials" and click on "Add Credential"

Select "Other" for "Federated credential scenario"
Set "Issuer" = https://[Dynamics environment ID prefix].[Dynamics environment ID suffix].environment.api.powerplatform.com/sts
1. Replace "[Dynamics Environment ID prefix]" with your environment ID (except the last two characters and without dashes)
2. Replace "[Dynamics Environment ID suffix]" with the two last characters of the environment ID
Set "Subject identifier" = component:pluginassembly,thumbprint:[Thumbprint],environment:[Dynamics environment ID]
1. Replace "[Thumbprint]" with Thumbprint value copied in step 2
2. Replace "[Dynamics environment ID]" with your environment ID (with dashes)
Set "Name" to whatever you want
For "Audience", you can keep the default value

Click on "Add" to create the Federated Credential

Step 6 : Create managed identity record in Dataverse

Open "XRMToolbox" and open the tool "Plugin Identity Manager" (you can also create it manually if you want, see documentation here)
Select your plugin assembly (1)
Click on "Link to New Identity"

Fill in the following information and click on "Create and Link"
1. ApplicationId = "Client ID" value of your managed identity copied in step 1
2. TenantId = Your tenant Id (Directory ID in Azure)

Verification

Good news ! You're ready to go and check if everything is working well. To do so:

Trigger your plugin. In our case, it will be the creation of an account
Open Plugin Trace Log and check the plugin execution and if the secret is correctly retrieved

Everything is working well — we are now able to connect and retrieve secrets from Key Vault without having to store or manage any credentials in Dataverse.

I hope this step-by-step guide was clear and helped you configure everything easily on your end. If that’s not the case or if any steps need further clarification, please let me know in the comments.

Image

/sites/default/files/2025-07/article.png

Dataverse Managed Environments Deep Dive

julien.biedermann — Tue, 08 Oct 2024 12:45:19 +0000

Dataverse Managed Environments Deep Dive julien.biedermann Tue, 10/08/2024 - 14:45

Body

Dataverse Managed Environments Deep Dive:

What is Managed Environments ?

Managed environments is a set of features that allows administrators to manage Power Platform at scale with more control, less effort, and more visibility.

List of features available with Managed Environments for now (18/09/24) :

Limit sharing
Weekly usage insights
Data policies
Pipelines in Power Platform (preview)
Maker welcome content (preview)
Solution checker
IP Firewall
IP cookie binding
Customer Managed Key (CMK)
Lockbox
Extended backup
DLP for desktop flow
Export data to Azure Application Insights
Catalog in Power Platform
Default environment routing
Create an app description with Copilot
Virtual Network support for Power Platform

Requirements to enable Managed Environments

You may ask why to not activate this option on every environments ? What are the requirements and implications of enabling Managed Environments.

Everything is about licensing, when activating Managed Environments, every user that want to access the resources (Power Apps, Power Automate, Power Virtual Agents, and Power Pages website) in this environment must have a standalone licenses, Dynamics 365 Enterprise license or capacity add-ons.

Example of which licenses cannot run app in Managed Environments:

Microsoft/Office 365 licenses (Business, E1, E3, E5, F1, F3, …) that are coming with access to some limited Power Apps, Power Automate capabilities.

How to enable/disable Managed Environments ?

Permissions required

You must have the role of global admin, Power Platform service admin, or Dynamics 365 admin Microsoft Entra ID.
Any user with permission to see environment details can consult the Managed Environments property for an environment (from the list).

Users with the Delegated Admin role or the Environment Admin security role aren't allowed to change the Managed Environments property in an environment.

Enable Managed Environments in the admin center

Open the Power Platform admin center.

Enable Managed Environments using PowerShell

Below the script to enable Managed Environments (don't forget to replace <EnvironmentID>, it can be found here https://admin.powerplatform.microsoft.com) :

$GovernanceConfiguration = [pscustomobject] @{ 
    protectionLevel = "Standard" 
    settings = [pscustomobject]@{ 
        extendedSettings = @{} 
    }
}

Set-AdminPowerAppEnvironmentGovernanceConfiguration -EnvironmentName <EnvironmentID> -UpdatedGovernanceConfiguration $GovernanceConfiguration

Copy Managed Environment settings using PowerShell

These commands can be useful for deploying Managed Environments settings from one environment to another one. If the target environment wasn't a Managed Environment, copy settings will also enable it as a Managed Environment.

#Get settings from the source Managed Environment
$sourceEnvironment = Get-AdminPowerAppEnvironment -EnvironmentName <SourceEnvironmentId>

# Copy the settings from the source Managed Environment above to the target environment
Set-AdminPowerAppEnvironmentGovernanceConfiguration -EnvironmentName <TargetEnvironmentId> -UpdatedGovernanceConfiguration $sourceEnvironment.Internal.properties.governanceConfiguration

Disable Managed Environments using PowerShell

Managed Environments can be disabled by administrators using PowerShell. Before disabling Managed Environments, the administrator must ensure that none of the Managed Environments capabilities are in use.

Below the PowerShell script to disable Managed Environments :

$UpdatedGovernanceConfiguration = [pscustomobject]@{
    protectionLevel = "Basic"
}
Set-AdminPowerAppEnvironmentGovernanceConfiguration -EnvironmentName <EnvironmentID> -UpdatedGovernanceConfiguration $UpdatedGovernanceConfiguration

Quick overview of the available features

Limit sharing

Canvas app can be shared with users. With this feature, admins can limit how broadly users can share canvas apps. It is possible to restrict sharing with security groups and also set a limit on the number of individuals with whom the app can be shared.

Here is what the user will see when trying to share an app that is not matching the limit sharing rule:

Usage Insights

Keep updated on the status of your managed environments with Power Platform's weekly admin digest. Receive analytics detailing your top apps, most influential makers, and inactive resources that can be safely cleaned up, all conveniently delivered to your mailbox every week.

Here is the setting to enable Usage Insights (please note that also need to enable tenant-level analytics to get usage insights):

Who will receive the weekly digest ?

The weekly digest is sent to all users with the roles of Power Platform administrator and Dynamics 365 service administrator.

To include more recipients, choose "Add additional recipients for the weekly email digest", then opt for "Weekly digest" and input email addresses into the "Additional recipients" box.

What information is presented in the weekly digest ?

The first part of the weekly digest shows the number of apps used and active users in your managed environments in the past month.

The second part of the weekly digest shows lists apps and flows that haven't been launched in a while. The last launch column shows the last date of use for the app or flow. If an app or flow isn't being used, we recommend that you work with its owner to update or remove it.

The third part of the weekly digest shows the most popular apps and flows in your managed environments in the past month, indicated by the number of sessions and runs. When a user launches and interacts with an application, that's considered a session.

Data Policies

With this feature, admins can easily identify all the data policies that are applied to an environment.

When clicking on "See active data policies for this environment", the data policies page opens in a new tab. The view is filtered to display only the data policies that are applied to the managed environment. The environment filter is exclusively available for managed environments.

Pipelines in Power Platform

Pipelines in Power Platform aim to democratize application lifecycle management (ALM) for Power Platform and Dynamics 365 customers by bringing ALM automation and continuous integration and continuous delivery (CI/CD) capabilities into the service in a manner that's more approachable for all makers, admins, and developers. All target environments used in a pipeline must be enabled as Managed Environments.

Enable maker welcome content

Admins can provide customized welcome content to help their makers get started with Power Apps. When you add your own help content, it replaces the default Power Apps first-time help experience for makers.

Here is an example:

Solution checker enforcement

With solution checker enforcement feature, you can perform a rich static analysis check on your solutions against a set of best practice rules and identify problematic patterns.

Setting	Description
None	Turns off the automatic solution validations during solution import. There aren't any experience or behavioral changes to solution authoring, exports, or imports.
Warn	All custom solutions are automatically verified during solution import. When a solution with highly-critical issues is being imported, you are warned about the action but the import itself continues, and if everything else with the import is fine, the solution is imported into the environment. After a successful import, a message stating that the imported solution had validation issues is shown. Additionally, a summary email is sent with details of the solution validation.
Block	All custom solutions are automatically verified during solution import. When a solution has highly-critical issues, the import process is canceled, and a message stating that the imported solution had validation issues is shown. This happens before the actual import, so there aren't any changes to the environment due to the import failure. Additionally, a summary email is sent with details of the solution validation.

Who will receive the emails ?

When the validation mode is set to Warn or Block, a summary email is sent when a solution is imported or blocked. When the solution is imported into an environment, the summary email shows the count of issues by severity in the solution.

The email is sent to all users with the roles of Power Platform administrator and Dynamics 365 service administrator. It is also sent to recipients of the weekly digest emails.

By default, emails are sent for solutions containing medium or higher severities. When the checkbox "Send emails only when a solution is blocked [...]" is selected, emails won't be sent in warn mode. In block mode, emails aren't sent except for critical violations, which block solution import.

Rule exclusions

You have the option to opt out of enforcing certain solution checker rules. For instance, if fixing a specific rule requires considerable time and effort across the solution, but you still want other rules to be enforced, you can exclude that rule from enforcement. Utilize the "Excluded Rules" dropdown menu to choose which rules to exclude from enforcement. As a reminder, only critical severity rules block a solution from being imported.

IP firewall in Power Platform environments

The IP firewall helps to protect your organizational data by limiting user access to Microsoft Dataverse from only allowed IP locations. The IP firewall analyzes the IP address of each request in real time. For example, suppose the IP firewall is turned on in your production Dataverse environment, and allowed IP addresses are in the ranges associated with your office locations and not any external IP location like a coffee shop. If a user tries to access organizational resources from a coffee shop, Dataverse denies access in real time.

Safeguarding Dataverse sessions with IP cookie binding

Prevent session hijacking exploits in Dataverse with IP address-based cookie binding. Let's say that a malicious user copies a valid session cookie from an authorized computer that has cookie IP binding enabled. The user then tries to use the cookie on a different computer to gain unauthorized access to Dataverse. In real time, Dataverse compares the IP address of the cookie's origin against the IP address of the computer making the request. If the two are different, the attempt is blocked, and an error message is shown.

Manage your customer-managed encryption key

Customers have data privacy and compliance requirements to secure their data by encrypting their data at-rest. This secures the data from exposure in an event where a copy of the database is stolen. With data encryption at-rest, the stolen database data is protected from being restored to a different server without the encryption key.

All customer data stored in Power Platform is encrypted at-rest with strong Microsoft-managed encryption keys by default. Microsoft stores and manages the database encryption key for all your data so you don't have to. However, Power Platform provides this customer-managed encryption key (CMK) for your added data protection control where you can self-manage the database encryption key that is associated with your Microsoft Dataverse environment. This allows you to rotate or swap the encryption key on demand, and also allows you to prevent Microsoft's access to your customer data when you revoke the key access to our services at any time.

Securely access customer data using Customer Lockbox in Power Platform and Dynamics 365

Most operations, support, and troubleshooting performed by Microsoft personnel (including subprocessors) don't require access to customer data. With Power Platform Customer Lockbox, we provide an interface for the customers to review and approve (or reject) data access requests in the rare occasion when data access to customer data is needed. It's used in cases where a Microsoft engineer needs to access customer data, whether in response to a customer-initiated support ticket or a problem identified by Microsoft.

Customer Lockbox is available in public clouds and US Government Community Cloud (GCC), GCC High, and Department of Defense (DoD) regions.

Back up and restore environments

For environments that don't have Dynamics 365 applications, the default backup retention period is seven days. Admins who run production Managed Environments of this type can use PowerShell to change the retention period to 7, 14, 21, or 28 days.

A Managed Environment can be restored only to another Managed Environment. A non-Managed Environment can't be restored to a Managed Environment.

Is activating the Managed Environments a risky move?

Apart from the dependence on licenses, to me, the risk associated with activating the feature is minimal, here are the reasons:

This is transparent for the users if no feature are activated
This option is at the environment level (not at tenant level)
- This gives more flexibility and it allows to test the features in dev environment
Activation of a feature does not have retroactive effect
This option can be disabled at any time

On the other hand, admins need to be careful before activating a feature because it can have an impact on users. For example, activating "limit sharing" can block user in their job. It is important to test feature before activating them in production.

When to activate Managed Environments?

A feature requires to have Managed Environments activated
For large organizations with lots of environments, users, apps

Dataverse Managed Environments Deep Dive

Image

/sites/default/files/2024-09/article.png

Cloud Flow Run History in Dataverse

julien.biedermann — Thu, 26 Sep 2024 12:40:21 +0000

Cloud Flow Run History in Dataverse julien.biedermann Thu, 09/26/2024 - 14:40

Body

Please note that, at the time of writing this article, this feature is still in preview.
Preview features aren’t meant for production use and might have restricted functionality. These features are available before an official release so that customers can get early access and provide feedback.

Quick overview

The Manage Cloud Flow Run History in Dataverse feature provides users with the ability to efficiently track, manage, and analyze the execution history of their Power Automate cloud flows directly within Microsoft Dataverse. The cloud flow run history records are stored in FlowRun table using Dataverse’s nonrelational database, elastic tables.

Please note that only solution cloud flows (solution-aware cloud flows), with their definitions in Dataverse, can have their run history stored in Dataverse.

The documentation for the Flow Run table/entity reference is here.

Storage use for FlowRun records

FlowRun data uses Dataverse database storage capacity. By default, flow run data is stored for 28 days (2,419,200 seconds).

Set FlowRun time to live (TTL)

In Dataverse

Setting the FlowRunTimeToLiveInSeconds value in the Organization table to zero stops all ingestion of new FlowRun records.

In Power Platform admin center

The FlowRunTimeToLiveInSeconds value in the Organization table can be set in the Power Platform admin center environments experience. To choose the FlowRun entity time to live that's used in an environment:

Sign in to Power Platform admin center.
Navigate to Environments.
For the desired environment, open the Settings page.
Select Product > Features.
Under Cloud flow run history in Dataverse, set the FlowRun entity time to live retention value to 28 days (the default), 14 days, 7 days, or Disabled.

Clean up FlowRun records immediately

If your environment is low on storage, you can free up database space by configuring the TTLInSeconds value for specific FlowRun records. These records will be automatically cleaned up and permanently deleted within one to two minutes. Be certain the records are no longer needed, as deletion is irreversible.

Image

/sites/default/files/2025-01/manage-cloud-flow-run-history.png

Dataverse Elastic Tables Deep Dive Tutorial

joao.neto — Thu, 27 Jun 2024 12:46:41 +0000

Dataverse Elastic Tables Deep Dive Tutorial joao.neto Thu, 06/27/2024 - 14:46

Body

Dataverse Elastic Tables Deep Dive Tutorial

Intro

Said to be the "Super Heros" of the information world, that they're super fast and can store lots of information and that they're a game changer for storing massive loads of data.

I went to undercover what's behind the scenes of this Elastic Tables feature and check if the rumours are fake or not!

Principles and Architecture

Microsoft use Cosmos DB instead of azure SQL to store data, meaning they have a special column called Partition ID that organizes information in a "folders" like structure.

Partitioning and Horizontal Scaling:

Elastic tables use Azure Cosmos DB partitioning to scale individual tables
Each elastic table contains a system-defined Partition Id column
Rows are divided into distinct subsets (logical partitions) based on the value of the partitionid column, like storing rows per in folder by its partitionId
Choosing a consistent partitioning strategy is crucial for optimal performance

Unique References and Partitioning:

Unique references for elastic tables combine the primary key and the partitionid value
There is no limit on the number of logical partitions
If you don’t set a partitionid value, it remains null
Custom partitionid values allow multiple records with the same primary key but different partition IDs
PartitionId cannot be changed after creating a row

Consistency level

Elastic table supports strong consistency during a logical session. A logical session is a connection between a client and Dataverse. When a client performs a write operation on an elastic table, it receives a session token that uniquely identifies the logical session. To have strong consistency, you must maintain the logical session context by including the session token with all subsequent requests.

Session tokens ensure that all the read operations that are performed during the same logical session context return the most recent write that was made during that logical session. In other words, session tokens ensure that reads always honor the read-your-writes and write-follows-reads guarantees during a logical session. If a different logical session performs a write operation, other logical sessions might not immediately detect those changes.

Transactional behavior

For example, you have a synchronous plug-in step that is registered on the PostOperation stage of the Create message on an elastic table. In this case, an error that occurs in the plug-in does not roll back the record that is created in Dataverse. You should always avoid intentionally canceling any operation by throwing InvalidPluginExecutionException in the PreOperation or PostOperation synchronous stage. If the error is thrown after the Main operation, the request returns an error, but the data operation succeeds. Any write operations that are started in the PreOperation stage succeed.

However, you should always apply validation rules in a plug-in that is registered for the PreValidation synchronous stage. Validation is the purpose of this stage. Even when you use elastic tables, the request returns an error, and the data operation won't begin.

Expire data by using Time to live

Dataverse automatically includes a Time to live integer column with elastic tables. This column has the schema name TTLInSeconds and the logical name ttlinseconds.

When a value is set in this column, it defines the amount of time, in seconds, before the row expires and is automatically deleted from database. If no value is set, the record persists indefinitely, just like standard tables.

Flexible schema with JSON columns

Elastic tables enable you to store and query data with varying structures, without the need for predefined schemas or migrations. There's no need to write custom code to map the imported data into a fixed schema. More information: Developer guide: Query JSON columns in elastic tables Elastic tables enable you to store and query data with varying structures, without the need for predefined schemas or migrations. There's no need to write custom code to map the imported data into a fixed schema. More information: Developer guide: Query JSON columns in elastic tables.

Limitations

Table features currently not supported with elastic tables:

Business rules
Charts
Business process flows
One Dataverse connector for Power BI
Many-to-many (N:N) relationships to standard tables
Alternate key
Duplicate detection
Calculated and rollup columns
Currency columns
Column comparison in queries
Table sharing
Composite indexes
Cascade operations: Delete, Reparent, Assign, Share, Unshare
Ordering on lookup columns
Aggregate queries:
- Distinct value of attribute1 while orderby on attribute2 value
- Pagination when having multiple distincts
- Distinct with multiple order by
- Order by and group by together
- Group by on link entity (left outer join)
- Distinct on user owned tables 
Table connections
Access teams
Queues
Attachment

Currently, you can't add the following types of columns:

Money (MoneyAttributeMetadata)
MultiSelectPicklist (MultiSelectPicklistAttributeMetadata)
State (StateAttributeMetadata)
Status (StatusAttributeMetadata)
Image (ImageAttributeMetadata)
Calculated, Rollup, or Formula Columns
Currency
Lookup based on the Customer option

Relationships with elastic tables:

Doesn't support creating many-to-many relationships
One-to-many relationships are supported for elastic tables with the following limitations:
- Cascading isn't supported. Cascading behavior must be set to Cascade.None when the relationship is created
- Formatted values for lookup columns aren't returned when the following conditions are true
- The table that is retrieved is a standard table, and the lookup refers to an elastic table
You're using a custom elastic table partitionid value. In other words, the partitionid value is set to something other than the default value (null).
Elastic tables support one-to-many relationships, and related rows can be retrieved when a record is retrieved. Related records can't be included in a query

Also:

Duplicate detection or adding activities aren't supported
Return related rows in a query
Elastic tables don't currently support returning related rows when a query is run. If you try to return related rows
Deep insert is not supported with elastic tables. Each related record needs to be created independently
Elastic tables don't support multi-record transactions
Elastic tables also don't support grouping requests in a single database transaction that uses the SDK ExecuteTransactionRequest class or in a Web API $batch operation changeset. Currently, these operations succeed but aren't atomic

Hands-on

After the theoretical side of the elastic tables let's demystify them by putting our hands-on creating and playing with some of the standard features.

Creating an elastic table

On the Power Apps maker portal inside your solution create a new table and then select the type elastic.

In the table properties as shown in the image below we can check that some of the default table features aren't available for the elastic tables (creating activities, duplicate detection rules, connection, SharePoint document management, ...)

Exploring the elastic table Columns

Creating a new column on the elastic table has pretty much the same look & feel except for the missing options in the data type choice list (Currency, Formula, Customer Lookup).

A new option arises with the elastic tables within the data type single line of text we can now chose a new format, the JSON.

We now have our table created and let's see the aspect of some of the default columns present in it with our JSON Column in the image below.

Two new columns are present:

Partition ID: as explained above it defines the logical compartiment to store the record, it cannot be changed after the record creation
Time to Live: measured in seconds and determine the time the record will remain in the table

Considerations around the partitionid column that should meet these criteria:

The values in it don't change. After a row is created that has a partitionid value, you can't change it
It has a high cardinality value. In other words, the property should have a wide range of possible values. Each logical partition can store 20 gigabytes (GB) of data. Therefore, by choosing a partitionid value that has a wide range of possible values, you ensure that the table can scale without reaching limits for any specific logical partition
It spreads data as evenly as possible among all logical partitions
No values are larger than 1,024 bytes
No values contain slashes (/), angle brackets (<, >), asterisks (*), percent signs (%), ampersands (&), colons (:), backslashes (\), question marks (?), or plus signs (+). These characters aren't supported for alternate keys

If a partitionid value isn't specified for a row, Dataverse uses the primary key value as the default partitionid value. For write-heavy tables of any size, or for cases where rows are mostly retrieved by using the primary key, the primary key is a great choice for the partitionid column.

When querying the JSON column:

Using the the default filter in the table view only uses standard text filtering options so here we will only be able to check for the presence of strings inside the JSON but no more than this.

However great news comes with You can use the ExecuteCosmosSQLQuery message that enables to run any Cosmos SQL query directly against your elastic table and filter rows based on properties inside JSON.

So let's try it in our created table and column !

Using the WebAPI we create the following http request, also available using the Dataverse SDK for .NET:

/api/data/v9.2/ExecuteCosmosSqlQuery(
    QueryText=@p1,
    EntityLogicalName=@p2,
    QueryParameters=@p3)?
    @p1='select c.props.sc_name as name, c.props.sc_jsoncolumn as json, c.props.sc_jsoncolumn.age as age 
    from c where c.props.sc_jsoncolumn.car=@car and c.props.sc_jsoncolumn.age >= @age'
    &@p2='sc_elasticpoc'
    &@p3={'Keys':['@car', '@age'],'Values':[{'Type':'System.String','Value':'Mustang'}
    , {'Type':'System.Int32','Value': '20'}]}

where "sc_elasticpoc" is our table, the "sc_jsoncolumn" is our JSON column and c.props is the prefix on the schema name of the columns. In this prefix, c is an alias or shorthand notation for the elastic table that is being queried.

And the result is:

{
 "@odata.context":"https://orgf9a090a4.crm17.dynamics.com/api/data/v9.2/$metadata#expando/$entity"
 ,"@odata.type":"#Microsoft.Dynamics.CRM.expando","PagingCookie":"","HasMore":false,"Result@odata.type":"#Collection(Microsoft.Dynamics.CRM.expando)"

,"Result":
 [{"@odata.type":"#Microsoft.Dynamics.CRM.expando","name":"elastic 2","age":20
,"json": {"@odata.type":"#Microsoft.Dynamics.CRM.expando","name":"Paul","age":20,"car":"Mustang"}}]
}

Final considerations between Elastic and Standard tables:

Performance:

As some announcements might let us think that elastic tables offer super performance over standard tables there are some studies that shows that's not quite the reality like in the Piotr Gaszewski blog (https://piotrgaszewski.hashnode.dev/dataverse-elastic-tables) that states:

Standard Create, Update, Delete operations: takes the same or a little bit more time to execute in elastic tables than in standard ones
Multiple Create, Update, Delete operations: takes significantly less time to execute in elastic tables than in standard ones (1/2 to 1/10)
Retrieve data operations: takes 2 to 3 times longer in elastic tables than in standard ones

So elastic tables offers significantly less performance execution times when using single atomic operation, however when working with multiple records on the same request it offers some advantages.

Service API Limits:

As per MS, Elastic Tables are still exposed to the Dataverse API throttling limits and bulk operation messages should be used to increase the throughput for high volume operations.

Is security model user compatible:

MS says yes that Elastic tables adhere to the Dataverse security model using

an User or Organisation level ownership
field level security

And yes audit is also available for elastic tables!

Conclusion:

Elastic tables enlarges the table types offer in dataverse, but it's to take with caution in my opinion because these pretty tables aren't the way to go to standard development in a relation database context, since table lookups aren't available ootb and since many other table features aren't also available which reduces a lot the scope of action of these tables.

Regarding performance finally they're also not the way to go if you search for increasing CRUD performances, except using multiple CRUD operations.

So my final take on the elastic tables would be for storing large datasets of data and mainly for IoT data that would managed by a service layer capable of using multiple CRUD operations and then consuming the data on a business intelligence scheme (as an example only).

Dataverse Elastic Tables Deep Dive Tutorial

Image

/sites/default/files/2024-06/output%20%281%29.jpg