Category: Uncategorized

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. 😊

A simple question which 3 out of 10 System Customizers/Developers may answer correctly.

Suppose you are doing a Bulk Edit for contacts from the View a form with fields get displayed which looks as below:

Similarly, if you add an Update Record step on a workflow on Contact record then you might see the same Form and fields without Headers as below:

So, if you ask which form fields the above form displays then you might say the Main Form. But its partially correct answer. As my Contact may have multiple Main Forms in the System.

So, the answer to this question is CRM follows the rule which it follows while opening the record of an Entity i.e. “It displays the last visited Form by the user for that Entity for which he/she is trying to Bulk Edit or trying to add Create/Update step of the particular Entity in a Workflow”.

Hope this helps 😊

Recently we encountered a strange issue in our Portal where the working Web Page started displaying not so descriptive but a generic error which many of you may have faced earlier for different reasons. So, the error looks as below:

This was a generic message. Thanks for the feature where we can now Disable the Custom error which is displayed above and can show the exact error in Portal. For more details on that you may refer the below link:

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/view-portal-error-log

So, Disabling the Custom Error gave me the exact error in my case as you can see below:

This was strange as the configuration was working fine earlier and then it stopped working.  But the fact was that we had changed the form name from “Portal Lead Form” to “Extended Portal Lead Form”.

So, we opened the Entity Form to check the form selected on the record.

And there you can see the dropdown is blank and the Form Name field contains the old value i.e. Portal Lead Form which was causing the error.

So, the conclusion is if you are changing the Form Name of any Form which is used in Portal Configurations then make sure you update the records manually with the latest values.

Hope this helps 😊

Recently we encountered a scenario where we had join queries involved in our code.

So, the requirement we had to pass the data of the joined entities accordingly which would satisfy the code logic in our Unit Test.

But it was not as easy as we thought as there is a tricky part involved there.

Sample Plugin Code for which we will be creating Unit Test:

As you can see in our code we are querying the Contact entity and using Joins with the Account entity to read the Account Name along with Contact Last Name.

So, we will be adding the below code to send the record in the Response:

But the problem here was How to send the joined Entity’s value as if we don’t pass any value then it was showing null value in the returned query results.

So, we thought of going for AliasedValue concept. So we decided to pass “a.name” field in the attributes and set the value as below as in our Linq query we had used “join a” in the Linq query:

contactObj.Attributes[“a.name”] = new AliasedValue(Account.EntityLogicalName, “name”, “Test Sid”);

But still, it didn’t work. On further spending more time and debugging the request we found the tricky part involved:

So as you can see the Entity Alias name involved is “a_0” and not “a” so we changed the code to “a_0.name” as below and it worked like a charm 😊

The above example shows how it works when one join is involved. Just for more curiosity, I tried with below multiple joins query:

So, it returns the link entity information as below:

For 1^st Join on Contact

For 2^nd Join on Lead

From the above results, I came to know that joins in LINQ works in a bit different way!!

The entity alias name is populated based on the joins order in your LINQ Query starting from 0 and increasing further if the query contains more joins along with the variable used for the respective entities.

Hope this helps and ease your Unit Testing with Fakes.

Recently we were working on Unit Testing using Fakes for our Plugin. We faced a strange issue while writing the Unit Test for code as we had request involved there.

We were using RetrieveAttributeResponse in our code. But we were unable to set the expected response in Unit Test as AttributeMetadata is a read-only attribute and we cannot set it using the standard way.

We found some alternative blogs which mentioned using Wrapper classes approach for the same:

http://www.alexanderdevelopment.net/post/2013/01/13/How-to-unit-test-C-Dynamics-CRM-interface-code-part-III

https://nishantrana.me/2014/01/25/unit-test-retrieveattributeresponse-in-crm-using-microsoft-fakes/

But I was not willing to change the code and use Wrapper classes for this. So, after investing my time in research I found that below approach and the code worked for us like a gem:

 

So as you can see here we just passed the ParameterCollection object to the response.Results property in the response with the parameter name as “AttributeMetadata” the property which I wanted to set along with the respective value.

And guess what it passed the corresponding value which I needed to set in the read-only property.

This approach can be used for any of the CRM request where the property is read-only.

Hope this helps.