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

Import Data (Import Data Wizard) – Few key points

Let us understand a few points about the Import Data feature with a simple example –

Say for example we have exported the following 4 records.

The exported file will have the view name along with the timestamp.

The exported file –

It has 3 hidden columns that allow for re-import of these records possible.

1^st column contains the GUID of the record, the second contains the Row Checksum which it uses to make sure to update only those records or rows which are changed, and the 3^rd column is Modified On which it uses to track if the record has been modified since it was exported.

Now let us update one of the records we exported inside CRM.

On importing the same file,

as expected we get 1 failure.

Error message – “You cannot import data to this record because the record was updated in Microsoft Dynamics 365 after it was exported” for the same record which we updated inside the app.

Now let us update one of the records (which has a possible duplicate) and re-import the file.

During import, we have let the Allow Duplicates settings be default i.e. No.

This time also apart from the previous error we get one partial failure.

The error message says – “A record was not created or updated because a duplicate of the current record already exists.“

This is because the record that was modified and imported was having another record having the same email id, triggering our duplicate detection rules. Also, we had specified Allow Duplicates as No while importing the file.

This time let us set Allow Duplicates as Yes and try the import with the same file.

As expected there was no partial error this time.

And the record got updated this time.

Another point to remember is if we export and import the file without any changes, or for the rows with no modification, it will not perform any action, i.e. trigger a create/update for any of the records.

For tracking the changes, as we mentioned earlier it uses the Row Checksum column’s hash value.

Now let’s update the GUID of the record in the 1^st row (changed b to c in the end) and the modified date (changed to 55 from 53 minute part) for the 4^th row and see the results.

As expected both these records failed – 1^st one where we changed the GUID with the error message – “The record could not be updated because the original record no longer exists in Microsoft Dynamics 365” and the 4^th row with the error that “You cannot import data to this record because the record was updated in Microsoft Dynamics 365 after it was exported” as we had changed the Modified Date in the imported excel file.

Lastly, let us restore the original value of those 2 fields of the hidden columns and try the import to see the results.

As expected we do not get any error for those 2 rows as we had restored the original value.

For .zip files 32 MB is the max size limit for other file types i.e. xlsx, csv, txt and xml it is 8 MB.

Microsoft recommends import to be limited to 20K rows or fewer.

Just in case we are interested to see how the data validation works especially for the option set field in the exported excel file from CRM.

Select the field in excel and open the Data Validation from the Data tab, which refers to the hiddenSheet.

To see the hiddenSheet, right-click the worksheet and select the View Code option.

It opens the VBA window, where we can select the hiddenDataSheet object and change its Visible property to -1-xlsSheetVisible.

Back in our excel, we can see the hiddenSheet visible and the values of our option-set fields.

Hope it helps..

Advertisements

Fixed – Unable to add record type ‘Lead’. It is invalid to create component msdyn_decisioncontract with the same export value as an existing component in Unified Routing (Dynamics 365)

Recently while trying to enable Unified Routing on Lead table/ entity we got the below error.

“Unable to add record type ‘Lead’. It is invalid to create component msdyn_decisioncontract with the same export value as an existing component“

The issue was that the we forgot to enable the unified routing on lead before migrating lead related unified routing records in that environment, from the development environment.

So as per the details in the error message, we found the below record and deleted it.

After deletion it allowed us to enabled the Unified routing on Lead as shown below.

Hope it helps..

Advertisements

Run as option in When a row is added, modified or deleted trigger – Power Automate

Let us see Run As option of When a row is added, modified or deleted trigger in action, to understand its behavior.

Below is our example flow – it triggers when a field on the case is updated and then it updates the lead record.

Here we have not specified any value for Run as for When a row is added, modified or deleted trigger step.

On updating a case record using the User 1 account who is also the Flow Owner, we can see the modified user as User 1 for the lead record.

Let us trigger the flow this time through User 2.

This time also modified by for the lead record is User 1, even though the Modifying User and Row Owner were different.

So if Runs as is not specified, the Microsoft Dataverse actions are performed using the context of the Flow Owner.

To test it further let us remove the update rights of User 1, who is the flow owner, and trigger the flow again using User 2.

As expected the flow run fails this time.

“Principal with id 7252e222-c07f-ec11-8d22-000d3a98d479 does not have WriteAccess right(s) for record with id 8ce6c6de-1bff-e411-80d4-c4346bac4730 of entity lead“

Not let us specify Run as = Modifying User this time, and trigger the flow using User 2 again. (we have restored the rights of User 1)

This time also we can see the modified by the user as User 1 (Nishant Rana) the flow owner.

