Microsoft Dynamics 365(CRM) Tips and Tricks » Entityhttps://www.inogic.com/blog
By InogicTue, 14 Aug 2018 10:37:00 +0000en-UShourly1http://wordpress.org/?v=4.0Introduction of Rollup Fields in CRM 2015https://www.inogic.com/blog/2015/01/introduction-of-rollup-fields-in-crm-2015/
https://www.inogic.com/blog/2015/01/introduction-of-rollup-fields-in-crm-2015/#commentsThu, 08 Jan 2015 11:42:03 +0000http://www.inogic.com/blog/?p=1120Read More »]]>Among the many new features added in Dynamics CRM 2015, Rollup Fields is one of the interesting new feature which provides a way to perform a record level aggregation from child records to its parent record. This avoids plug-in development and can be easily achieved by end users through simple setup and settings itself without any code involved.

Let’s take an example to explore implementation and working of rollup fields. Suppose we want to show total count of all the active contacts associated with an active Account and its Child Accounts on Account form.

Rollup field setup:

To achieve this we will first start with creating new Rollup field for Account as shown below:

Here you can see that the field type which we have selected is of type “Rollup” and the data type which we have selected is of type “Whole Number”. The Data Type of the Rollup field must match the Data Type of the field for which we want to calculate the rollup. So if we want to show rollup of a field for Contact on Account form then the data type of rollup field must match the data type of the field for which we want to calculate rollup.

Also, you can see the “Edit” button besides “Rollup” selected Field Type. Whenever we select field type as “Rollup”, Edit button appears next to the Field Type and that brings up one editor screen which is similar to the “Business Rules” screen. Please refer the below screen:

Here we can specify the filters, conditions and aggregations which will be applied to the rollup field. The details are explained below,

The source entity which is taken by default to be the entity for which the rollup field is created. In our example it is “Account” entity hence the “Source” is by default “Account”

Use Hierarchy can be set to Yes/No for utilizing parent-child relationship. In our example we want to get aggregation for all Child Accounts of an Account hence we have set it to “Yes”

We can apply filters for source entity using the “Filters” option where we can specify the conditions to apply. In our example we have specified the condition that the Account status needs to be “Active” so rollup happens for active records only.

When we want to get aggregation of related entity data in our rollup then we specify the “Related Entity”. In our example since we want to show total count of all the active contacts present for an Account and its Child Accounts, we have selected “Contacts (Company Name)” as the “Related” entity.

If we want to apply filters for related entity then we can do that by adding filter conditions in “Related Entity”. In our example since we want to show total count of all the activecontacts present for an Account and its Child Accounts we have added filter condition to check if “Status” equals “Active” for related opportunities

And finally we specify the aggregation function which we want to apply and for which field. In our example since we want to show all active Contacts for an Account, we have selected the aggregate function as “Count”.

User Interface:

The Rollup Field that we just created will be seen on the “Source Entity” form i.e. account form:

So the total Contacts for a particular Account will be calculated and shown in this “Total Contacts” Rollup field for that Account . If the Account has Child Accounts then the total of Contacts for that Account along with its Child Account’s Contacts will be calculated and shown in this “Total Contacts” Rollup field for that Account.

Rollup fields are read only. On this Rollup field you can see the “Refresh” icon attached to the Rollup field. Since rollup operates asynchronously, it is calculated on hourly basis. But we can also self-trigger the rollup field calculation by hitting this “Refresh” icon and perform the re-calculation.

Developer Notes:

Each rollup attribute for an entity has two supporting attributes for the rollup attribute which automatically gets created when a rollup field is created:

<attribute SchemaName>_Date: DateTime – When the rollup was last calculated

<attribute SchemaName>_State: Integer – The state of the rollup calculation

Following are the State values:

0 – NotCalculated: Attribute value is yet to be calculated

1 – Calculated: Attribute value has been calculated per the last update time in <attribute SchemaName>_Date attribute

