OnLoad event for SubGrid in CRM 2015 Update 1

Till CRM 2011 we used to use Xrm.page.getControl(“grid”) to get a grid control available on form and perform any runtime activity like changing the view/query, etc. Also we were required to write the complete script on OnLoad even of form and add a timeout till the subgrid is loaded as subgrids are loaded asynchronously after the form is loaded. There was no way we can have a trigger on load of a subgrid till CRM 2015 Update 1. What we used to do is explained in older post here.

But with CRM 2015 update 1, we now have an option to execute scripts when data is loaded in subgrids. Because of which we are not required to have any timeout added in the script and iterate it till the data is loaded into subgrid.

With addition on GridControl.addOnLoad method, we can now add event handler for OnLoad event of subgrid which is more reliable than the form OnLoad event for form with a timeout. This event will get triggered whenever data is bound to a subgrid.

The steps to add this event is not similar to adding a form OnLoad event (from form customization popup), the way to add it is by invoking it using a code from other events (e.g. form OnLoad) by making use of GridControl.addOnLoad method. Similarly, use GridControl.removeOnLoad to remove event handlers.

Xrm.Page.getControl(“Contacts”).addOnLoad(myContactsGridOnloadFunction);

References:

https://msdn.microsoft.com/en-us/library/dn932137.aspx?f=255&MSPPError=-2147217396

https://msdn.microsoft.com/en-us/library/dn932126.aspx#BKMK_subgridAddOnLoad

https://crmcooking.wordpress.com/2015/07/15/writing-scripts-for-subgrids-with-crm-2015-update-1/

Advertisements

DID YOU KNOW? Potential issues with CRM due to SQL server replication

I’m not an expert in SQL Server and related stuff like replication but recently faced an issue with simple solution deployment in CRM 2011.

Scenario:

I was trying to deploy an unmanaged solution consisting of Contact entity where I had created a new custom field. When I tried to import the solution, the solution import used to fail without any specific error even in the downloaded log. All components used to process successfully with only Root Components status as unprocessed where the import used to fail.

Then I tried to create the field manually by customizing the entity. When I tried to create a new field, I used to get SQL Server error. The log here too had not much helpful information.

Cause:

These error messages occurs when SQL Replication is enabled for Microsoft Dynamics CRM databases and you attempt to insert into a text, ntext, or image column that is published in a replication article.

In this case, you get below error.

System.Data.SqlClient.SqlException (0x80131904): Length of LOB data (14349284) to be replicated exceeds configured maximum 65536.

Resolution:

Below article describes the resolution for it.

http://blogs.msdn.com/b/atif/archive/2012/02/28/length-of-lob-data-152644-to-be-replicated-exceeds-configured-maximum-65536.aspx

sp_configure
‘max text repl size’, 14349284

RECONFIGURE

GO

In few cases, above resolution didn’t worked for me. The only way that we could figure of was to import the solution by un-publishing the related replication articles and then publishing.

DID YOU KNOW? What happens to Audit History on performing database level update?

062915_1445_DIDYOUKNOWW1.jpg

Note: This is all about UNSUPPORTED database level updates. These kind of updates are not recommended (unless you are left with no options).

Though any kind of database level updates are not recommended in CRM, there are scenarios where we are required to do so. I had one such requirement where I was required to perform a simple update (setting two options field value to Yes) for millions of records. Doing same using a supportive way (bulk update or bulk workflow execution) used to take days due to CRM service calls but same updates using SQL script was done in few hours.

I had auditing enabled for these records in CRM, but as this was unsupported db level update I was not expecting any help from audit history. What was expected form auditing was either of below:

  1. Change track as new update request in audit history. (If there is any kind of trigger return at db level to maintain auditing)
  2. No updates at all in audit history. (Assuming auditing are maintained by some kind of workflow/plugin that trigger at UI level)

Unfortunately, none of this happened and what happened was not at all audit friendly or expected. This is what happened:

The change made by SQL script was tracked at create event itself in audit history. But only the field value change was tracked and not the change date/time. The change date/time was still showing when the record was created.

Though these kind of changes are not recommended, but I still feel that in some cases these are required and this behavior of auditing will affect the consistency. I feel that things should be either completely baked or not baked at all than having them half baked. But again this is only what I feel. J

