Solution import issue after 2022 Release wave 1

 

If you’re having issues importing solutions at the moment getting weird error messages like “Import failed: The evaluation of the current component(name=msdyn_knowledgemanagementsetting, id=33c540e8-76a5-ec11-983f-00224884c290) in the current operation (Delete) failed during managed property evaluation of condition: Managed Property Name: ismanaged; Component Name: msdyn_knowledgemanagementsetting” it might be an issue with the latest wave and the solution is not super straight forward.

I was trying to do an import yesterday and got this error and was mighty confused since I was sure there was no knowledge managing at all in the solution. The next thing I did was unzipping the solution and going through the xmls, that’s customizations.xml and solutions.xml, to see if there was a “msdyn_knowledgemanagementsetting” present in it, which there wasn’t.

Ok, next step was creating a support ticket. No next step is to ask on Facebook and I got a quick reply from the CRM group there where the response was “is the release wave installed in both systems?” and yes both environments have the latest release wave installed.

Now I created a support ticket and got a lightening speed response with “It’s a known issue, a patch is coming". The workaround is to set the knowledge management to enabled on the table that is causing the issue. In my case this was the product table so solution time!

 Unzip the solution and find the table tag in the customizations.xml looking like this: for <entity Name="Product">.

Under that row you should find this somewhere: <IsKnowledgeManagementEnabled> and change this: <IsKnowledgeManagementEnabled>0</IsKnowledgeManagementEnabled>
to this: <IsKnowledgeManagementEnabled>1</IsKnowledgeManagementEnabled>

 

Re-zip the solution and import, happy days.

This is a solution proposed by Microsoft support so it should be reliable, it worked for me so I thought I'd share it so you might not have to raise a ticket even if Microsoft support was mighty quick.

 

Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se  

 

Count records in a table

 

It’s been a known issue since forever that you don’t know how many rows (records) there is in a table (entity) once the count is larger than 5000 since Microsoft in it’s infinite wisdom chose not to implement the counting of rows larger than 5000.

The usual solution from way back was to push the number of rows exported to Excel to half a million or so and then export the relevant records from advanced find and see how many rows were present in the excel file.

Jump to 2021, or maybe 2020 I’m not really sure. In the Webapi there is now a function that, supposedly, return the recordcount, note that it doesn’t return the number of rows.

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/web-api/retrievetotalrecordcount?view=dynamics-ce-odata-9

That’s the docs page of this function and you pretty much do a call like “https://contosocrm.crm.dynamics.com/data/api/v9.1/RetrieveTotalRecordCount(EntityNames=['account'])” if you want to see the number of rows in the account table.

According to the documentation, this is supposed to give you the number of rows “from a snapshot within last 24 hours.”. This is maybe the only issue, but probably not. In quite a lot of cases I’ve seen the data is quite static but the return number if WAY off.

This is a shame, really, since the function is really nice to have and very practical since you don’t have to do something else like doing some magic in PowerBI, creating you own console app or using another tool like https://www.xrmtoolbox.com/plugins/Fic.XTB.FastRecordCounter/.

I wonder why the chosen implantation is set to work “on a snapshot from within last 24 hours” when you can use the xrmtoolbox tool to count the live data, or PowerBI even if will chew away at your entitled precious API calls. Too bad it isn’t implemented in a way that is usable for real.
I'm not even sure that the snapshot-part is the issue but I tested this on a customer system that's about to go live to see how the migration was going and the answer for account was 65k and when a colleague did the check using PowerBI the amount was 105k so I wonder what user scenarios this can be usable at all in.

 

Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se  

 

Automatic Record Creation Rules (ARC) – The good, the bad and the ugly

ARC has been around for quite some time and has changed shape a bit lately. No more the pretty gruesome “sort of workflow creating of incident” (or case as the rest of the world would say), not that I’m always a fan of flows, but you can at least do more stuff nowadays.

 

The Good

You can actually control very much what happens now with the flow bit. There are different functions you can use to “de-html” the incoming email body which was a nightmare earlier. You can also do very much logic for example not creating a case if you can find the incoming email address on multiple rows (or records as the rest of the world says), one thing I’ve just implemented for a customer.

The Bad

Ok, the real reason I’m writing this article is what I just realized, and it’s because a colleague of mine, Sebastian, pointed out a weird effect he saw. He had just implemented an ARC where an incident wouldn’t be created if the email address contained “noreply”, a quite fair rule IMHO. He thought that if the ARC just didn’t touch the email, it would remain in the queue so someone could handle it as an email.

He was wrong.

At first, I thought this was a bug or a oversight but it turns out that someone in Redmond has hatched the idea that an email shouldn’t remain in the queue if there is an ARC on the queue for emails even if the email doesn’t match the criteria of the ARC. According to https://docs.microsoft.com/en-us/dynamics365/customer-service/automatically-create-update-records?tabs=customerserviceadmincenter you have this nugget: 

There are so many things that I want to write when I see this, and many of them are probably inappropriate. I will just give you this youtube link to express what I’m feeling https://www.youtube.com/watch?v=4JkIs37a2JE

I didn’t quite see it since the solution I’m working on comes from an old setup where the queue item views didn’t filter on “active queue items” so all were visible. This leads to another issue but that’s not relevant for this article 😊.

I was about to post a “fix this please” but that has already been done, please vote on this: https://experience.dynamics.com/ideas/idea/?ideaid=b6b50504-668d-ec11-b820-0003ff45e08a

I have no idea who Christan Buck is, but I have his back on this one.

The Ugly

I don’t know if this classifies as ugly, but it was such a snappy title I guess I have to come up with something. It’s part of the issues we are seeing with deployment of flows which hopefully are getting better and part the old “lines in dev doesn’t always have the same id as other environments”.

When deploying ARC to other environments you who are doing the deployment gets to be the owner of all lines and you can’t really change it in any sensible fashion. This will hopefully be remedied by having application registrations own the records  (I don’t know what the rest of the world calls these but it’s a BAD NAME, pun intended for you that are old enough to get it. Service principle or even the old “Application user” makes more sense).

Number two, if you actually have been a good boy (in my case) and have the queues in all environments having the same Id, can’t that part join the deployment?

 

Please vote on Christian’s idea, we need this. This is yet another example of “Microsoft doesn’t seem to ever have worked with their own products in real life”™

Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se