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”™
