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  

 

Name changes in the application we no longer know what to call.

I might have overdone the namecalling a bit now but it makes things a bit less easy. When I started working with the application it was called Microsoft Dynamics CRM which made searching for information quite easy, most of the time you just searched for "CRM <version>" and what your issue was and you got quite good results.

Sometimes I just get a bit disheartened by the application.
Today I did the first customization after the latest name change and I get to pick field type "choice" or "choices". Not much information so I turn to Google with "dynamics 365 choice choices".
That search didn't go well, or, the search did just fine but the results weren't really helping me. SO I modify it to "dynamics 365 column type choise choises" and the first hit is this page https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/customize/types-of-fields
which tells me that I can use optionset or multiselect optionset.
I suppose "choices" is multiselect optionset, which somehow sounds a bit more intuitive than "choices".

Call me old.

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

 

Read Only setting in Dynamics 365, the product formerly known as CRM

 

I had a discussion about a setting called “Read only in Unified Client” with a couple of people on the Facebook group “Microsoft Dynamics CRM” (good group if you are into the trade) a few weeks ago after Tejesh Sharma posted a blog about this setting .

The blog post is here: Make D365 CRM Entity as Read only and my comment on Facebook was “Why on earth is this even an option? Who made up this setting and what is any perceivable application?”
Now I want to be clear, the comment has NOTHING to do with Tejesh’ post which is good, the comment is why did someone actually come up with the idea in the first place.

On to the issue. Microsoft has implemented this with some update of the system. We had a customer that complained that they no longer could create products and my initial thought was that there’s some mixup with licenses and the UI app.

I wasn’t completely off, there was an issue with the app, but not in the way I originally thought. When I opened a product form it clearly said that it was read only so I went into the solution (using the classic one, I know, but it works…)

Lo and behold, the Read-only in Unified Client was set. This is nothing we’ve done, or the customer and it was present in production as well as in development. The picture is not very educational because I made it after turning it off, but it was set to true, I promise. The only entity that had this turned on was product, or at least the only entity that the customer is using so it's not turned on for everything in this case.

So if you run into an issue with customers saying they can’t edit or create objects, have a look if this setting has been turned on. If you need any help with how to do it, have a look at the blog linked above!

 By the way, there should be a symbol to use for the product formerly known as Microsoft Dynamics Customer Engagement Enterprise Edition, like Prince. In the words of the big poet Weird Al Yankovic, Never write words as numbers, unleass you're 7, or your name is Prince!

Hope this helps someone, both the text and Weird Al's lyrics.

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