I wanted to use
Xrm.Webpi methods inside a web resource loaded into a new window however I ran into a limitation on how CRM implements their internal methods.
The following describes how I attempted to troubleshoot this issue and how I eventually implemented a work around
I was working on an issue with Duplicate Detection reported by a customer. They had duplicate detection enabled on Contact with rules detecting records with the same firstname and lastname.
The steps they were following were:
The problem they were reporting was that when they entered the second “John Smith” the duplicate detection dialog was appearing; however, the dialog was not showing the potential duplicates.
Now because the same user was creating both Contact records, we thought it wasn’t a security issue, but we were only partially correct – it was a security issue but not related to Contact
The underlying problem was that the Duplicate Detection Rule was created in a different Business Unit and the user’s Security Role didn’t have Organisation-level read for Duplicate Detection rules. So CRM knew that a duplicate existed, but the user didn’t actually have permission to view the results.
The fix was simple: extend the user’s security role to include Organisation-level read permission of Duplicate Detection Rules.
Another fix for connecting to CRM 365.
I had a CRM ConnectionString that had previously been working but after an update to Dynamics 365 no longer worked. There didn’t seem to be any exception and the LastCrmError property didn’t contain anything helpful.
This article describes my solution to an intermittent connection problem when using IIS Express to connect to CRM
I recently came across a problem where, despite using Business Rules to clear an attribute’s value in the past, it was not available for a specific field.
Added in a CRM 2015 Update, Business Rules can be used to clear field values by completing the following steps:
I recently came across this problem looking at a CRM instance that had been upgraded to use early-binding. They had done something like below:
var accountInputParameters = ((Entity)context.InputParameters["Target"]).ToEntity<Account>();
This takes the InputParameters (which is of type Entity) and then bound it to the Account early-bound type.
While this seems like a good idea on the surface, as it allows all the fields of the Account to be accessed using strongly typed properties, the customer reported some strange behaviour on their Accounts.