2 – OverflowError: Attribute value calculation lead to overflow error

3 – OtherError: Attribute value calculation failed due to an internal error, next run of calculation job will likely fix it

4 – RetryLimitExceeded: Attribute value calculation failed because the maximum number of retry attempts to calculate the value were exceeded likely due to high number of concurrency and locking conflicts

Rollup field is not supported by all data types and only following data types support rollup field:

Whole Number

Decimal

Currency

Date & Time

Limitations:

Rollup works on 1:N relationship. They don’t work on N-N relationship

Rollup field cannot use another Calculated or Rollup field for rollup

For Complex field calculations we need to still rely on plug-in or java script

Rollup fields don’t raise the event to trigger workflows

We can have maximum of 100 rollup fields within an organization and each entity can have no more than 10 rollup fields.

]]>https://www.inogic.com/blog/2015/01/introduction-of-rollup-fields-in-crm-2015/feed/0How to show Filtered Lookup Dialog in Dynamics CRM through Scripthttps://www.inogic.com/blog/2014/12/how-to-show-filtered-lookup-dialog-in-dynamics-crm-through-script/
https://www.inogic.com/blog/2014/12/how-to-show-filtered-lookup-dialog-in-dynamics-crm-through-script/#commentsFri, 19 Dec 2014 11:09:46 +0000http://www.inogic.com/blog/?p=1104Read More »]]>We had a requirement where in we were supposed to show a Filtered Custom Lookup on form load. By Filtered Custom Lookup, it meant that we were supposed to create a Lookup dialog similar to CRM Filtered lookup (Filtered Lookup value changes on the basis of other Lookup on which it is dependent) dialog. The lookup has to be filtered on the basis of a value in the lookup field which was there on the form.

Now the question was, how were we supposed to achieve this? We had already done a Lookup Dialog to show all the records for an entity, but this was something new and enthralling.

We dived into it and after a few hours of R&D, we came up with a solution. This blog is entirely dedicated in explaining and implementing that solution.

Let us begin with our entity structure which comprised of an entity called Contractor and it was in N:1 relation with Project and Payment Schedule where as Payment Schedule was in N:1 relation with Project.

The requirement was to show the Filtered Custom Lookup dialog containing Payment Schedule records, related to the Project (Lookup field) selected on the Contractor, on form load of Contractor.

Screenshots:

Note: Lookup Dialog seen in the below screenshots is a Custom Lookup Dialog opened on form load using JavaScript.

Below screenshot shows the Project selected as Test Project having Payment Schedule records for it as a result of which we can see that record in the Lookup Dialog.

Below screenshot shows the Project selected as Test Project 2 and Test Project 2 has no Payment Schedule records for it and as a result we cannot see any records in the Lookup Dialog.

]]>https://www.inogic.com/blog/2014/12/how-to-show-filtered-lookup-dialog-in-dynamics-crm-through-script/feed/0Enhanced Business Process Flow in CRM 2015 – VEGA releasehttps://www.inogic.com/blog/2014/10/enhanced-business-process-flow-in-crm-2015-vega-release/
https://www.inogic.com/blog/2014/10/enhanced-business-process-flow-in-crm-2015-vega-release/#commentsTue, 28 Oct 2014 13:55:13 +0000http://www.inogic.com/blog/?p=1037Read More »]]>As you may be aware, Microsoft has come up with Business process flow feature in CRM 2013 which provides assistance to users in CRM using stages to be followed in order to complete the whole process.

Earlier Limitations:

Strictly Linear Process: Business processes are designed to work only in linear manner, no branching is allowed.

Cannot Revisit The Entity More Than Once: Cannot visit the same entity again in flow single business process flow.

No programmability support

New improvements in VEGA:

Here, you have the ability to define branches as well as branching rules. You can create and update branching rules through UI and it can be evaluated in real time. Branching rules must be based on the steps involved in stages.

Steps and stages can be configured easily where branching rules are defined.

