Microsoft Dynamics CRM – Page 2 – Nishant Rana's Weblog

Updating Records Without Triggering Plugins – Bypassing Plugin Execution in Dynamics 365 / Dataverse using C#

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.

A screenshot of a computer

AI-generated content may be incorrect.

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.

A screenshot of a computer program

AI-generated content may be incorrect.

To bypass only the specific plugin steps that are registered on Update, we can use the BypassBusinessLogicExecutionStepIds property as shown below.

A computer screen shot of a computer code

AI-generated content may be incorrect.

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.

Also check – https://nishantrana.me/2023/11/08/use-tag-parameter-to-add-a-shared-variable-to-the-plugin-dataverse-dynamics-365/comment-page-1/

Hope it helps..

How to Trigger a Plugin on a Calculated Column Change in Dataverse / Dynamics 365

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.

Calculated field considerations

A screenshot of a field

AI-generated content may be incorrect.

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.

A computer screen shot of a program

AI-generated content may be incorrect.

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.

A computer screen with a green arrow pointing to a white box

AI-generated content may be incorrect.

The trace log –

While plugins can’t directly trigger on the calculated column changes, this workaround ensures we still get the desired automation.

Hope it helps..

Fixed – MisMatchingOAuthClaims – One or more claims either missing or does not match with the open authentication access control policy error – OAuth Authentication for HTTP Request trigger (Power Automate)ismatch

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.

Audience values as expected in the claim.

A screenshot of a computer

Description automatically generated

https://jwt.io/

On correcting the resource value, and using the new generated token,

fixed the mismatch claim issue

Below is our flow

Refer – https://nishantrana.me/2025/01/28/configure-oauth-authentication-for-http-request-triggers-specific-users-in-my-tenant-power-automate/

Get more details

Hope it helps..

Advertisements

Fixed – Delete Plugin on Appointment not firing for operation on Recurring Appointment (Dataverse / Dynamics 365)

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.

Hope it helps..

Advertisements

Fixed – Real-time marketing form’s Standalone page submitting to a different environment – (Dynamics 365 Customer Insights – Journeys)

Recently we migrated the Real-time marketing forms from our Dev environment to UAT environment using the Configuration Migration Tool. Here what we noticed was on submitting the form using the standalone page in UAT, the submissions were going back to the Dev environment instead of UAT.

This was because the data-form-api-url and data-cached-form-url property of msdynmkt_standalonehtml field of msdynmkt_marketingform record was still referencing the organization id of the Dev environment instead of UAT.

A computer screen shot of a computer screen

Description automatically generated

<div data-form-id='167fce01-b674-ef11-a671-002248e36298'
data-form-api-url='https://public-oce.mkt.dynamics.com/api/v1.0/orgs/f69f1cea-23d9-446f-9130-ed45ce666b28/landingpageforms'
data-cached-form-url='https://assets-oce.mkt.dynamics.com/f69f1cea-23d9-446f-9130-ed45ce666b28/digitalassets/forms/xxxfce01-b674-ef11-a671-002248e36298' ></div>

The f69f1cea-23d9-446f-9130-ed45ce666b28 is the development environment’s organization ID.

This information is stored in the msdynmkt_standalonehtml field of msdynmkt_marketingform record.

select msdynmkt_marketingformid,msdynmkt_standalonehtml,* from msdynmkt_marketingform where msdynmkt_marketingformid = ‘formGUID’

To fix we replaced the Dev’s Organization ID = f69f1cea-23d9-446f-9130-ed45ce666b28 with UAT’s Organization ID = dd628e4e-ffd7-ed11-aecf-002248932ace

<div data-form-id='167fce01-b674-ef11-a671-002248e36298'
data-form-api-url='https://public-oce.mkt.dynamics.com/api/v1.0/orgs/dd628e4e-ffd7-ed11-aecf-002248932ace/landingpageforms'
data-cached-form-url='https://assets-oce.mkt.dynamics.com/dd628e4e-ffd7-ed11-aecf-002248932ace/digitalassets/forms/xxxfce01-b674-ef11-a671-002248e36298' >

And updated the marketing form record.

Red text on a white background

Description automatically generated

update msdynmkt_marketingform
set msdynmkt_standalonehtml = '<div data-form-id=''067fce01-b674-ef11-a671-002248e36298''
 data-form-api-url=''https://public-oce.mkt.dynamics.com/api/v1.0/orgs/dd628e4e-ffd7-ed11-aecf-002248932ace/landingpageforms'' 
 data-cached-form-url=''https://assets-oce.mkt.dynamics.com/dd628e4e-ffd7-ed11-aecf-002248932ace/digitalassets/forms/067fce01-b674-ef11-a671-002248e36298'' >
 </div><script src = ''https://cxppusa1formui01cdnsa01-endpoint.azureedge.net/oce/FormLoader/FormLoader.bundle.js''></script>'
where msdynmkt_marketingformid = '067fce01-b674-ef11-a671-002248e36298'

After the update we can see submission reflecting back to the correct UAT environment.

The query we used to update all the forms with UAT’s Id

-- replace Dev Org ID with UAT Org ID in all the marketing forms 
UPDATE msdynmkt_marketingform
SET msdynmkt_standalonehtml = REPLACE(msdynmkt_standalonehtml, 'f69f1cea-23d9-446f-9130-ed45ce666b28', 'dd628e4e-ffd7-ed11-aecf-002248932ace')
where msdynmkt_standalonehtml is not null

Hope it helps..

Advertisements

How to deal with the Calculated columns having Null values (Dynamics 365 / Dataverse)

Suppose we have the following whole number fields, where Field C is the calculated column and is the sum of Field A and Field B

A screenshot of a contact form

Description automatically generated

Field C calculated column –

However, if any of the fields used for calculation is null, Field C will also show null.

The way we can resolve it is to put a null check in the formula.

We have created a new calculated column with the below definition.

The other option that we can consider is using JavaScript / Business Rules / Additional Calculated Columns to set the default value to 0 in case of null, for the fields being used for calculation.

In the case of 0 also, the calculated columns will work properly.