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.
As in any project, either CRM or Web application, the requirement to have JavaScript libraries that can be accessed across multiple files is common. In Dynamics 365 Portals, the use of Web Files is how we have the ability of create files that will be shared across the entire portal, or possibly only sections of the Portal. These common files are stored in the Web Files entity. This issue is that when we try to add a JavaScript web file, we get an error that the attachment is blocked. Web Files use the Notes entity to store the actual files that we add to the Web File entity.
Recently we had a requirement for one of our Dynamics Portal projects that I thought we could share with the community. The requirement was pretty simple. We had a many to many relationships between Contact and Account (so that a contact could belong to multiple Organizations) that needed to be displayed in a dashboard.
Microsoft Dynamics 365 Online comes with a Portal license which allows users to easily create forms that will capture user input and have that data populate the records of their different Dynamics CRM entities. In many community posts, I still see requests of how this process is done. In the following article I will demonstrate the step to create a web form in CRM and publish that form to the portal on the web site.
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.
In the second part of the installation of configuration of Azure Logic Apps with the On-Premise Data Gateway, we will review the requirements that are need inside of the Azure Portal. This will cover the creation of the Data Gateway resource, the Logic app and the creation of the Trigger and Action inside of the Logic App designer.
I recently had a requirement to configure Logic Apps for use with the Azure On-Premise Data Gateway and connection to an Oracle On-Premise database. Since I did not have access to the Oracle database at that point, I decided to try this out with an On-Premise SQL Server database as the logic should have been similar. I downloaded the Azure On-Premise Data Gateway and installed it on the server, and the configured the Azure environment to connect to the server and post data back to Dynamics 365.
