Sam's Activities

Introduction:

Every CRM update comes with a lot of goodies for both the developers and the end users, so Dynamics CRM 2015 SP1 was not different.

One of such feature is opening a record in a new window.

While most of you`ll think, what`s so great in this, we have been doing this since CRM 2011, or maybe even before that.

Well here the difference is, now this is available through CRM API.

Before finding out how to achieve this, let`s run down the memory lane, let`s start with CRM 2011 and understand how this functionality have evolved with every update from CRM 2011 to CRM 2015 SP1.

CRM 2011:

How do we used to open an entity record or simple, a record during CRM 2011 era?

We used to use the JavaScript functionality of window.open() to open up a record.

Syntax:

window.open(URL, name)

URL - server name + URL of the record

name – specifies where to open the window, i.e., on the same page or a new tab or a new window.

CRM 2013:

Now, comes the CRM 2013, complete overhauled design, with added features for developer.

It further simplified the way of opening a record, by providing us a parameterized function. This also ensured that it works across devices.

Syntax:

Xrm.Utility.openEntityForm(name, id, parameters)

name – Name of the entity, whose record we want to open.

id – GUID of the record to be opened, if passed null, it opens an empty record form.

parameters – parameters to be used on the form.

Though it simplified the process of opening a record by eliminating the need to create the URL, still it lacked in one component i.e., giving us the choice whether to open a record on the same page or in a new window.

Remember since CRM 2013, all navigation in CRM is in-place i.e it replaces the current page with the new URL that is requested.

Using the above piece of code to open a record, would very well open the record, but it would open on the same page itself, which was kind of annoying.

What if we want to open a record in a new window then? Well, we have to use the same conventional method i.e., window.open(). As a result this functionality could be achieved but not supported across devices.

CRM 2015 SP1:

Then, came CRM 2015 SP1 update, in this update the openEntityForm method has been enhanced further

It means the method is allowed to take in one more parameter, which on specifying defines where the record would open

Syntax:

Xrm.Utility.openEntityForm(name, id, parameters, options)