For it to run under the context of the user set as “Run As” in When a row is added, modified or deleted trigger, we need to select the Use invoker’s connection setting for the Update a row step.

Let us trigger the flow again through User 2, remember we have Run As set as modifying user.

Interestingly it still shows User 1 as the Modified By user.

Let us again remove the write rights of User 1 and trigger the flow using User 2.

This time flow is successful. If you remember it failed last time when we removed the User 1 rights and the Run as was default Flow Owner.

And this time, it shows modified by as User 2. (as we can see for user 1, the record is read-only as we have the rights removed)

This time it worked because had set Run As as Modifying User and specified Use invoker’s connection for the subsequent step i.e. update a row in this case, so it used User 2’s context which modified the case record to trigger the flow, which in turn updated the lead record using user 2’s context.

Now it will fail if User 1 updates the case record and triggers the flow because it will try to update the lead record using its context i.e. Run as = modified by

We will observe a similar behavior with Run As = Row Owner.

In case the owner of the record is a team, instead of a user, then it falls back to the flow owner option.

Get all the details here – https://docs.microsoft.com/en-us/power-automate/dataverse/create-update-delete-trigger#user-impersonation-using-run-as

Also check – https://d365demystified.com/2020/10/30/run-as-context-in-cds-current-environment-flow-trigger-power-automate/

Hope it helps..

Advertisements

Fixed – Flow client error returned with status code “Forbidden” and details – MissingAdequateQuotaPolicy, the user does not have a service plan adequate for the non-Standard connection in Power Automate

Recently one of the users reported this error while trying to Test a flow.

Request to XRM API failed with error: ‘Message: Flow client error returned with status code “Forbidden” and details “{“error”:{“code”:”MissingAdequateQuotaPolicy”,”message”:”The user ‘8a47d139-662e-4b73-bca3-53a59e8bebeb’ does not have a service plan adequate for the non-Standard connection ‘Microsoft Dataverse’. https://go.microsoft.com/fwlink/?linkid=2123710″,”extendedData”:{}}}”. Code: 0x80060467 InnerError: ‘.

As here the Premium Dataverse connection was being used, the resolution was to either purchase a Per User plan or Per Flow plan or to enable the trial of Power-Automate per user plan.

After the trial was enabled for the user, the error got resolved.

Hope it helps..

Advertisements

Understanding Change limits option in Do until control – Power Automate

Within Do Until control in Power Automate we have the option of defining the limits i.e. how long the do until will run either based on count or timeout.

By default, the value for count is 60 and Timeout is PT1H which equates to 1 hour i.e. it will either run 60 times or will run for 1 hour which occurs first.

Let us set the count to 5 and test it.

We have also added the delay of 1 minute along with the condition for do until and triggering it on the update of a lead record.

As expected if the condition is not true, after running 5 times it stops successfully.

Now let us change the Timeout to 2 minute and we keep the count as 5.

As expected after 2 minutes (by that time it has looped 2 times with 1 min delay), the flow stops successfully.

The flow will also be successful when the Do until condition is met.

Here we can make use of Current Iteration Index property of Do until to find out the number of times it has looped.

To set the time out format –

https://www.digi.com/resources/documentation/digidocs/90001437-13/reference/r_iso_8601_duration_format.htm

Lastly the Count value can be maximum 5000 –

Also check –

https://nishantrana.me/2022/05/17/fixed-invalid-template-unable-to-process-template-language-expressions-in-action-template-language-expression-cannot-be-evaluated-the-template-action-is-not-defined-in-the-current-scope/

https://nishantrana.me/2022/01/19/how-to-use-do-until-and-delay-in-power-automate/

https://nishantrana.me/2022/05/19/filter-rows-and-trigger-conditions-in-power-automate/

Hope it helps..

Advertisements

Fixed – Authorization failed. The client with object id does not have authorization to perform action ‘Microsoft.Authorization/roleAssignments/write’ over scope ‘/subcriptions’ while configuring Azure Synapse Link for Dataverse

Recently while configuring Azure Synapse Link for Dataverse, for exporting data to Azure Data Lake we got the below error –

{“code”:”AuthorizationFailed”,”message”:”The client ‘abc’ with object id ‘d56d5fbb-0d46-4814-afaa-e429e5f252c8’ does not have authorization to perform action ‘Microsoft.Authorization/roleAssignments/write’ over scope ‘/subscriptions/30ed4d5c-4377-4df1-a341-8f801a7943ad/resourceGroups/RG/providers/Microsoft.Storage/storageAccounts/saazuredatalakecrm/providers/Microsoft.Authorization/roleAssignments/2eb81813-3b38-4b2e-bc14-f649263b5fcf’ or the scope is invalid. If access was recently granted, please refresh your credentials.”}