Demystifying Dynamics 365 Portal Projects - Part 3 Entity Forms, Entity Lists

Photo by Emanuel Villalobos on Unsplash

Part 1: DEMYSTIFYING DYNAMICS 365 PORTAL PROJECTS - PART 1 PLANNING & ANALYSIS

Part 2: DEMYSTIFYING DYNAMICS 365 PORTAL PROJECTS - PART 2 PROFILE PAGE

In the previous 2 parts, I covered Planning, Analysis and Design as well as customising Profile Page of a Portal Project. In this post, I am going to write about few other scenarios related to Entity Forms, Entity Lists and Web Forms. Details about Entity Forms can be found here and you can read more about Entity Lists here. This post will consist of few short How-To sections and I hope you can make use of the time I spent on these scenarios.

Display Owner Field in Portal

Dynamics Portal by default, hides the Owner field on its web pages. It means even if you have owner control in your CRM form, when you create a web form to interface an Entity Form, the owner field will not be displayed on the form in portal. The solution to tick "Show Owner Field" on the Entity Form to display Owner field on Portal Page.

Set optional CRM fields to Mandatory in Portal

By default, portal renders CRM forms in their original form. For example, if you make First field optional and mobile phone mandatory, the portal shows the name as optional and mobile. There is an option which you can set Business Recommended fields to be mandatory on portal. However, for this you will need to configure entities in CRM and if you want to fill a long form with lot of Business Recommended fields, it becomes problematic. The solution is to use Entity Form Metadata. You can keep all your CRM fields optional and in return create Entity Form Metadata for each field which you want to make mandatory and tick on "Set as Required" field in the metadata definition.

In case if you want to ensure validation based on a format, you can use Regular Expression like below. 

Conditional hype-link/buttons on Entity Lists

You can use CRM Grids on Portal pages to show list of records. For this purpose, you will need to use Entity Lists. Entity Lists allow you to define controls on top of portal grid to create, update or delete records or even run workflows. Whenever you define a new action on grid, the portal adds a button for each record which you can use to perform an operation. 

By default, the action you define for a grid will be the same for all records. However, there are situations in which you want to take different actions based on some conditions. For example, in the above case, I want to be able to cancel an application if the status is New but when the status is Submitted, I want to disable canceling the application but Edit and View application. In this case, the solution is to use Actions in conjunction of Metadata filter. This post from Colin Vermander helped me a lot to identify this solution.

1. Let say for Cancel, you run a workflow, for Edit and View actions, you will Edit and View application in two different forms.
2. You will need to create a WORKFLOW action and two EDIT actions.
3. In each EDIT action, select Webpage as target Type to take EDIT and VIEW actions.
4. You will need to use FILTER CRITERIA in each action to instruct portal when to show/hide each button.
5. Create FetchXML query filtering records based on the condition you wish to use
   
   
   <fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
     <entity name="incident">
       <attribute name="name" />
       <attribute name="createdby" />
       <attribute name="createdon" />
       <order attribute="createdon" descending="false" />
       <filter type="and">
         <condition attribute="status" operator="eq" value="new" />
         <condition attribute="statecode" operator="eq" value="0" />
       </filter>
     </entity>
   </fetch>
6. If you place the above FetchXML in Cancel action, it will display CANCEL button for records fulfilling the above criteria

Hyperlink behavior of Entity List

The entity list by default add a hyperlink to "View Details" if you set the value of "Web Page for Details View". In case if you don't set the value of "Web Page for Details View" but instead define an Edit action on the list, the entity list adds a hyperlink linking the record to the Edit page. 

There are situations where you want to remove the hyperlink from the list. So, you can use the following code:

$(".entitylist.entity-grid").find(".details-link").val("href").contents().unwrap();

1. $(".entitylist.entity-grid") is the client-side reference to the list
2. .details-link is the CSS class of the hyperlink
3. And contents().unwrap() removes the clickable behavior of the hyperlink 

File Upload Control

The file upload control is added to a form when you choose to add the control by configuring options in the "Add Attach File" section of the entity form.

Allowing specific files types in the control can be set by setting "Access File Types". This field's length is set to 100 but it is recommended to increase it to 150 or 300 if you need a longer text in this field. Also, note that you must use ONE MIME type for multiple file types. For example, if you want to allow ZIP, PDF and DOC files, you CANNOT use application/zip, application/msword and application/pdf separately. Instead you should use application/.zip,pdf,msword.

Validation

Validation is a topic which will be in every portal project you implement. You will always need to ensure users input data in a right format to ensure data is clean and can be used in your CRM solution. However, adding validation by using Metadata or JavaScript is only one side of the coin. You must ensure that data is validated on server side as well. For example, you cannot solely rely on hiding Create Button to prevent a user to submit forms because user can simply use developer option of the browser and shows the Create button and simply overrides your desired behavior.

That is why it is essential to ensure that you use Server-Side validation along with Client-side validation to deliver a secure solution. Server-side validation can be implemented at the workflow and plugin level or by use Liquid template. In the above example, we hid the EDIT button if the application status was not NEW. So, ensure that the user does not have the ability to Edit records, I have used Liquid Templates to decide when a record is editable.

{% assign querystringId = request.params['id'] %}
{% assign querystringStepId = request.params['stepid'] %}
{% assign pageTitle = page.title %}
{% if pageTitle == 'Edit Case' %}
{% if {{querystringId}} == null and {{querystringStepId}} == null %}
{% fetchxml new_query %} 
<fetch version="1.0" output-format="xml-platform" mapping="logical" returntotalrecordcount="true" distinct="false">
<entity name="incident">
<attribute name="name" />
<attribute name="createdon" />
<order attribute="name" descending="false" />
<filter type="and">
<condition attribute="statecode" operator="eq" value="0" />
<condition attribute="status" operator="eq" value="Submitted" />
<condition attribute="owner" operator="eq" value="{{User.Id}}" />
</filter>
</entity>
</fetch>
{% endfetchxml %}
{% if new_query.results.total_record_count < 1 %}
{% if page.adx_webform %} 
{% webform id: page.adx_webform.id %}
{% endif %} 
{% else %}
<div class="alert alert-danger" role="alert">
You cannot Edit a submitted application.
</div>
{% endif %}