Hannah Rubin-Burrasca CRM Support Analyst

When running a native Dynamics Import, the error 'A duplicate reference was found.' can occur where there are no duplicate records but the matching record is in an Inactive state. This is misleading and should specify that it is an Inactive record causing the issue.

This is being raised on behalf of the customer Riverside Community College District who is using the 3rd party vendor Solution Anthology Reach on top of Dynamics 365.

When viewing Data Import logs and sorting by Description column from A-Z or Z-A, the values are not sorting in alphabetical order. Ideally when sorting is enabled for Z to A, the column should display The lookup reference could not be resolved followed by A record was not created or updated because.... The sorting is not taking the first alphabet T followed by A instead takes A followed by T

See the screencast captured of this behavior: https://www.screencast.com/t/RpYipvk8UtY6

This is due to the field being a Multiple Lines of Text' formatted field. As per Microsoft support this is a limitation of this type of field (https://docs.microsoft.com/en-us/sql/t-sql/queries/select-order-by-clause-transact-sql?view=sql-server-ver15#limitations-and-restriction). Since this is not possible to do with this field then the column itself should not appear to be sortable as it causes a misconception in the products functionality.

This is specific to an example from a third party solution called Anthology Reach. The goal is to display Applications(Entity) with Decisions(Entity) based on a specific Academic Period(Entity). They wanted to include Fields from both the Contact and Decision Entity in their column headers. There does not seem to be a way to drill down across relationships to add all of the below desired columns into one View regardless of whether the Base Entity is selected as Contact, Application, or Decision. Columns desired: External Identifier (Contact), Application Name(Application), Application Submitted (Application) , Decision Status (Decision), Review Status (Application). The desired output can be done in a Report. The columns available for selection in a View do not allow Decision related columns to be added to the header due to the M:1 Relationship between Decision and Application. The customer is aware this would create duplicate rows to be returned per Contact when creating a View with Application as the Base Entity due to multiple Decisions existing for each Application. They want the data to be returned like this.