Company Blog Development

Recently, I published a blog post on creating a PowerApp that validates a Credit Card number, and displays the correct image next to the card based on the Card number. As my first PowerApps Component Framework application, I took the same logic of the PowerApp that I created, and decided to create a PCF control that will do the same. I have also created a training guide for this, so that you can follow this logic step by step, which you can download at the bottom of this post.

When displaying entity lists on a web page, there is usually a default column in a view which is displayed as a hyperlink. The link to the page is displayed based on the Web Page for Details View and the ID Query String Parameter Name attributes on the Entity List form (as shown in the image below). The problem is, what happens if my page that is displaying the Entity List already has query string parameters, and you want to keep those parameters on the next page that you are going to display.

It is a pretty known practice today, that when creating a web application that requests data from customers, certain fields are masked so that the system can prevent the entry of incorrect data. This has been done in desktop applications for a long time and is now also very common in web based applications.

Recently I was working on a project, where the client needed all fields to have placeholders for accessibility reasons. When looking at the attribute metadata of the Entity Form, we are allowed to enter some text above or below the textbox control (or above the label), but the option is not available to prepopulate the control with some text when there is no data in it. After seeing a few community questions on how to implement this, I thought to share the solution.

Recently we had a requirement to change the Lookup Control in the Portal to look like a hyperlink, so that when the user clicked on the Hyperlink it would pop up the Lookup Dialog.
The Lookup control was displayed as part of an entity form, so the only way to really do this was with jquery.

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. 

The requirement was as follows: Gather the Business Information of the Signed in Contact in a Registration form, and pass some of the information from the Registration form to the Application form.

Now that we have configured our SharePoint and Azure environments to allow us to create an API that will be called from CRM and process SharePoint requests, we will dive into the actual API.

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.