torsdag 19 december 2013

New feature in CRM 2013 on activities

I have been struggling with a problem to relate emails to "parent email", i.e. the email you're replying to, during the past week. The upgrade to CRM 2013 made on of our solutions very much obsolete. The solution of the problem did make me happy though, good work Microsoft!

We created a solution in CRM 2011 where the sender address was set to the address of the queue the email was in instead of the user. This is very much a standard configuration of pretty much ALL ticket systems I have been working in while being a support engineer. That the service parts of CRM doesn't have this feature out of the box is a mystery to me.

The old solution was to use a queryattribute called _InReplyToId, which was the GUID of the email you were replying to. The queryattribute wasn't present in CRM 2013 and I have been looking for a solution ever since. The solution was in fact very simple, Microsoft has provided a connection to parent activity called ParentActivityId. When responding to an email this field is populated with a lookup to the original email, just add the field to the form and you can access this with regular JS code.

To set the sender address to the address of the queue you will have to look up the queue item of the parent email, and fetch the queue from that. I chose to to this with an OData call which I've grown quite fond of the past months.

I think this will help quite a lot and it's really a great feature of the new CRM.

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

tisdag 17 december 2013

Security roles impact on updated CRM 2011

Since the upgrade from CRM 2011 to 2013 some things have most definitely changed. Some of these changes seems very strange and as soon as the security roles are involved things often are a bit of a challenge to troubleshoot.

One of our customers have a customisation that adds "synchronisation users" to contacts. This is used to sync contacts to more than the owner's outlook. In CRM 2011 there wasn't a problem to add users to the contact with the N:N relation that we created, but after the upgrade they weren't able to add users to the contact.

Of course, when I logged in it was working and since I was using the sysadmin role the answer seemed to reside in the ever so funny security roles settings. It always amuses me to find the correct setting. This time I went through the roles to find the one with least privileges to try to match what was happening. The role I started off with was the CEO-role, which I started stripping of rights until I couldn't add users anymore.
Before I did this manouver I started off by guessing which rights that were needed but since that didn't help I went straight into trial-and-horror-land. The answer confused me a bit at first since the answer was to give users create rights on the user entity. When I opened the search on the quick add field I realized that there was a "new" button at the bottom which probably was evaluated before you could add an existing user.

There is some sort of logic behind this, however it would please me if the "Add existing user" button didn't need a create user privilege to be able to add an EXISTING user. The entire security role part is in my humble opinion somewhat hard to grasp and understand when you move out of the clear areas. To have to have the right to create a user to be able to add an existing one is one of the examples I have encountered during the past years but I could probably make quite a list of these examples.

Happy holidays and great new year!

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