options – It`s optional. It takes in an object in which we have to specify true or false, true means open in a new window and false means to open on the same page. If this parameter is not specified it defaults to false.

How to use this functionality?

First of all create an Object.

var options = {

openInNewWindow : true

};

Note: the property openInNewWindow cannot be replaced by any another name.

Xrm.Utility.openEntityForm(“account”, null, null, options)

The object just takes only one property currently, we cannot specify the height or width of the window to be opened. It by defaults take up the entire screen.

Conclusion:

Now, the records can be open in a new window.
Currently, we cannot define the size of the window to be opened.

There's much more, for more Dynamics CRM Tips and Tricks head on to Inogic Blog. If you have any questions on Dynamics CRM or need any help in implementaion, customization, upgradation of Dynamics CRM or are looking to get more out of your CRM, feel free to reach us at crm@inogic.com today!

The post Support to open an Entity form in a new Window in Dynamics CRM 2015 SP1 appeared first on Inogic Blog.

CRM 2013 now allows java script coding on header fields as well as BPF fields. Sometimes we come across with the requirement where we need to write script on the fields existing in the business process flow and not on the form. Same with the fields on header of any form.

When a form displays a business process flow control in the header, additional controls gets added for each attribute that is been displayed in that BPF. These controls hold unique names like:header_process_<attribute name>. So using this control we can write script around these fields.

The Controls displayed in the form header are also accessible and hold unique name like:header_<attribute name>.

We can perform all those operations that we can perform on the attribute added on the form. Below we have mentioned some of the sample scripts around such fields.

Show/Hide field

We can also show/hide the fields from the BPF same like we do for the other form attributes. Below we have hidden the field based on the value selected on the form.

We can simply use below line of code to show/hide the field from the BPF.

Xrm.Page.getControl(“header_process_parentcontactid”).setVisible(false);

You can use below line of code to show/hide the field from the Header.

Xrm.Page.getControl(“header_leadsourcecode”).setVisible(false);

Make the field Read only

The field will be read only after applying script on the BPF controls.

Below is a line of code where we have disabled the control from the BPF.

//Check if the control exist on the form

if (Xrm.Page.getControl(“header_process_parentcontactid”) != null) {

//Set the control disabled

Xrm.Page.getControl(“header_process_parentcontactid”).setDisabled(true);

}

The same script you can use to apply to the header fields.

//Check if the control exist on the form

if (Xrm.Page.getControl(“header_leadsourcecode”) != null) {

//Set the control disabled

Xrm.Page.getControl(“header_leadsourcecode”).setDisabled(true);

}

Filter Lookup

We can also filter on lookup based on another. Below we have written script to filter Existing Contact lookup based on Existing Account selected.

We have selected Fourth Coffee Account in the Existing Account as you can see in below screen shot:

And the Existing Contact lookup will now show only Account associated Contacts in this lookup, where as previously it was showing All the contacts exist in CRM regardless of any condition.

Below is a code snippet which will help you to filter a lookup:

function filterLookup() {

//Check if the control exist on the form

if (Xrm.Page.getControl(“header_process_parentcontactid”) != null) {

// add the event handler for PreSearch Event

Xrm.Page.getControl(“header_process_parentcontactid”).addPreSearch(addFilter);

}

function addFilter() {

var accountId = null;

var accountLookup;

var fetchQuery;

try {

//Check if control exist on form

if (Xrm.Page.getControl(“header_process_parentaccountid”) != null && Xrm.Page.getControl(“header_process_parentaccountid”).getAttribute().getValue() != null) {

//Get Account lookup value

accountLookup = Xrm.Page.getControl(“header_process_parentaccountid”).getAttribute().getValue();

//Get the account id

accountId = accountLookup[0].id;

}

//Build fetch

if (accountId != null || accountId != undefined) {

fetchQuery = “<filter type=’and’>” +

“<condition attribute=’statecode’ operator=’eq’ value=’0′ />” +

“<condition attribute=’parentcustomerid’ operator=’eq’ value=’” + accountId + “‘ />” +

“</filter>”;

//add custom filter

Xrm.Page.getControl(“header_process_parentcontactid”).addCustomFilter(fetchQuery);

}

} catch (e) {

Xrm.Utility.alertDialog(“addFilter Error: ” + (e.description || e.message));

}

Get/Set Value

We need to use below method to get/set the value on the BPF fields.

Xrm.Page.getControl(“header_process_descriptions”).getAttribute().getValue();

Xrm.Page.getControl(“header_process_description”).getAttribute().setValue(“Hello World”);

If you want to write a script on the header fields then you can use below line of code for this.

Xrm.Page.getControl(“header_leadsourcecode”).getAttribute().setValue(parseInt(value));

Key Points:

We can only perform actions like set/get value, show/hide fields, add custom filter etc. but we cannot add event handlers on the BPF fields. For this we need to add the same field on the form and then add event handler on that field.
As we cannot apply OOB filter lookups on the BPF fields, achieving through scripts is an advantage.

As we have integration of Dynamics CRM with other external systems, in that case we need to keep track of changes that were done after last synchronization of data and we integrate only those changes in external system. To achieve this previously we have to add some kind of custom logic like add one date field in CRM to track the date of last synchronization. Now, in CRM 2015 update 1 we have a built-in functionality to achieve this, it is called Change Tracking.

Change Tracking is used in Dynamics CRM to keep the data synchronized in a better way by detecting what data has changed since the data was last synchronized.

To retrieve the changes for an entity, we need to enable the Change Tracking functionality for that entity.

This feature can be enabled by using the customization user interface (UI) or programmatically by setting the ChangeTrackingEnabled property to True.

To achieve this functionality CRM 2015 has introduced a new request called RetrieveEntityChangesRequest.

When you execute this request for the very first time, then it returns all records for the entity and that data can be used to sync into any other external system. The message also returns a DataToken that we can use in the RetrieveEntityChangesRequest, so that when we execute this request the next time then it returns data for those changes that occurred since last execution of request.

If you want to get the changed data(created/updated/deleted) of Account since last execution of request then RetrieveEntityChangesRequest message is used to retrieve the data. After executing this request it will return the BusinessEntityChangesCollection of new/updated and deleted records. The new/updated records can be retrieved from NewOrUpdatedItem and deleted item can be retrieved from RemovedOrDeletedItem.

Following is the sample code for RetrieveEntityChangesRequest:

RetrieveEntityChangesRequest changeTracking = new RetrieveEntityChangesRequest();
//set the properties
changeTracking.Columns = new ColumnSet(true);
changeTracking.DataVersion = “471550!05/15/2015 10:08:13″;
changeTracking.EntityName = “account”;

changeTracking.PageInfo = new PagingInfo() { Count = 5000, PageNumber = 1, ReturnTotalRecordCount = false };

RetrieveEntityChangesResponse res = (RetrieveEntityChangesResponse)_service.Execute(changeTracking);

//get the token
string dataToken = res.EntityChanges.DataToken;
BusinessEntityChangesCollection busEntChanColl = res.EntityChanges.Changes;

for (int bizColl = 0; busEntChanColl.Count > bizColl; bizColl++)
{
if (busEntChanColl[bizColl].Type.ToString().ToLowerInvariant() == “neworupdated”)
{
NewOrUpdatedItem createUp =(NewOrUpdatedItem) busEntChanColl[bizColl];
Entity changedEnt = createUp.NewOrUpdatedEntity;
}
else if(busEntChanColl[bizColl].Type.ToString().ToLowerInvariant() == “removeordeleted”)
{
RemovedOrDeletedItem removeOrDelItem = (RemovedOrDeletedItem)busEntChanColl[bizColl];
EntityReference delItem = removeOrDelItem.RemovedItem;
}
}

If you doesn`t provide the DataVersion parameter for request then it will always return all records.