Example:

  1. I created a Contact record on 7/6/2015 at 11:52 AM with ‘First R~~~~~ Created’ set to ‘No’. Audit history shows something like below.

     

  2. Now on 7/6/2015 at 12:00 Noon, I update the value for ‘First R~~~~~ created’ to ‘Yes’ using a database level update script. Ideally there should have been a new entry made in audit log to track this change and there should be no change made to existing audit history records. But CRM updates the changed value in create event itself without even tracking the change time.

 

Hope this helps and thanks if you have come all the way down here reading the article.

DID YOU KNOW? Workflow process throws generic CRM error


Scenario

I have an OOB workflow process developed some time back and activated. Now when I try to open the process, I get generic CRM error (below image). Also the process status is changed to “Draft” automatically. There were no updates made to the process.

Cause

I have seen these issues frequently especially when working with Child Workflow Processes where I have a child workflow called from a Master workflow. If you have a Master workflow calling a child workflow and for some reason the child workflow is activated as “Process Template”, then user gets this error when they try to open the master workflow.

Conclusion

CRM throws generic exception and its status is changed to Draft if it linked/related to a “Process Template” instead of “Process”.

Note

Other common issue faced while working with workflow process is “Invalid Expression” error in “Condition Expression” step. This occurs if the field used in condition expression is either deleted from system or if Value is changed. Once you fix the field/value issue, all conditions in the process are automatically fixed.

DID YOU KNOW? Fields rarely touched in Dynamics CRM

We all know that whenever we create an entity in CRM, CRM creates few fields by default. Some of these like Owner, Owning Business Unit, Created On, Modified On, etc. are used extensively while working with Dynamics CRM. But there are some fields that we use very rarely or even never; thus we tend to forget about them. But some of these fields are really important and can save a lot custom work, it’s just that we should be aware of them.

Recently there was a question on Dynamics Community regarding use of same fields which inspired me to search for them and have it documented. Few fields can be understood from their name but some fields don’t even have proper description in CRM. For such fields, below table can help. Links against the fields has more explanation and scenarios where these can be used.

Field Name Description
CreatedBy User who created the record.
CreatedOn Date and time when the record was created.
CreatedOnBehalfBy To create records on behalf of another user.
Used for impersonation in CRM 2011
ExchangeRate When I create a record, such as an opportunity,
and use a non-base currency, such as GBP in this
hypothetical scenario, this is what happens:

  • I set the Currency field to GBP
  • I put a value in the money field, called Estimated
    Revenue
  • I save the record. During the save operation,
    the following occurs:
  • The Exchange Rate field is populated with the
    value 0.61300000000
  • The Estimated Revenue_base field is populated
    with the value from the Estimated Revenue field
    converted to its inflated USD value
  • Both of these updates occur whether the Exchange
    Rate and Estimated Revenue_base fields are exposed
    on the form or not

Afterwards, when the dollar makes that incredible comeback,
I need to update my exchange rate on the GBP currency.
I do so – it’s now 1, reflecting a 1:1 conversion rate.
What happens to my opportunity? Nothing, at least not immediately.
The Exchange Rate field on my opportunity is not automatically populated
with the new value of 1. However, as soon as I change the value of ANY money
field on the opportunity and save the form, the Exchange Rate field is updated
with the new value from the GBP currency record, and the Estimated Revenue_base
field is updated with the new converted value (and any other _base fields for other
money fields on the form – remember, there is only 1 Currency and 1 Exchange Rate field,
so these values apply to all money fields on the form). This also happens if I change the state
of the record, such as closing the Opportunity as won or lost, activating or closing a quote, etc.

http://andrewbschultz.~exchange-rate-updates/

ImportSequenceNumber The import sequence number is a whole number field. The range can be customized if needed.
The basic idea behind this field is to store the sequence number (ID) of the source record during
data import to CRM. If this field is mapped during migration package/script design,
it provides a one-to-one link between source row and destination CRM record.

 

http://www.powerobjects.com/~-number-field/

ModifiedBy User who modified the record.
ModifiedOn Date and time when the record was modified.
ModifiedOnBehalfBy To create records on behalf of another user. Used for impersonation in CRM 2011
OverriddenCreatedOn Date and time that the record was migrated.
http://www.magnetismsolutions.~_crm_2011_part_1
TimeZoneRuleVersionNumber The definition of a recurrence pattern of how local time is converted to/from Universal Coordinated Time (UTC). This includes information about Daylight Savings Time (DST) versus Standard Time. Time zone rules can change over time, thus a time zone can have multiple rules from a historic point of view, but can have only one rule that is current and in effect.

 

