Monday, September 14, 2009

Add Shortcut button for new Activity on CRM toolbar

Some time back we had posted a script that would allow you to create an ISV button to bring up the new activity form (phone call, appointment etc).

Recently we had the same request from one of our customers and we were quick to offer them the same. Unfortunately it failed. The locAddActTo function is not available on main CRM form.

To get this done, we had to provide the following alternate script


<Button Icon="/_imgs/ico_16_4210_d.gif" JavaScript="window.open('/activities/phone/edit.aspx','null','height=500px,width=800px,resizable=1,status=yes,toolbar=no,menubar=no,location=no')"> <Titles> <Title LCID="1033" Text="New Phonecall" /> </Titles> <ToolTips> <ToolTip LCID="1033" Text="Create New Phonecall" /> </ToolTips>

</Button>

Tuesday, September 1, 2009

Sales Quotas for Sales Person in Dynamics CRM

One of the not so widely discussed features of Dynamics CRM is the Sales Quota. You are bound to have missed this feature unless you have completed the Fiscal Year settings of the CRM organization.

To set the fiscal settings of the system, Go to settings Business Management and click on the Fiscal Year Settings.

Suppose you have set the following setting shown in the below screenshot.

Once the fiscal settings have been defined, the Sales Quota option is available on the System User record for settings the Sales quota of a Salesperson based on the first period settings.

You can set the Quotas for different fiscal periods as shown in the below screenshot. The fiscal period displayed in the below screen depends on the fiscal period settings in the above screen.


The Current Fiscal year tab will display the Current Year quota defined for the particular Salesperson.

Though CRM provides a way to define the Sales quota for a Salesperson, it ends at that and there is a lot left to be done in this area. They have not provided for any Actual/Quota comparison that would be considered essential once the Quota has been defined. There is a lot of scope for developing this functionality further through add-ons.

Friday, August 28, 2009

How to convert a RetrieveMultiple query written Server side to SOAP message to be used in Javascripts

It has often been seen that a RetrieveMultiple query that is very easy to write using the server side Query Expression objects using CRM webservices becomes difficult to achieve if we need to create a SOAP message for the same.

In this article we hope to explain each of the elements involved in the writing of SOAP messages to be used through Javascripts.

Let us take a simple RetrieveMultiple code as an example.

While writing the SOAP message the first component required is the SOAP envelope. This is the same at all times for all SOAP messages.

"<?xml version='1.0' encoding='utf-8'?>"+
"<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'"+
" xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'"+
" xmlns:xsd='http://www.w3.org/2001/XMLSchema'>"+

Next we need to add the Authentication Header that needs to be passed along with the SOAP message for successful authentication with the CRM Web service. CRM has an inbuilt function GenerateAuthenticationHeader() that can be used for this purpose.

var authenticationHeader = GenerateAuthenticationHeader();

SOAP Body is where the actual SDK message to be executed is included.

"<soap:Body>"+

In our example we are using the RetrieveMultiple Message so we provide the Message name and the schema reference to the CRM webservices

"<RetrieveMultiple xmlns='http://schemas.microsoft.com/crm/2007/WebServices'>"+

The parameter to a Retrieve Multiple Message is always a query expression

QueryExpression query = new QueryExpression();

"<query xmlns:q1='http://schemas.microsoft.com/crm/2006/Query'"+
" xsi:type='q1:QueryExpression'>"+


Now include all properties of the Query object that you set.

Entity name

query.EntityName = EntityName.incident.ToString();

"<q1:EntityName>incident</q1:EntityName>"+

Column Set

query.ColumnSet = new AllColumns();

"<q1:ColumnSet xsi:type='q1:ColumnSet'>"+
"<q1:Attributes>"+
"<q1:Attribute>title</q1:Attribute>"+
"<q1:Attribute>incidentid</q1:Attribute>"+
"</q1:Attributes>"+
"</q1:ColumnSet>"+

Criteria

ConditionExpression condition = new ConditionExpression();
condition.AttributeName = "title";
condition.Operator = ConditionOperator.Like;
condition.Values = new string [] {strSearchText};

"<q1:Criteria>"+
"<q1:FilterOperator>And</q1:FilterOperator>"+
"<q1:Conditions>"+
"<q1:Condition>"+
"<q1:AttributeName>title</q1:AttributeName>"+
"<q1:Operator>Like</q1:Operator>"+
"<q1:Values>"+
"<q1:Value xsi:type='xsd:string'>"+searchtext +"</q1:Value>"+
"</q1:Values>"+
"</q1:Condition>"+
"</q1:Conditions>"+
"</q1:Criteria>"+