Selection of entity relationships – It can be optionale. previously in CRM 2013 if you wanted to add an entity in business process flow, then it was necessary for the entity to be in 1:N relationship with another entity but now, if there is no 1:N relation between the two entities, you can still add that entity in process flow, the only requirement is that the entity must be enabled to create BPF.

Programmability through client API: Programmatically updates process state and hooks on to process events.

To elaborate this further, we can consider a scenario where you sell ‘Software’ as a product in your organization. The requests you receive on daily basis get classified as leads, some of them get Qualified if they are further interested in evaluating the trial of the software, if not, then the lead get disqualified.

Once a lead is interested in trial, the lead gets Qualified and an Opportunity gets created. Once the trial is completed, we ask if a Quote is required. If no, we close the Opportunity but if it is a yes, we create a quote and deliver the quote. After that, we offer maintenance for the product, if the Opportunity is interested in maintenance, we update the Quote, otherwise we create Invoice and at the end close Opportunity.

Now, we have created a Business process as follows. This shows the updated UI for designing the Business process flow.

This provides UI to edit ‘Stage Name’, ‘Entity’ to be selected, ‘Stage Category’, then ‘Step Name’ and their Value which includes the fields required to show on BPF followed by the ‘Required’ status of the steps.

Further, you can see the ‘Insert stage’ button and the ‘Add branch’ button at the bottom of the stage as shown below:

Insert stage: Adds a new stage in the process.

Add Branch: Adds branching in flow. When you click on ‘Add branch’ button, it will allow to check some specific conditions and on that basis the branching will be done as shown below:

As you can see above, it will apply ‘if’ criteria to check condition, where we can specify field criteria and save the condition. Once it is saved, it will allow you to insert stage on that basis as shown below. It also allows to add else condition if the criteria to flow the process in another direction is not fulfilled. You can combine multiple conditions using And/or branching techniques.

Here, it will also allow you to set relationship with another entity. If no relationships exist, then you can set it to none. Likewise, you can create complete BPF and it can be used as shown below:

Likewise, you can create a complete BPF and it can be used as shown below:

As you can see below, it currently shows only two stages ‘Qualify’ and ‘Close’ and the step ‘Is Interested In Trial’ shows value as No.

If you select ‘Is Interested In Trial’ as yes it will change the flow with additional stages as shown below:

Similarly, after qualifying the lead, it will go to another stage where if you select ‘Is Require Quotation’ as yes, it will show some additional stages as ‘Deliver Quote’, ‘Offer Maintenance’ etc. as shown below:

This is how you can include business process flow in CRM using advanced features.

Note:

The process can span across maximum 5 unique entities

It can include maximum of 30 stages per process and 30 steps per stage

Each branch can be no more than 5 levels deep

Hope this helps!

]]>https://www.inogic.com/blog/2014/10/enhanced-business-process-flow-in-crm-2015-vega-release/feed/0Issue with the Lookup View selected during Customizations not being honored in Tablethttps://www.inogic.com/blog/2014/10/issue-with-the-lookup-view-selected-during-customizations-not-being-honored-in-tablet/
https://www.inogic.com/blog/2014/10/issue-with-the-lookup-view-selected-during-customizations-not-being-honored-in-tablet/#commentsFri, 17 Oct 2014 10:14:03 +0000http://www.inogic.com/blog/?p=1015Read More »]]>Issue:

Usually when placing a lookup field on the form, we also select the view based on which the records should be displayed in the lookup window. The same behavior is expected for the Tablet application as well.

But we came across a scenario where the lookup displayed all records irrespective of the view selected in the tablet application. The web app works fine but it is only tablet application that does not consider the view selected.

For example, like we have set custom entity lookup “Industry” on “Account” entity as below:

And we have set “Active Industries” view for that lookup control, which should only show Active Industry records as shown below:

So even though we have selected “Active Industries” view it will still show inactive records. If we search for “clothing” industry, it displays the result even though it is inactive in CRM.