http://blogs.msdn.com/b/crm/archive/2008/05/14/time-zones-in-microsoft-dynamics-crm-4-0.aspx

TransactionCurrencyId Currency associated with the entity.
UTCConversionTimeZoneCode Time zone code that was in use when the record was created.
VersionNumber This column is used mainly for concurrency support. The VERSIONNUMBER field is a unique value that gets incremented as records are updated – it can be very useful.

Only update things you need to

While it is important not to reduce the benefit of a Dynamics CRM system by excluding activities that would be beneficial, often requests are made to include customization that add little business value but drive real technical complexity.

Consider a simple business scenario:

If every time we create a task we also update the user record with the number of tasks they currently have allocated, that could introduce a secondary level of blocking as the user record would also now be heavily contended. It would add another resource that each request may need to block and wait for, despite not necessarily being critical to the action. In that example, consider carefully whether storing the count of tasks against the user is important or if the count can be calculated on demand or stored elsewhere such as using hierarchy and rollup field capabilities in Dynamics CRM natively. Limited update philosophy should also be adopted while extending CRM using Processes, Plugins or Scripts.

 

 

This is something that reminds me of normalization in DBMS J

***References : Scalable Dynamics CRM Customization documentation

Subject lookup changed to Option Set in CRM 2015

Recently while exploring CRM 2015, when rest of the world was talking about all kind of new features added to CRM 2015, one of my friend pointed to a small change made to Subject field on Case form which sound bit weird and not at all user friendly for data entry. The change was “Subject lookup is changed to Option Set type field”. Not really, but yes it is again a new complex field that you cannot customize something similar to full name field.

This was not the only surprise, on checking the field type in default solution, the field type is still same as lookup. Even the way of accessing the field using JavaScript is same like lookup. Then why the change on form and how is the new change helpful?

Consider a scenario where I have a CSR creating a Case while on Phone Call with the customer. With CRM 2011, CSR can directly type into the Subject lookup and the value will get auto populated, but with CRM 2015 option set kind field CSR will have to manually drill down to Root node à parent node à Child node and more dipper based on the Subject tree complexity.

TimeZone field format in CRM

I’m sure that everyone of us must have added the field of type Whole number with format TimeZone in at least one CRM implementation. But have you tried to set the value of this field using a custom C# application or a Plugin or Workflow?

Problem with setting the value for this field using C# is that as the field is of type whole number, it accepts only integer value while setting it, but the values for each timezone labels are not mentioned. Also the minimum and maximum range mentioned for whole number field do not apply for format as timezone. Then what are the values for these?

The values ranges from 0 to 300 but this are not in sequence. Below table shows the values for the labels.