Here, we have used 'Like' condition operator, likewise one can use any of the sdk supported operators and change the values to be matched accordingly.


Order by

OrderExpression oe = new OrderExpression();
oe.AttributeName = "title";
oe.OrderType = OrderType.Ascending;
query.Orders = new OrderExpression[]{oe};

"<q1:Orders>" +
"<q1:Order>" +
"<q1:AttributeName>title</q1:AttributeName>" +
"<q1:OrderType>Ascending</q1:OrderType>" +
"</q1:Order>" +
"</q1:Orders>" +

Once you have set all of these… your SOAP message is ready for execution.

Wednesday, August 26, 2009

How to Bulk Edit Attributes that show up Disabled on the Bulk Edit Form

We came across this really tricky situation and we would like to thank Microsoft for having a KB article (http://support.microsoft.com/kb/949941) for this.

We wanted to bulk edit a few of the accounts using the Actions => Edit option. The form that comes up here displays all attributes available for the Account entity. You would however notice that some of them are disabled though. Since we had 2 custom picklist type of attributes, one showing up as enabled the other disabled, it was easy to identify the possible reasons for disabling this one had custom code written on its onchange event while the other did not.

But we still wanted to be able to Bulk Edit this attribute without having the need to create a custom page just for editing a custom picklist attribute. Our search lead to the following KB article that explains the steps to enable this.

To have this explained in short, the entity customization file has a property “BehaviourInBulkEditForm” for the event tags. This determines the behavior of the attribute and the code written on the event. The valid values are

Enabled -- If you use this value, the field is enabled. Additionally, the code for the event is run when the event is called.
Disabled -- If you use this value, the field is disabled.
EnabledButNoRender -- If you use this value, the field is enabled. However, the code for the event is not run when the event is called.

Exporting the customization and making the below change should enable the attribute and not have the code written on the onchange event fired

<event name="setadditionalparams" application="true" active="true" behaviorinbulkeditform="EnabledButNoRender">

Monday, August 24, 2009

Converting ACT! Legacy data to Dynamics CRM

There has always been a request for bringing in legacy data to Dynamics CRM before they migrate to you. One of the key points for going through with the shift from one system to another is the ability to have access to all the records in their legacy system in Dynamics CRM.

The easy way out most often is to look for Data Export options from the current system to generic file formats like XML, CSV, XLS etc. Same is the case with ACT! as well. However though a quick and easy way out this does not necessarily guarantee the quality of the data migrated. Often not all data is exported from the ACT! System and sometimes the data exported is not in a format that can be easily imported to CRM.

ACT! however has its own SDK made available that allows us to read every entity data from ACT! And this way we have more control over the data and format in which we want to bring it into CRM.

Writing information to CRM is not a difficult task for a proficient Dynamics developer. With good knowledge of the SDK of both systems we have been able to successfully bring in not just the Account/Contact and basic details but also bring in Opportunities and history as well.

A couple of tips that would help you when writing your own import tool for ACT!

1. When importing activities, ACT! Allows you to store the activity description in rich text format. In CRM the activity details is a plain text attribute. So it is essential to make sure that all the RTF tags from the activity description read from ACT! are stripped off before writing the data to CRM.

//read act history details to RTF

RichTextBox rtf = new RichTextBox();

rtf.Rtf = oHistory.Details;

//Get the plain text desc from RTf to add to CRM

Desc = rtf.Text

2. When processing history be carefully while parsing the duration field of ACT! CRM requires duration to be specified in minutes.

3. ACT! allows to associate Primary contact as well as additional Secondary contacts with a company. The main contact of ACT can be set as the primary contact in CRM and additional contacts can be made as Contacts by setting the Parent account of these correctly.

4. ACT! provides for creating custom attributes and often you would want to bring to CRM as well. The custom attributes in ACT! are available just as any other field of ACT! and is not stored separately in a different entity.

There are a number of migration tools available in the market to take care of ACT migration if you do not like to reinvent the wheel. One of the unique tools is available here with us, where we offer it as a service / product by testing with your data and verifying the details as well as making small changes according to your specific needs. Check this tool out here.