Thursday, October 13, 2016

How to modify the Quick Create form for tasks and activities

This is one of those post that will explain a problem we have in CRM but unfortunately there is no great solution I know so far for this problem.

When you insert the social pane in a given entity, you will notice that there is a quick way to add activities (phone call, task, etc.) were the user does not have to leave the screen in order to add these records:



This makes the user experience great for adding tasks to a given record quickly. However, while this is beautiful for customer demos, in real life things are rarely this simple. For example, we’ve had to add another required field on the task called “Task Type”, but how can I add this field on this form?!


Things that I have tried:

1.       Modify the quick create view on Task entity. However, there are no “Quick Create” forms on task entity:




2.       Try to see if the Quick Create forms are defined at the parent entity “Activity”. However, this entity has no forms defined since it is a special entity:



3.       Then I thought maybe I can create my own quick create form in the task entity and set the form priority higher so it supersedes the one that comes out of the box. However, when I check the Quick Create form order I can only see my form:



It seems like the out-of-the-box quick create form is completely hidden. When I publish my changes and look my new form is not really used

4.       Then I thought maybe we can remove “Add Task” from the social pane so that users would be forced to add tasks the old way and be able to use the form we need. However, the Social Pane is not very configurable and the only things that can be set is whether to show Activities or Notes by default, which is really not useful.



So this actually forced us in some cases to remove the social pane all together and go back to the sub-grid approach. However, if you need to capture notes then you might be out of luck!

Also note that in the Quick Create menu in CRM, when you try “Task” it will actually open the default full form, rather than any Quick Create form that you define, so you have control but you cannot leverage the quick create feature for activities apparently.



We also tried to hide the activities from appearing in the quick create menu but this was not possible because you cannot unselect the setting to show activities in the quick create menu. This is perhaps one of the most annoying things with quick create and stems from the fact that Microsoft has locked down the configurability of this feature which often just renders it useless in the real world but only pretty for customer demos. This sadly seems to be the case for many features that are also locked down for extension or configurability. If you have any workaround I’d be very happy to hear!





Thursday, October 6, 2016

Transporting SLAs in a CRM solution

This post explores some of the nuisances when transporting SLAs in a CRM solution. I did most of my tests in CRM 2015 and CRM 2016 environments but behavior might vary between different versions.

When you include an SLA to the solution there are some special things that will happen. In this example, I have a blank solution and I have added only my SLA to the solution. As expected, the only component in the solution is the SLA itself:



However, after you export the solution for the first time, you will notice that magically some processes get added to your solution automatically after export without any indication that this has happened:


Furthermore, in older versions of CRM (2015) you will also see that the “Process”, “Case” and “SLA KPI Instance” entities get added to the solution magically which can be quite confusing:



But why is this happening? The reason why you see some processes added to the solution is because SLAs are implemented as CRM processes (workflows) behind the scenes, so at the moment you export an SLA, you need to export at the same time the process definitions for the SLA. There wil be one process per SLA plus one additional process for each SLA Item you have added to your SLA (1 item in my example). That is because SLA Items are also implemented as workflows. Now, the question of why we have to surface these implementation details to the user is in my opinion a bug, there is no reason to show the user these components in the solution and should be hidden because they are implementation details of the SLA that happen behind the scenes and causes confusion more than anything about what these processes are. If you try to open one of these processes you will notice that they are read only and completely system managed depending on the SLA and SLA Item definitions that you have provided in the user interface.

Another problem with such implementation is that if you rename the SLA Items, then their corresponding workflow/process is not renamed accordingly which can cause even more confusion since they will keep the original name that was given to the SLA Item during creation. I have even run in a situation in which solution export fails because it could not find the corresponding SLA Item process once I had renamed the SLA Item (although I was not able to reproduce this problem consistently).

The reason why you see the “Case”, “Process” and “SLA KPI Instance” entities added to the solution in CRM 2015 is most likely a bug and something that was fixed in CRM 2016. Even if you remove these entities from the solution, they will get added back automatically next time you export the solution so not worth trying to remove them manually!

Another thing I wanted to explore is how the Business Hours get transported in the solution. For example, I have defined my business hours as follows:



I have found out be inspecting the solution XML that the business hours are not included at all in the solution, therefore when you transport the SLA to another environment the business hours will be blank for the given SLA. You will then need to set it manually in the target environment. I have researched whether I could use the Configuration Migration utility that comes with the SDK in order to migrate business hours and include in the solution deployment package but as it turns out both the Business Hours and the Holiday Schedule are implemented as entries in the “Calendar” entity which is not supported by the Configuration Migration tool, and AFAIK is also not possible to import these using Excel import file. Therefore, you have no option than to re-create these records in your target environment (manually or automate via SDK) and link them to the existing SLA. You might be able to import the individual “Holiday” records to the Holiday Schedule in an automated fashion such as import but I have not validated that far what can be done.

Luckily creating the Business Hours and Holiday Schedule is not a very long task, and you should be able to create them only once in each target environment. After than re-importing an existing SLA should preserve the link to the Business Hours you had set previously.