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 trying to delete a custom public view (Test View) in Dataverse, we encountered the following error:
“The SavedQuery(<GUID>) component cannot be deleted because it is referenced by 1 other component. For a list of referenced components, use the RetrieveDependenciesForDeleteRequest.”
This usually means that the view we’re trying to delete is still being referenced somewhere else in our environment — and Dataverse is safeguarding against breaking things.
Depedencies was pointing to the Lead form.
The lead form had the campaign lookup and the test view was one of the selected views in “Allow users to change view”.
This means even if the view wasn’t the default for that lookup, the form still allowed users to switch to it, and that counts as a dependency.
Removing it from the list and publishing the changes allowed us to delete the view.
Note – Also check if it is being used as a Subgrid, if so temporarily remove the subgrid from the form to delete the view and than add the subgrid back.
Recently while trying to set Bookable Resource Booking record’s status as completed or trying to change Settings >> General >> Field Service Settings >> Time Entry, we were getting below error
We can see the Dynamics 365 Project Service Installation Failed and on retrying the installation it was giving below error.
The fix that worked here was to install the Project Operations.
Had written a post on deleting the elastic table record earlier – How to Delete Elastic Table Records in Dataverse (SDK). We need to pass the partitionid value through an alternate key to delete the elastic table records. We will have the alternate key auto-created by the system when we create an elastic table. Earlier specifying an Alternate Key was not possible for the Delete action in the CDS Destination component. However, with the latest release (Version 25.1 – April 4, 2025), the Manually Specify and Alternate Key matching criteria support has been added when performing the Delete action as shown below. We also need to have the Use Homogeneous Batch Operation Message option checked, this uses DeleteMultiple request in the background.
On running the package, now we can see the elastic table records (having partitionid) getting deleted successfully.
After the successful run (here we are deleting 40K records), we can see the records deleted.
Double Opt-In is a two-step process for email subscription:
The contact fills out a subscription form (initial opt-in).
They receive an email with a confirmation link. Only after clicking that link is their subscription considered confirmed (final opt-in).
This process ensures that the person who signed up wants to hear from us—and that the email address is valid.
Enable the Double Opt-In Feature
Below is how we can enable it in Dynamics 365 Customer Insights – Journey
Go to Settings > Feature Switches > Compliance (Double Opt-In)
Create or Configure aCompliance Profile
The Compliance Profile is what governs how consent is collected and managed in real-time marketing.
Go to Settings > Customer engagement > Compliance profiles
Here we will enable it in the existing default compliance profile. We can have different compliance profiles for different regions, languages, or purposes.
Navigate to the Double opt-in tab.
As part of the setup, the system creates the Double opt-in email and the journey required as part of the process for that particular compliance profile.
We can see it configured after a few minutes.
Below is the email created by the system that will be used for the journey generated. Notice its state will be Ready to Send.
Similarly, we will have the journey created, with Status = Live.
Link Compliance Profile to the Form
Open an existing marketing form or create a new one.
In the form editor, drag a Consent field.
In the property pane for the Consent element, select the compliance profile (default one in our case), specify the purpose, and other required properties.
To see it in action let us submit the form using the standalone page.
Till this point, we do not see any contact point consent record created.
We can see the confirmation email received in our mailbox. From there we can confirm it.
After confirmation, we can see our consent record created with the appropriate consent status.
Sometimes, we might create a new view for a table, and not everyone in our organization needs to see it — or maybe, only a specific team should have access to the existing views, now we can achieve it through security roles.
This feature is governed by the EnableRoleBasedSystemViews property, which we can manage through the OrganizationSettingsEditor tool.
Before we set the property as true, let us apply security roles to some of our views.
To apply it, select the view in the PowerApps Maker Portal and click on View Settings.
From the View Settings window, we can choose Specific security roles to apply to the views. Here we have selected the Vice President of Sales role for the All Leads Views. Save and publish the change.
Here we have repeated the same steps for the below remaining views.
Now if we open the leads view as System Admin, we can see all the views. This is because we have not yet set the EnableRoleBasedSystemViews to true.
Now let us set the property as true.
As soon as we set the property as true, we can see the views getting filtered for the System Admin user.
Only the below public view is visible. (along with the 2 private views at the top)
Now if we assign the “Vice President of Sales” role to the same user, he can then see the views on which security roles were applied.
The user can still see the remaining views through the “Manage and share views” option.
The records that the user can see in the views are still governed by security privileges.
Although the documentation mentions, that this feature only filters views in the table list view selector and not in associated grids or subgrids, we can see the same filtering applied.
Below is the Lead Associated view in the Competitor table.
When we enable the EnableRoleBasedSystemViews setting using the OrganizationSettingsEditor tool, it takes effect immediately. All table views, except the default one, start getting filtered based on assigned security roles right away. Assigning security roles to a view is also effective immediately after we save and publish the view. However, if we change a view’s access from ‘Specify security roles’ to ‘Everyone’, it might take up to 24 hours for the change to fully apply across the system.
Nishant Rana's Weblog 