Archive for November 2011

CRM 2011 Solutions – Problems & Best Practice

Hi,

As you may (or many not) know i have been working on our largest CRM implementation which also happens to be out first large scale CRM 2011 implementation. As such, we have started working with solution files!



First of all, I would like to say that I really love the concept of solution files. Making changes for either support or development purposes on clients CRM systems in CRM 4 felt very clumsy and poorly controlled. The introduction of solutions dealt with this in a way that feels much more professional. However, the question arose, what is the best practice for using solutions?

The Problems

Surprisingly, i couldn't see many (if any) articles or details on this. So we started out by, on our development environment, creating a solution file using the client name and using the version number to control this. We added all the existing system components and made changes to these as we went along. However, the problem with this is that development felt a bit cumbersome. You couldn't use the native “Customise” tab on forms as this edited the default solution as well as the fact that all members of the team had to remember to stick to the solution only and not do this.

We also had major issues when applying the solution that came from the way our solution was interacting with another managed solution. We installed our main solution on one of the clients servers after which, we installed the brilliant eCampaign (great email marketing extension for Dynamics CRM 2011) on the one of the clients servers. The problems started when we subsequently made changes (by creating another solution file) on this server.

When we tried to export our solution file, we were quite rightly warned that components were missing. So, we added the components. We did this until it appeared that all the required components (including those used by the managed eCampaign solution) were included. When we tried to import the solution into our Dev environment it failed because, you guessed it, we couldn't import components of a managed solution! So, we went back, removed all components of the managed solution, re-exported ignoring the warnings about missing components. When we tried to import it into our Dev environment………it failed because of missing components!!! The only “solution” was to edit the XML solution file, something we were very uncomfortable with at this stage.

Now, i know what your thinking. Why on earth are you developing on a client server!! And, to be honest your right. It was necessary at the time but bad practice which brings us back to what should be our future practice. For those of you interested, the way we got around the above situation was to ask the vendor (eCampaign) to uninstall the managed solution, export our solution file (which now no longer required the missing components) and reinstall the managed solution after.

The Best Practice (Well…according to me anyway)

So the moral of the story (or what we have learned so far is…)
  1. Create a Deployment for your Client on your development environment
  2. Develop in the “Default Solution”.
  3. When ready to deploy on your client server, you have 2 choices:
    • Export The Default Solution – If this is exported as managed, then when imported it will show as “Default Solution” in the clients list of installed solutions. If it is exported as unmanaged, it will overwrite the existing default solution and as such, wont appear in the clients list of solutions.
    • Create A New Solution & Add The Relevant Components – When exported either as managed or unmanaged, it will show in the solution list.
  4. For small changes you also have 2 choices:
    • Create  A Single Solution File With Relevant Components – Create a solution file with a relevant name (i.e. ClientName Updates 2011) and add the relevant components. Every time the client wants changes made, create a solution with the same name but different version number on your Dev environment and when importing as a managed solution, it will update the existing solution. You can of course always do this with your solution file created in step 3 with the same results.
    • Create Multiple Solution Files For Each Change Batch – Create a solution with a unique name and install on your clients environment.
  5. For major changes, i would go through step 3 again.
  6. When working with other managed plugins, always uninstall them from your Dev environment before exporting your solution.
Of course, all of the above is only what i have learned so far and my opinion on best practice. It would be nice to see some more on this so that CRM developers can share methodology for the above, but for now, this is the approach i will take. As it changes (as i am sure it will) i’ll keep you up to date!

Thanks

J
Tuesday, 29 November 2011
Posted by XRM Consultant

Set Default Activity Values – Duration, Date & Time

Hi All,

Ok, so first of all apologies for going quiet over the past few months! (Again!). I have just delivered the biggest CRM project that Chorus IT has ever delivered! This has been a huge success (with plenty lessons learned also!). Customer happy, seeing real tangible value and really excited about how MS Dynamics CRM 2011 is going to revolutionise their business.

As part of the development process, i have come across numerous interesting bits of JavaScript etc. that have helped me overcome certain issues and now we are coming to the conclusion of the project i will be blogging these over the coming weeks. I will also be thanking (if i can remember) those whose blog/tweets helped me come to the solutions i used along the way…

So, to begin… Setting Default Activity Values – Duration, Date & Time.

The system we built for our client is being heavily used to record activities for large sales teams. With a target of 100 calls a day in mind, any little pieces of data entry we could shave off would help hugely. One of these was the fact that every time they made a phone call they had to enter the duration (which on average was 2 minutes") and set the date and time to the current date and time.

Duration:

This was no where near as easy as i expected it to be. As you know, the duration field displays as an option set (dropdown) of values. As such you would think it would be easy to add values to this…………not so! This field is in fact a “Whole Number” field!
image_thumb1
After very briefly considering editing aspx files etc, stumbled across a comment from Donna Edwards MVP that noted the fact that you can enter a numerical value in here. This got me thinking, rather than add the option to the list, could i simply populate it via JavaScript and allow the field to do its thing and display it correctly?
It worked!
I used the following JavaScript to populate the value (using a Whole Number of course) and had the following results…
Xrm.Page.getAttribute("actualdurationminutes").setValue(null);

image_thumb4


Date & Time

In contrast with the above, this was much easier than i thought. I found a post of the website of the legendary Sonoma Partners that dealt with this for the specific circs I was looking for. It utilises the JavaScript Date() function to retrieve the current date and time and populate this in the relevant field as follows with the following results…
Xrm.Page.getAttribute("scheduledend").setValue(new Date());

image_thumb6


Only OnUpdate…

The only drawback to auto-populating these during the OnLoad event is that it will, of course, fire every time the page is loaded. This can be got around by referencing the form type when firing the JavaScript OnLoad as follows...
function datetime()
{
var CRM_FORM_TYPE_CREATE = 1;
var CRM_FORM_TYPE_UPDATE = 2;

switch (Xrm.Page.ui.getFormType())
{
case CRM_FORM_TYPE_CREATE:
Xrm.Page.getAttribute("actualdurationminutes").setValue(null);
Xrm.Page.getAttribute("scheduledend").setValue(new Date());
break;

case CRM_FORM_TYPE_UPDATE:
// do nothing
break;
}
}


Hey presto! This meant that on creation of a phone call activity the script runs but not on any other occasion.
Hope this helps and stay tuned for some more interesting bits to come!

Thanks

xRM Consultant
Tuesday, 22 November 2011
Posted by XRM Consultant

Search This Blog

Popular Post

About xRM Consultant.com

Having worked with Microsoft Dynamics CRM 4.0 in a sales & development environment, my focus now is on customising this awesome solution and showing its true potential.
Powered by Blogger.

- Copyright © xRM Consultant -Metrominimalist- Powered by Blogger - Designed by Johanes Djogan -