In a recent project, we had a requirement to display cases to the portal that are associated with either Contacts or Accounts. Our case entity had a related entity called Case Contacts, and our account entity had a related entity called Account Contacts. The account entity had a list of all the cases associated with the account.
For the final part of the series, I am going to demonstrate and explain the portions that resides inside Dynamics CRM (or can possibly be built inside other applications). The solution includes an HTML web resource that contains a subgrid (using JQWidgets, but can be replaced with any third party jquery grid or bootstrap table). The subgrid contains a list of documents that are contained in SharePoint, and provides the functionality to upload or download additional documents.
Recently we had the need to create multiple Entity forms in our portal, and be able to pass multiple parameters between the different pages of the portal. As it seems, you are able to pass a single parameter (such as the id of the created record) to the next form, but passing multiple does not seem to be the case. For this particular scenario, using Web Forms was not an option.
A few years ago we had some requirements where we needed to pop up an html web resource where users could select a value from a related entity (in a manner similar to a lookup control). We originally developed this as a regular drop down and retrieving the values using Rest messages, but later on decided to change this and have the user click on a “lookup” style control inside the web resource to get this working.
The next part of this solution is to configure Microsoft Azure. If you do not have an Azure account, you can create a Trial account of Pay as you go account. If you are a partner or have a BizSpark subscription you get a certain amount of credits per month, which should be more than enough for the type of implementation that needs to be done using Azure.
The easiest part of this solution is to configure SharePoint. There is no custom development involved, but just the creation of the document library, the folders, custom lists and the attributes that we want to use for the solution. We will need to start with the creation of the custom lists as they will be used for the creation of the lookup attributes.
Over the past few years we have encountered multiple scenarios where the Out of the Box SharePoint Integration component, did not fulfill the requirements of our clients using Dynamics 365 and SharePoint. Some of these had to do with capturing additional attributes in SharePoint, and sharing similar data across different entities in SharePoint.
Recently I had a requirement to provide cloning capabilities for one of the projects that I was working on. It wasn’t so simple as to just clone an individual record, but also provide the ability to clone the relationships.
In a few of my recent implementation I had the requirement of making modifications to many child records. Some of these processes required the use of an external SSIS package that executed a console application and ran on a schedule, but more recently I had a requirement to simply deactivate multiple child records. This of course can also be done using cascading rules, but it’s a little more complicated once you involve custom filtering.
In this third post of the series, we will review the changes between the properties and methods of the control based on the getControls Collection or the Xrm.Page.getControl method. The tables below will show the base methods of the control, as well as specific method for specific control types.