So to retrieve only records those are Created/Updated/Delete after the last execution of request then you have to provide the DataVersion parameter, DataToken returned by previous execution of request is what we have to pass as DataVersion new value for the next request.

For example: res.EntityChanges.DataToken in the above code snippet gives us the DataToken.

If you have the windows service/ windows application for integration of CRM with another system then you can store the DataToken value in app.config. If you used it in a plug-in or a workflow then it is better to create custom entity to store value of DataToken.

This is Part 2 of our Maplytics solution series, which allows you to integrate your Dynamics CRM with Bing Maps for all entities. In Part 1, we saw replies to some of common FAQ’s on the solution. Today let’s see some features and how adding this solution to your CRM can help you analyze your business in a much better way and help you provide Smart Customer Service. We use maps for our daily use, so why not for business.

Maplytics is used across all industries and by all roles. Ofcoz the two most common people in your organization who would use this often is the Manager and the Salesperson. Lets see what one of them has to say..

Manager - We never thought Maps could be so useful until we started using them for our business. Its now become more like an analytical tool for me. Our business is spread across cities and this helps us to keep a tab on things like service requests in an area, complaints from any area or maybe whereabouts of the daily schedule planned by my service technicians. Its all there now right in front of me in my crm. I love the heat maps in it.

Salesperson – Planning meetings is no longer a challenge. Now we can plot any entity on Bing Map from within Microsoft Dynamics CRM and make plans, print and go. The Proximity search feature in Maplytics allows us to search records within a given radius of a location. And yes, we can now find nearest meeting spots like a Starbucks or an airport quickly.

A little more about why we innovated Maplytics and its features:-
Product Page – http://inogic.com/Product/76/Integrations/Maplytics
Video – https://www.youtube.com/watch?v=UgWslSIv5MM

Why Maplytics

Mapping is like changing the game in CRM. Mapping inside of Dynamics CRM goes a step further by showing your users the way to make better business decisions. From simply having a better understanding of your data to making better, more-informed business decisions – maps have the power to transform your business.

Maplytics Features:

1. Plot any entity: Maplytics supports for all entities in Dynamics CRM. User can plot any entity on Bing Map from within Microsoft Dynamics CRM.
2. Save geographical search: Maplytics allows user to save geographical search results. The search results can be saved as static personal views in CRM.
3. Heat Maps: Maplytics also support Heat Maps. Heat maps helps to understand the concentration of your biggest accounts, opportunity, hot leads or any other entity.
4. Color coding of pushpins: With Maplytics user can color code pushpins based on configurable categorization in Microsoft Dynamics CRM.
5. Search records: Maplytics provides the ability to search records within a given radius of a location.
6. Print and Export search results: Maplytics allows to print or export search results to an external file.