Solution:

Upon reviewing this issue further we noticed that the entity on which the lookup was based was not enabled for viewing on Phone and Tablets.

Once you configure the entity for use on Phone and Tablets, the problem is resolved.

Configuring the option:

Navigate to Settings –> Customizations and Select the entity which you want to configure for tablets as shown below:

After doing this changes we can get records as per view filter criteria for lookup.

Note: Please note the custom views you create for entities in CRM are not available in tablets and phones.

]]>https://www.inogic.com/blog/2014/10/issue-with-the-lookup-view-selected-during-customizations-not-being-honored-in-tablet/feed/0Using “PreEntityImage” and “PostEntityImage” in Workflowshttps://www.inogic.com/blog/2014/10/using-preentityimage-and-postentityimage-in-workflows/
https://www.inogic.com/blog/2014/10/using-preentityimage-and-postentityimage-in-workflows/#commentsWed, 01 Oct 2014 10:23:06 +0000http://www.inogic.com/blog/?p=976Read More »]]>As we all know that we can always read Pre image and Post image in the plug-in for various purpose. However, in workflow, we may sometimes want to read Pre Image for some purpose. Now we can also read Pre Images and Post Images in the workflow using Execution Context. It uses the same Plug-in Architecture and hence we can use it to read Pre Images and Post Images. However, this concept is not documented in the SDK so it might be unsupported.

The purpose could be to read the previous values from the entity record. For e.g. We may require it for Rollup Calculations in the Update operations since we need to see what the previous value in the Entity Record was and according to it we can perform some action on the same. For instance there is a field named as “No. of contacts” on the Account, which maintains the number of sub contacts associated with the account, so when we write a workflow on update of contact (Parent Account) field, we need to read the Pre Image to update Old Account record field and Post Image to update new account field.

To read pre entity image you can read it like below:Entity contractedProductPreImage = context.PreEntityImages["PreBusinessEntity"];
To read Post Entity Image you can read it like below:Entity contractedProductPostImage = context.PreEntityImages["PostBusinessEntity"];

Here, names such as “PreBusinessEntity” and “PostBusinessEntity” are used to read the Pre and Post Images.

At times, it may not required to read Post Image from context as we can read the updated entity record by retrieving its data from the organization service or from the Input Parameters. In order to get the Previous Entity Record Values, the only option to get it is to read it from the Pre Image.

The availability of Pre Image and Post image also depends on the events. As we know, workflows can also works in Synchronous mode i.e. Real Time Workflow. Below is the table that tells us when we can read Pre Image and Post image during different events and in different scenarios:

Events

Pre-Image

Post-Image

Background Workflow

Create

NO

YES

Update

YES

YES

Delete

YES

NO

On-Demand

YES

NO

Real-Time Workflow

Create-After

NO

YES

Update-Before

YES

NO

Update-After

YES

YES

Delete-Before

YES

NO

On-Demand

NO

NO

Conclusion:

We can read the Pre and Post entity images in the workflow depending on Synchronous/Asynchronous Workflow and its events.

]]>https://www.inogic.com/blog/2014/10/using-preentityimage-and-postentityimage-in-workflows/feed/0Update fetch query of System/User view dynamicallyhttps://www.inogic.com/blog/2014/08/update-fetch-query-of-systemuser-view-dynamically/
https://www.inogic.com/blog/2014/08/update-fetch-query-of-systemuser-view-dynamically/#commentsMon, 25 Aug 2014 04:19:11 +0000http://www.inogic.com/blog/?p=857Read More »]]>Based on the client requirement sometimes it is needed to update the system/user view to filter record as per needed. In your query you need to apply outer join which won’t be possible through Advanced Find so in that case you need to update the fetch query of System/User view dynamically. Below is the sample code how to update the fetch query of system/user view dynamically using link type as Outer Join. Below is the query which describes that show only those active contacts with no opportunity exist in contact and those opportunities which was not closed in last 9 months using Outer Join. Below query won’t be possible through advanced find.

