You are currently browsing the category archive for the ‘Design’ category.

I recently saw this question posted on the MS CRM Forum and I can clearly understand why this would be a requirement. When you look at fields using an advanced find you get a list of all attributes associated with the entity. This sometimes can be confusing for end users.

In the screen shot below you can see a list of all fields associated with the account record type.

Advanced Find field list

To remove fields not used on the form you will need to set the Searchable field to No on the attribute customization form. To do this you will navigate to the Settings area, click customizations, click the attributes tab and then click on the attribute you want to remove from the list. You will then need to set the searchable field to No.

The screen shot below demonstrates how do do this. You will then need to publish your changes.

customization

Once the changes have been implemented the non searchable field will not be visible in the Advanced Find field list.

Be advised that making a field non searchable will also make the field not visible in the report wizard.

Advertisements

Microsoft CRM of course does not allow you to assign a system user to multiple sales territories. There is a simple work around though. This solution might help you overcome this constraint. Simply create a new sales territory that is a contains both territories . Add the user to the new territory.

You can display dialog in MS CRM application from a plug-in. The code below is an example of a plug-in this.


using System;
using Microsoft.Crm.Sdk;
using Microsoft.Crm.SdkTypeProxy;

namespace MyPlugins
{
   public class HelloWorldPlugin: IPlugin
   {
      public void Execute(IPluginExecutionContext context)
      {
         // Call the Microsoft Dynamics CRM Web services here or perform
         // some other useful work.
         throw new InvalidPluginExecutionException("Hello world!");
      }
   }
}

You can read more about this at the URL below.
http://msdn.microsoft.com/en-us/library/dd393303.aspx

If you have custom entities in your MS CRM system, having custom icons for your custom entities will make such a huge difference to your system users. They will find it easy to recognize the entities and find it much easier to work with them. Grouping custom entities into a separate tab or renaming an existing module tab like service to “Project Management” or “Financials” also helps.

Unfortunately not all companies have in-house graphics designers to create custom icons, and not all customers are comfortable with exporting XML files to customize the MS CRM user interface (UI).

So if you want to add a bit of “Bling” to your MS CRM Server installation but don’t have technical resources then the “Microsoft Dynamics CRM Demonstration Tools” is defiantly for you.

Click here to download the tool.

Download the application and have a play with it. It is fairly easy to learn.

Good luck!

I was recently looking to build a plug-in that got triggered when two account records were merged.

The plug-in needed to read properties from both the Master record and the sub-ordinate record and to do that I needed the ID of both records.
I couldn’t find much help in the SDK or on the web.

I’ve decided to post some of the code from my plug-in on my blog, just to help anyone who is trying to build something similar.

Good luck!


using System;
using Microsoft.Crm.Sdk;
using Microsoft.Crm.SdkTypeProxy;
using System.Web;

namespace Merge_Plugin
{
	public class Plug_Merge : IPlugin
	{
		public void Execute(IPluginExecutionContext context)
		{
			Microsoft.Crm.Sdk.Moniker MasterRecord = null;
			Guid SubOrdinateRecord = new Guid();

			// Check whether the input parameters property bag contains a target.
			if (context.InputParameters.Properties.Contains("Target") &&
			   context.InputParameters.Properties["Target"] is Microsoft.Crm.Sdk.Moniker)
			{
				// Obtain the target Moniker from the input parmameters.
				MasterRecord = (Microsoft.Crm.Sdk.Moniker)context.InputParameters.Properties["Target"];
			}
			else
			{ return;}

			try
			{
				//Get the ID of the MasterRecord
				string masterId = MasterRecord.Id.ToString();
				
				if (context.InputParameters.Properties.Contains("SubOrdinateId"))
				{
					SubOrdinateRecord = (Guid)context.InputParameters.Properties["SubOrdinateId"];
					//Get the ID of the Sub Ordinate Record.
					string subId = SubOrdinateRecord.ToString();
				}
			}
			catch (Exception ex)
			{
				throw new InvalidPluginExecutionException(
					  "An error occurred in the AccountMerge plug-in.", ex);
			}
		}
	}
}

In the begining as an MS CRM consultant I was always tempted to group different types of contacts in the system togather into the contact entity and use a type picklist to filter on different types of contacts, but expirence has taught me other wise.

If you have different types of “Contacts” whos information you want to hold in the system then I highly recommend creating custom entities. I have found this to be espically critical in implementations for the Financial and Insurance industry. When you have broker contacts, supplier contacts and so forth it is a good idea to hold the information in custom entities. This makes it easy to referece these types of contacts to Policies and contacts.

Most customers ask consultants to remove the address name field from the account form. What is the point anyway of having the field on the form anyway?

Well here is the catch. If you don’t fill the address name field, MS CRM 4.0 (and 3.0 for that matter) do not create an address record in the database. What that means is that you can’t reference the address on the contract form. Or search for the address in the more address table in the database.

So if you have a customer that plans to use the service module in MS CRM, I would advise you always keep the address name field on the account form. If you the customer doesn’t want to fill the field then you can always fill the field with the company name OnSave and make it ready only.