Want to know more, why not just see a live demo or opt in for our 15 days fully functional trial. Email us on crm@inogic.com with your CRM version.

There's much more, for more Dynamics CRM Tips and Tricks head on to Inogic Blog. If you have any questions on Dynamics CRM or need any help in implementation, customization, upgradation of Dynamics CRM or are looking to get more out of your CRM, feel free to reach us at crm@inogic.com today!

The post Business analytics using Maps in Dynamics CRM appeared first on Inogic Blog.

Introduction

There are multiple ways provided in Dynamics CRM SDK to query and read data like

Using ODATA
Using FetchXML
Using Query object

ODATA has a limitation where it can return only 50 records at a time. You can ofcourse query more than that but it would be in batches of 50 records at a time.

Fetch XML queries on the other hand will allow you to read upto 5000 records in one go with the ability to read the next 5000. Since requesting 5000 records at a time may not really be a good idea because of the network resources that would use and potentially slow down or even time out depending on the network speeds, it is always a good idea to read data in small manageable sets of records. Fetch queries when executed return paging cookies when you implement paging and this helps you to implement a system where you would like to read a fixed count of records and provide a next/prev button to access additional records.

Query Records using Fetch

</filter>

</link-entity>

</entity>

</fetch>

The above code works fine as long as there are less than 5000 records in the system. When the records fetched count went above 5000+ records we started getting following error:

So if you notice in our above fetch xml we are providing “paging-cookie” as blank. So once the records retrieved count goes above 5000+ records we started getting the above shown error. For Fetch to bring records above 5000+ it requires paging-cookie to be set in the fetch tag

Setting the Paging Cookie

Where do we find the paging cookie? The answer is fetch response. Whenever we make a fetch request the response which we get back from fetch has paging-cookie in it. We need to extract that paging-cookie from response which we can send to our next page fetch request. In addition to paging-cookie we also get “MoreRecords” which is Boolean which tells us if there are any more records to fetch.

When we are on first page we provide the paging-cookie as blank as the first page doesn’t need a paging-cookie. When the fetch query is executed it brings the page-cookie with it in the resultant response which looks like this:

“<cookie page=\”1\”><name lastnull=\”1\” firstnull=\”1\” /><accountid last=\”{98B36F67-3A21-E511-80FC-C4346BAD2660}\” first=\”{A6B16F67-3A21-E511-80FC-C4346BAD2660}\” /></cookie>”

To get this page-cookie from response we extract it from resultant fetch response as follows:

Var pagecookie = $(resultXml).find(“a\\:PagingCookie”).eq(0)[0].text;

You can find that since we are on first page it returns the page as “1”. Since the fetch is for “Account” entity it returns the first accountid and last accountid for that page in page-cookie. When we request for the next page we provide this page-cookie from first page to the next page fetch query request.

In the same way we can extract “MoreRecords” as follows:

Var moreRecords = $(resultXml).find(“a\\:MoreRecords”).eq(0)[0].text

This returns “true” or “false” which helps us to determine if we reached last page or still there are any records to fetch.

Updated Code

var xmlDocument = parser.parseFromString(fetchxml, “text/xml”);

var fetch = $(xmlDocument).find(‘fetch’);

fetch.attr(‘page’, page);

fetch.attr(‘count’, pageCount);

fetch.attr(‘paging-cookie’, pagingCookie);

In above code we are providing “pagingCookie” variable to which we set the page-cookie which we get from response in fetch attribute along with page and pagecount.

So now when you checkout the fetch query it be as follows :

</filter>

</link-entity>

</entity>

</fetch>

Note:

Make sure to encode the fetchxml request to cover for any special characters in the data. Let us explain with an example, for one of the result sets of the above fetch we found the paging-cookie received a special character – single quote (‘) in one of the records name field. This field was referenced in the paging-cookie.

Example:

“<cookie page=\”2\”><fullname last=\”Susan’s Burk (sample)\” first=\”Rene Valdes (sample)\” /><contactid last=\”{349DB5FF-DA1B-E511-80F1-C4346BACD1A8}\” first=\”{2E9DB5FF-DA1B-E511-80F1-C4346BACD1A8}\” /></cookie>”

