Recently while trying to import the product records in our Dynamics 365 Sales, we got the below error – “The Default Unit is not a member of the specified Unit Group”
We were providing the correct UoM Group and Default UoM in our Excel file to be imported.
After some troubleshooting, we realized that we had 2 units with the same name “Primary Unit”, because of which the system was not able to identify the correct unit to be used during the import.
To fix this issue, we replaced the Name with the Guid of the record in our excel file.
This fixed the issue for us and we were able to import the product records successfully.
While working on a LINQ query using early-bound classes in a Dynamics 365 plugin, we encountered a familiar error.
“Could not find an implementation of the query pattern for source type. ‘Where’ not found”
At a glance, everything looked fine. The query was syntactically correct, and the early-bound class was generated properly.
After spending some time, we realized that the error message wasn’t due to the query or the early-bound class itself. It was because we forgot to include the following directive:
using System.Linq;
Without this, C# doesn’t recognize LINQ query methods like Where, Select, or ToList.
Adding this single line at the top of the file resolved the issue immediately, the LINQ query compiled and executed as expected.
Recently, we had to write a small utility—a console application—that would go and update a bunch of existing records in our Dynamics 365 environment. However, we didn’t want any of my custom plugins to trigger during this update. Because the updates were internal, more like data correction / cleanup, and had nothing to do with business rules or processes enforced via plugins. Triggering them would’ve not only been unnecessary but could also lead to unwanted side effects like auto-assignments, email sends, or data syncing. Thankfully, the Dataverse platform provides us with two powerful properties that allow us to selectively bypass plugin execution logic.
BypassCustomPluginExecution – This allows us to bypass all the plugin steps for an operation – create, update, delete, etc.
BypassBusinessLogicExecutionStepIds – If we do not want to skip all the plugin steps, but just a few specific ones, we can use this property.
We have the below sample plugin registered that throws InvalidPluginExecutionException on the update of the lead record.
On updating the record through the console app, we will get the same exception.
To bypass all the plugins that are registered on Update, we can use the BypassCustomPluginExecution property as shown below.
To bypass only the specific plugin steps that are registered on Update, we can use the BypassBusinessLogicExecutionStepIds property as shown below.
One point to remember is these flags do not bypass system plugins or platform logic—only custom plugin steps we’ve registered.
This was a really handy trick in our recent utility and helped us to safely update the records without triggering the plugin. The other options could have been to either temporarily deactivate the plugin step, add certain conditions to the plugin based on calling user, flag/fields on the record etc.
In Microsoft Dataverse, calculated columns are a powerful way to derive values dynamically without the need for manual updates. However, one challenge is that plugins do not trigger directly on calculated column changes since these values are computed at runtime and not stored in the database.
Since calculated columns use/depend on other fields, we can register a plugin on the change of those dependent fields. If a calculated column Total Amount is based on Quantity and Unit Price, then we can trigger the plugin on the Update event of Quantity and Unit Price.
Let us see it in action, we have the below plugin registered in the update event.
On specifying the Formula / Calculated column as a Filtering attribute, our plugin doesn’t get triggered.
Here we updated the Unit Price, which changed the Total Amount, but we do not see any trace log generated.
Now we have updated the filtering attribute to be Quantity and Unit Price the field used by the Calculated column.
We updated both the Quantity and Unit Price and see the log generated i.e. plugin triggered.
The trace log –
While plugins can’t directly trigger on the calculated column changes, this workaround ensures we still get the desired automation.
Recently while trying to invoke the HTTP Request trigger, on passing the token we got the below error from the Postman
{
"error": {
"code": "MisMatchingOAuthClaims",
"message": "One or more claims either missing or does not match with the open authentication access control policy."
}
}
Turned out that we missed the trailing slash for the resource’s value while generating the token.
Recently we observed that our plugin registered on the Delete message of appointment on the PreValidation stage was not getting triggered when we were deleting or updating the occurrence of the Recurring Appointment.
For both of the below operations, our plugin was not getting triggered. The plugin had the logic to delete a few associated records to the appointment record.
Delete operation – This deletes all the existing appointment.
Recurrence Update –This deletes the existing appointment and creates new appointment records based on the new recurrence.
On trying out different things, we saw that the plugin was getting triggered if registered on the PreOperation.
For testing, we registered a sample plugin that throws the InvalidPluginExecutionException and saw it getting triggered in case of PreOpertaion as shown below.
Nishant Rana's Weblog 