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