In above example you can see that the fullname last=\”Susan’s Burk (sample)\” has (‘s). This (‘) used to break the fetchxml and hence started throwing “Page Cookie Malformed” exception when trying to execute fetchxml request.

To resolve this you need to encode the paging-cookie before it is insert in the fetch xml.

Traversing backwards

Using the paging-cookie you can traverse forward to the next set of results. But if you want to implement the previous button or you want to allow navigation to a specific page, you need to make sure you store the paging-cookie received for each of the pages.

To deal with this you can save the page-cookie for example in the array for the pages which you move forward and use this later to get the page-cookie for that particular page when moving backward in paging.

Conclusion

Using Paging-cookies effectively, you can implement paging without actually retrieving all the records at one-go. Query records only when requested and display for better performance results.

The post Querying More than 5000 records in Dynamics CRM appeared first on Inogic Blog.

Converting Date/Time values according to a timezone is quite easy in languages like javascript, C#, etc. but achieving this in SSRS reports is a challenging task. For CRM online we can achieve this using CRM parameter in SSRS reports.

We have covered a work around to achieve this functionality in SSRS reports for CRM online.

Scenario:

We had a request from one of our clients in which the client used to run a report on the last day of every month.

The client used to pay commisions to the users as per the goals achieved by them in the month, so he runs the report on the last day of the month. Somehow the report when ran didn’t show the proper data and the reason was the timzone difference between the user and the UTC timezone.

Since the report was made to show records of the current month so when the client ran the report on May 31 it unexpectedly showed the details of June because till that time the date has changed to June 01 in UTC.

Resolution:

After so much googling also we could not find a way to tackle this situation. So we tried to know the principles used in the OOB reports of CRM to handle this situation as they always run without any issues and show the perfect data all the time.

To know what is the logic used in the OOB reports we downloaded the Account Summary report available in system and we found two things that are used to achieve this functionality:

CRM parameter: CRM_UserTimeZone
Assembly reference:Crm.Reporting.RdlHelper

To incorporate these changes in our report we created a parameter CRM_UserTimeZone to store the user time zone as shown below:

After adding the parameter in the report we need to add the assembly refrence, to add the refrence go to Report Properties and click on the References tab. Now click on the Add button, since the assembly we need to add in the report is only available on the reporting server so we cannot browse and add a URL to it.

To overcome this we need to just paste the following URL in the browse textbox as shown below:

URL: Microsoft.Crm.Reporting.RdlHelper, Version=7.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

The above URL is found in the refrences of the Account Summary report.

After adding the assembly reference we need to initialize a variable which will contain the user current datetime. To do this we use the following code:

=CDate(Microsoft.Crm.Reporting.RdlHelper.DateTimeUtility.ConvertUtcToLocalTime(DateTime.UtcNow, Parameters!CRM_UserTimeZoneName.Value))

In the above code, we have converted the UTC time to user local time using theCRM_UserTimeZoneName parameter so it provides us the flexibility to run the report on the last day of each month.

Note: If we run this report in the dev machine then it gives an error of missing references as shown below:

But when this report is rendered in the online environment then it loads the referenced assembly from the CRM online environment and shows the proper data.

Summary

It is clear from the above example that we can use the CRM parameters to make our reports user-friendly and to show user-specific data.

The post Converting Date/Time based on user timezone in SSRS reports for Dynamics CRM Online appeared first on Inogic Blog.

Introduction:

In our recent blog post about calculated fields we have covered about calculated fields support extended for Date/Time data types in Dynamics CRM 2015 Online Update 1. You can read this blog here. In this blog we will focus on accessing related entities fields in calculated fields formulas.

In Calculated fields, you can define the formula at the time of adding the field itself. This ensures it is executed at all times, server-side. But since it is updated synchronously you can see the updates immediately upon save.

Calculated fields can only use N:1 look up fields. We cannot use N:N or 1:N relationship for Calculated fields.

Walk-through:

Let’s see how we can use related entities look up fields in calculated fields formula.

Consider an example where we need to calculate the Budget for Opportunity Entity using the formula:

Budget(Opportunity)=Budget(Account) – ( Budget(Account)*0.002)

To accomplish this,

1. We will first create Budget field as calculated field on Opportunity Entity. As we createBudget field as Calculated Field it becomes read only on the form.

2. To define the calculation for Budget field click on Edit button that appears only when Field type is Calculated or Rollup.

This opens a UI similar to Business Rules where we can define calculation.

3. When setting the action and formula, you get intellisense to support the common functions. Using the intellisense, we can use the related entity by using the lookup fields name of that entity.

4. The lookup fields name allows access to all fields of the look up entity.

5. For above requirement we have defined the conditions and actions as below:

Now, when you create a new record, upon Save you will find the Budget automatically set.

Conclusion:

With this extended support we can perform calculations that require related entities fields using calculated fields.

Stuck with migration to Dynamics CRM? Experts at Inogic are always happy to help you, get in touch with us on crm@inogic.com.

The post Accessing related entities fields in Calculated Fields formulas in Microsoft Dynamics CRM 2015 appeared first on Inogic Blog.

Introduction:

Calculated fields was first introduced in Dynamics CRM 2015 and it further improved upon the ability to provide codeless solutions to power users to configure. You can learn more about its features from our earlier blog here.

It provided support for most CRM data types however the calculations and formulae supported for Date/Time fields were still limited.

With the latest Online update, they have enhanced the operations supported on Date/Time fields.

DIFFINDAYS(start date or time, End date or time)
DIFFINHOURS(start date or time, End date or time)
DIFFINMINUTES(start date or time, End date or time)
DIFFINWEEKS(start date or time, End date or time)
DIFFINYEARS(start date or time, End date or time)
DIFFINMONTHS(start date or time, End date or time)

The Rollup field has also been enhanced to support AVG as an aggregate calculation for Date/Time fields.

How does this help?

A very real scenario where this code be used is to calculate the Avg. time it takes for resolving a complaint.

The Actual Units fields in the Case entity calculates the total time spent on the case by adding up the times on the individual activities associated with the case. But what if you wanted to know just how long a case had been open – case createdon – case modifiedon.

Next it would be good to have the Avg. case resolution time per customer, to monitor if there are particular customers for which is usually takes too long to close a case. What we are looking out for here is Avg. Case closure time.

Walkthrough

Let us see how to go about getting this set up in no time.

Add the Calculated field.

Since we have created a Duration field, we would calculate the difference between CreatedOn and ModifiedOn in minutes. Note. Duration field always expects the values to be provided in minutes.

Create the Rollup field.

We will add the rollup field on Account to get the Avg. Resolution time.

Rollup the time for only resolved cases.

Place both the fields on the Case and Account forms respectively.
Now when you resolve the case, you will find that the case resolution time is auto calculated.

We quickly closed a few cases for this account so that the avg. could be calculated

6. Now lets check how it looks on the Account form

Conclusion:

Though this takes a step further in supporting date/time data type in Calculated and Rollup fields, Rollup fields still do not support Date conditional operators like Last X months/years etc. So if I wanted to get the avg. case closure time in the last 6 months, I still cannot do that. Hoping to see this included in future version to support a full code-less power-user configuration solution.

The post Calculated fields support extended for Date/Time data types in Dynamics CRM 2015 Online Update1 appeared first on Inogic Blog.

Keywords : Calculated field, Dynamics CRM 2015, Date/Time data types, Dynamics CRM 2015 Online update 1,

Introduction

Hierarchies were introduced in Dynamics CRM 2015. Hierarchy provided a way for visualizing relation between records and identify where the records reside in parent child relationship.

As in example below shows where “Test Account02” situated in hierarchy tree.

SDK Support

To support the ability to retrieve records based on Hierarchy, the SDK was enhanced and new operators added that would allow you to specify the records to be selected in the hierarchy.

There are new conditional operators has been added in CRM SDK to utilize record hierarchy feature and retrieve records in hierarchy.

Listed below are the conditional operator can be used to retrieve records in hierarchy. We retrieved the records on account form load for account “Test Account02” and displayed in alert dialog to check the result. Below are the condition operator and its description.

1. above