0: “Dateline Standard Time”;
1: “Samoa Standard Time”;
2: “Hawaiian Standard Time”;
3: “Alaskan Standard Time”;
4: “Pacific Standard Time”;
5: “Pacific Standard Time (Mexico)”;
6: “UTC-11”;
10: “Mountain Standard Time”;
12: “Mountain Standard Time (Mexico)”;
13: “Mexico Standard Time 2”;
15: “US Mountain Standard Time”;
20: “Central Standard Time”;
25: “Canada Central Standard Time”;
29: “Central Standard Time (Mexico)”;
30: “Mexico Standard Time”;
33: “Central America Standard Time”;
35: “Eastern Standard Time”;
40: “US Eastern Standard Time”;
45: “SA Pacific Standard Time”;
47: “Venezuela Standard Time”;
50: “Atlantic Standard Time”;
55: “SA Western Standard Time”;
56: “Pacific SA Standard Time”;
58: “Central Brazilian Standard Time”;
59: “Paraguay Standard Time”;
60: “Newfoundland Standard Time”;
65: “E. South America Standard Time”;
69: “Argentina Standard Time”;
70: “SA Eastern Standard Time”;
73: “Greenland Standard Time”;
74: “Montevideo Standard Time”;
75: “Mid-Atlantic Standard Time”;
76: “UTC-02”;
80: “Azores Standard Time”;
83: “Cape Verde Standard Time”;
84: “Morocco Standard Time”;
85: “GMT Standard Time”;
90: “Greenwich Standard Time”;
92: “Coordinated Universal Time”;
95: “Central Europe Standard Time”;
100: “Central European Standard Time”;
105: “Romance Standard Time”;
110: “W. Europe Standard Time”;
113: “W. Central Africa Standard Time”;
115: “E. Europe Standard Time”;
120: “Egypt Standard Time”;
125: “FLE Standard Time”;
129: “Jordan Standard Time”;
130: “GTB Standard Time”;
131: “Middle East Standard Time”;
133: “Syria Standard Time”;
135: “Jerusalem Standard Time”;
140: “South Africa Standard Time”;
141: “Namibia Standard Time”;
145: “Russian Standard Time”;
150: “Arab Standard Time”;
155: “E. Africa Standard Time”;
158: “Arabic Standard Time”;
160: “Iran Standard Time”;
165: “Arabian Standard Time”;
169: “Azerbaijan Standard Time”;
170: “Caucasus Standard Time”;
172: “Mauritius Standard Time”;
173: “Georgian Standard Time”;
175: “Afghanistan Standard Time”;
180: “Ekaterinburg Standard Time”;
184: “Pakistan Standard Time”;
185: “West Asia Standard Time”;
190: “India Standard Time”;
193: “Nepal Standard Time”;
195: “Central Asia Standard Time”;
196: “Bangladesh Standard Time”;
200: “Sri Lanka Standard Time”;
201: “N. Central Asia Standard Time”;
203: “Myanmar Standard Time”;
205: “SE Asia Standard Time”;
207: “North Asia Standard Time”;
210: “China Standard Time”;
215: “Malay Peninsula Standard Time”;
220: “Taipei Standard Time”;
225: “W. Australia Standard Time”;
227: “North Asia East Standard Time”;
228: “Ulaanbaatar Standard Time”;
230: “Korea Standard Time”;
235: “Tokyo Standard Time”;
240: “Yakutsk Standard Time”;
245: “AUS Central Standard Time”;
250: “Cen. Australia Standard Time”;
251: “Adelaide (Commonwealth Games 2006)”;
255: “AUS Eastern Standard Time”;
256: “Canberra, Melbourne, Sydney (Commonwealth Games 2006)”;
260: “E. Australia Standard Time”;
265: “Tasmania Standard Time”;
266: “Hobart (Commonwealth Games 2006)”;
270: “Vladivostok Standard Time”;
275: “West Pacific Standard Time”;
280: “Central Pacific Standard Time”;
281: “Magadan Standard Time”;
284: “UTC+12”;
285: “Fiji Standard Time”;
290: “New Zealand Standard Time”;
295: “Kamchatka Standard Time”;
300: “Tonga Standard Time”;

Small Things that Often Forgotten in Plugin Development – Just 1 Tip Presentation

Work and Study book - Dynamics 365 (CRM) Blog

As requested by Ben on my previous blog post. I posted the slides of my Just 1 Tip presentation from the last Melbourne CRM User Group. The presentation focus is a quick tip on how we as developers are often forget the small details in event-driven solution design that could ended-up in a headache for the other fellow developers/business user to trace/test.

There are 3 issues that I commonly encountered during the design and development:

#1: Infinite Loop – a request inside the plugin code to the same message and field filter as the registered step and in the same entity.

#2: Auto-save – this will trigger the update request and if the plugin step registered is not filtered, it will trigger the plugin very often.

#3: Multiple Synchronous Events (Plugin + Real Time Workflow) – Tips of using XrmToolbox plugin to change the order of executions. (This section drove…

View original post 12 more words

CRM 2011 / CRM 2013 COMPARISON TOOL

COMPARISON TOOL is a tool for Microsoft dynamics CRM 2011/2013 (CRM Online) that compare two different customization. COMPARISON TOOL gives you possibility to compare:

a) Attributes.
b) Sections.
c) Tabs.
d) Relationships.
e) Events.
f) Business Rules (Only for CRM 2013).

Main Features:
1. Supports 2011 and 2013 version servers.
2. View list of intersected entities.
3. View list of unique data for each customization.
4. Export excel file that include results of comparing.

comparision tool

https://comparisontool.codeplex.com/