You can get the GUID of view from the URL of view. Refer the below screenshot:

Note: The attributes you define in a fetch query to show in the view should match with the columns that have been added in the view manually. Refer the below screenshot:

]]>https://www.inogic.com/blog/2014/08/update-fetch-query-of-systemuser-view-dynamically/feed/0Duplicate Detection is back in Microsoft Dynamics CRM Spring Releasehttps://www.inogic.com/blog/2014/07/duplicate-detection-is-back-in-microsoft-dynamics-crm-spring-release/
https://www.inogic.com/blog/2014/07/duplicate-detection-is-back-in-microsoft-dynamics-crm-spring-release/#commentsTue, 08 Jul 2014 06:41:42 +0000http://www.inogic.com/blog/?p=717Read More »]]>How good were the old days of CRM 2011 that even at the point of creation of records you were notified on the entity form itself that the particular record is a duplicate record and hence the data duplication was reduced to a considerable amount. But suddenly in CRM 2013 Duplicate Detection was removed partially i.e., it was no more available on the entity form, at the time of new record creation but it was available on the Home Page of all those entities for which duplicate detection was enabled.

In the Spring Release, Duplicate Detection is back with all its old charm plus a new feature that would be further explained in this blog.

Prior to Spring Release Update if you enabled Duplicate Detection for any of the entity the only way to understand that we have duplicate data in our records was to run Duplicate Detection Job for that entity.

Things have now changed a bit after the Spring Release update or we can say things have been brought back to normal by reinstating the same old feature of detecting duplicates at the time of Record Creation as well as a new feature that detects duplicate records at Auto Save as well. This reduces the extra steps to some extent that were needed prior to Spring Release update in order to have the Duplicate Detection Job work. However, the same procedure can be followed post the update as well, since it is an essential part for duplicate detection and cannot be removed.

Duplicate Detection on the entity form:

1. At the time of creation of the record:

For this demo, we have created an Account with the name “Apollo.” Now, we are trying to create another Account with same name. So, on the entity form itself we get the Duplicate Detection result. You have the option to Save anyway or Cancel.

Note: Even while creating record using Quick Create Form, you’ll get the Duplicate Detection result there itself.

2. Auto Save:

Consider you have recently upgraded to Spring Release and you already have duplicate records. You are now updating one of the duplicate records and you mostly rely on Auto Save to save the updates. In that case, you’ll get a notification as shown in the below snapshot:

This is indeed a handy feature that saves our time by detecting duplicate records on the spot and sparing us from going the conventional way.

3. Qualifying Lead:

If you try qualifying a Lead record with the Company Name matching with the existing Account record then in that case youll get a Duplicate Warning dialog where you can associate the existing company(Account record) with the current Lead record or else you can Continue creating a new Account record with same name.

Note: In the above demo we are detecting duplicates by same Account Name. However, it is not simply restricted to Name, you can create your own rules for other fields for other entities as well.

Verifying Duplicate Detection through programming:

While creating a record for an entity programmatically, we observe that even if Duplicate Detection is enabled for the entity, it does not work and it still allows to create the duplicate record for the entity.

In order to enable Duplicate Detection we have to enable “SuppressDuplicateDetection” parameter in the CreateRequest while creating the record for the entity programmatically.

If you create records programmatically using CreateRequest with the parameter SuppressDuplicateDetection as false, then duplicate detection will take place and if the record is a duplicate record then it wont be created and the below error will be shown:

“A record was not created or updated because a duplicate of the current record already exists.”

As you can see, we need the CreateRequest to enable Dup detection while creating record and therefore this feature is not available when creating records using oData.

Duplicate Detection also works while importing records using the OOB import data functionality.

You can also enable duplicate detection and retrieve duplicates programmatically using the RetrieveDuplicatesRequest. An example for the same can be found on MSDN.