Recently we had a scenario where we had to avoid the recursion occurring in CRM Plugin due to update of a field through same plugin.

Checking Depth would have helped to avoid this but we had some scenarios where the Depth check won’t work.

So we used the below approach to handle this scenario:

There is a property of IExecutionContext named CorrelationId which stores the GUID for tracking plug-in or custom workflow activity execution.

For more details click here.

We had a class level variable which stored the value of context.CorrelationId.

And before we proceeded the further logic we checked if the value stored in variable is same as context.CorrelationId then only proceed further else return.

Hope this helps!!

Recently, we encountered a scenario where our client reported that the French user is unable to Insert the Email Template which the English user could see by Default on lead while create an email

i.e.  as below no options were seen:

So when the user changed the language to English he was able to select the Template and Insert it into the Email.

However later on the client reported the bug that Status Reason field on lead is getting populated in English and not with the French.

So this brought to us the issue that the Email Templates are language specific. i.e. it depends on the language we select while creating the Email Template.

So in our case, we had selected English language in the Email Template so it was showing English value of the Option set when selecting that:

So for the French users to make the template visible by Default we had to create a same Email Template in French language and then the value of Status Reason in the Email was populated with the French translation in the system.

So if you are working with Multi language enable organization then make sure you are using multiple language Email Templates too to avoid the translation issues.

Hope this helps.

You might have seen the popup dialog of Resolve Case when you click on Resolve Case as below:

So, someone asked me from where the locked Total Time is calculated in the System.

I didn’t know the prompt answer for this. So, had to go through some basics and it was worth a finding to clear my concepts.

Total Time = Duration of all the Completed Activities related to Case.

Hence when I created a Task with Duration 30 minutes and marked it complete the Total Time populated that value i.e. 30 minutes.

So to conclude if I had added another Activity and marked it completed then that Duration would have summed up and shown in the Total Time field when we attempt to resolve the case.

Hope this helps.

Recently, I was trying to retrieve formatted values using Linq.I was able to do for the attribute of the same entity with the help of this blog: Read Formatted Values using Linq.

Every System Customizer/Developer might have created a waiting workflow using Timeouts.

Just noticed one thing which made me think is it really working as expected.

Suppose I had a workflow on Create of Lead to wait till the Est Close Date as below:

Now I created a Lead in my System suppose so that this workflow is triggered, and it waits till the Estimated Date. So, the Process Session looks as below:

So as per this the workflow is Waiting and Postpone until Estimated Date i.e. a Future Date.

Now suppose I change the Estimated Date to Present Date then what should happen?

CRM interestingly handles this scenario and causes the workflow to resume and execute the logic.

You can see the Process Session below:

So, as you see here the Postpone Date shows the same date whereas the Completed on Date represents the workflows completion Date.

So, CRM interestingly has a mechanism which keeps on checking whether the Timeout condition of the field is met or not and then executes accordingly by itself.

Hope you enjoyed CRM’s interesting fact. 😊