In this post, I am going to review some of my favorite and anticipated features in the Power Platform, especially Power Apps Portals and Model Driven Apps.

Let’s start with some of the anticipated changes to Power Apps Portals. Screenshots were not yet available for the Power Apps Portals, so I will just list some of them out:

Power Virtual Agents as a component of the Power Apps portals Studio. This will allow portal makers to drag and drop a Power Virtual Agents bot component on their portal, similar to the way that it is done with the Power BI Component.

Power Apps component framework control suppose in Power Apps portals. This will allow app makers to create code components to use across apps. As part of the initial release, this will include support for code components created sing Power Apps component framework inside of Power Apps portals. This feature is expected to be in Public preview on December 2020.

Power Apps portals web API General availability. This feature will make Power Apps portals CRUD web API generally available for all customers. It is expected to be in GA in February 2021.

Next, let’s look at some of the changes that are coming to our Model-driven apps.

Makers can add custom page in the model-driven app designer. This enabled model apps to create custom layouts and use PCF controls in ways that are not possible with the model-driven app form and dashboard pages. Using the modern app and sitemap designers, custom pages can be added enabling more flexibility in the components, behaviors and visuals. These pages are authored using Canvas designer with no code/low code support and configuration of controls and components. These enhancements will be in Public preview in December 2020.

Modern model-driven app and sitemap designers enable more productivity. This enhancement enables authoring model-driven apps and sitemap within context and aligned with the other designer in the Power Apps shell. The new app designer makes app authoring easier, with page based authoring approach that complements existing sitemap/entity authoring. A preview canvas is added to clarify the parts of the app that are being edited, and leverages the modern entity, form and view designers as well as providing access to other classic designers. These enhancements will be in Public preview in December 2020.

New and improved global search experience in model-driven apps. The Global search experience in model-driven apps is easy, intuitive and modern. The search bar provides suggestions on recent records, automatic records suggestion on types query, improved search results page, high quality results that allow users to search for information quickly and easily. The improvements to the search experience will also allow users to use relevance search on the desktop. This will be in GA in October 2020.

Improved model-driven app header, sitemap and app switching. The model driven app shell has gone through various enhancements and has an updated Office app launcher. When clicking on the app name, it will open the inline app switcher. When the website is opened without an app parameters, the message bar enabled switching to a specific app. The classic sitemap controls have been replaced with modern sitemap controls for better usability. This will be in GA in October 2020.

There are a lot more enhancements that the ones I mentioned in this post, and not only in Power Apps, but also in Power Automate, Power Virtual Agents, AI Builder, Power Platform Administration and the Common Data Model.

You can view or download the full Power Platform 2020 release wave 2 plan from here.

The post Power Platform 2020 Release Wave 2 plan appeared first on Aric Levin's Digital Transformation Blog.

A few years back we launched our first Dynamics application where one of the requirements was the ability to scan files that were uploaded by end users, whether from the Dynamics application or from Dynamics Portals. These documents would be uploaded to an Azure Blob Storage Container, and as they were uploaded copies to a separate quarantine container until they would be scanned.

At the time our options for a Virus Scan solution were limited. We had an On-Premise Virus Scanning McAffee appliance that was available to us, and we ended up with a solution that would check every few minutes if there were pending quarantined uploads, we would scan them and then move them from the quarantine container back to the clean container.

The below diagram is the high level solution that was implemented.

This solution worked fine when the traffic was not high, but we did experience at time of high traffic that it would not complete processing the files in the allocated time, and needed a separate solution. The heavy traffic was mostly experienced in the last few months during the COVID-19 pandemic where the amount of applications that we received were substantial higher.

We needed to find a solution to have a quicker turnaround. We have used the Azure Service Bus in previous projects to pass information between our Dynamics environment and our On-Premise servers, so this should work. We would change the process to handle this in real time. As the file is uploaded to our Azure Storage Container, we would immediately fire the Azure Service Bus.

I have written a few posts about Azure Service Bus in the past, so if you are interested in that implementation, click here.

This solution would call the Azure Service Bus listener as soon as the file is uploaded and sent to the Virus Scanner. We could also bypass the need of the quarantine container immediately and only send it there after the Scan if the file was infected. The diagram below shows the new solution.

As I mentioned that we are in GCC and there are a lot of limitations both from the list of available connectors and the implementations that can be done, but I wanted to address this as if it was done in a Commercial Cloud.

I noticed a couple of weeks ago that Microsoft announced the availability of a new Virus Scanner connector called Virus Total. I was not aware of other options but when I did some searching I encountered the availability of three connectors that have the capabilities of scanning documents (or document streams): Virus Total, Cloudmersive Virus Scan and Microsoft Defender ATP. This was great, it would simplify this logic.

Regardless of which Virus Scanner you are using, you will need to get an API key from the vendor of the Virus Scanning connector in order to establish a connector. Depending on your load of scanning the your cost can be free or cost you some money. I think most of these vendors offer about 4000 free scans a month.

If you are using Dynamics Portals or Power Apps Portals, you can upload your documents to either an Azure Blob Storage Container or SharePoint. The following flow executes when a new filter is uploaded to a SharePoint folder, scans the file for Virus and creates a CDS record with the Status of a Successful or Unsuccessful scan. Let’s review this step by step.

The first part is going to be our trigger. When a new document is uploaded to SharePoint (or Azure Blob) the flow will be triggered to get the content of that document. In case of SharePoint, the single step will provide us with the Content of the Document. If using Azure Blob, we will need an additional step to get the content of the blob based on the path of the file.

Next, we will call the Scan file for Viruses. In this case we used the action from Cloudmersive, but any of the connectors should work just fine for this.

After the scanning is complete we will add a condition to our flow that looks for the result from the Scan. The CleanResult will return True if there are no Viruses and False otherwise. We can then determine what action we want to do. Delete the file, move to quarantine container or folder, write a record, etc… Your choice. In our case I just wrote it to CDS.

That is basically it. You can add additional logic as you see needed, but this is all it takes. Again if you are in Government Cloud or your IT is blocking certain connectors this might not be the solution for you, but if you are able to implement this, it might save you a lot of trouble and headaches.

The post The Road to modern Virus Scanning appeared first on Aric Levin's Digital Transformation Blog.

Let’s start from the beginning. The first thing that we need to do is to create the Web Link Set that we are going to use. In our case, we are using a web link set called Legal. Notice that the Display Order is important, because we are going to write that back to the record every time we navigate from one page to the next.

The screenshot below shows a sample of the Web Link view for our Legal Web Link Set.

The next thing that we want to do is create the field on the entity that will capture that page that we are currently on (or the change of the record during submission. We will need to add the field to the entity, but also add the field to every tab (entity form) that is displayed on the application. The first screenshot shows the field that is created on the Application entity. For our purpose we used two field, but only the Last Page completed field is required.

Once the field is created, we will add that field to all of the tabs that are displayed in Entity forms. We have a custom form called Portal Application, where everything that is displayed on the portal is set. In our Legal Advice page for example, you can see that the page contains the Last Page Visited and Last Page Completed so that they can be populated on the portal form.

We have a web template that displays the navigation area of the application. In that web template, we are retrieving the value of the last page completed, and will perform some logic on it.

We start by verifying the template has a unique identifier that will allow us to retrieve the application, and assigning the app variable to the application entity, and then setting the category and the last page completed fields to the assigned variables.

{% if request.params.id != null and request.params.id != empty %}
   {% assign app = entities["bac_application"][request.params.id] %}
   {% assign application_category = app["bac_applicationcategoryid"].name %}
   {% assign last_page_completed = app["bac_lastpagecompleted"] %}
{% endif %}

We then retrieve the Web Link set for the category that we specified

{% case application_category %}
  {% when 'Legal Assistance' %}
    {% assign app_nav = weblinks["Legal"] %}
  {% else %}
    {% assign app_nav = weblinks["General"] %}
{% endcase %}

Now that we have the Web Link Set and the Last page completed, we will loop through the Web Link Set and perform a few checks. We will check the application status to verify if the application has been completed or not and check the value of the last page completed to verify whether or not we have already reached a particular page. We will also check if the current page is the same as the Url of the page on linkset so that we can have different style for the current page to notify the user this is the page we are on.

In every condition we include a link to the Navigation Item which contains that code to the styling of the link, passing the style that the link should display. The loop code is displayed below:

{% if app_nav %}
    {% for link in app_nav.weblinks %}
        {% if request.params.id != null and request.params.id != empty %}
            {% if link.adx_displayorder > 20 %}
                {% if link.adx_displayorder <= last_page_completed %}
                    {% if (application_status == 'In Progress') %}
                        {% include 'Application Navigation Item' with link, special_class: ' cvd-list-row-thread-completed'  %}
                    {% else %} 
                        {% include 'Application Navigation Item' with link, special_class: ' cvd-list-row-thread-submitted'  %}
                    {% endif %}
                {% else %}
                    {% if link.url == request.path %}
                        {% if forloop.last %}
                            {% if (application_status == 'In Progress') %}
                                {% include 'Application Navigation Item' with link, special_class: ' cvd-list-row-thread-completed'  %}
                            {% else %} 
                                {% include 'Application Navigation Item' with link, special_class: ' cvd-list-row-thread-submitted'  %}
                            {% endif %}
                        {% else %}
                            {% include 'Application Navigation Item' with link, special_class: ' cvd-thread-current'  %}
                        {% endif %}        
                    {% else %}
                        {% include 'Application Navigation Item' with link, special_class: ' '  %}
                    {% endif %}
                {% endif %}
            {% endif %} <!-- link.adx_displayorder > 20 -->
    {% endfor %}
{% endif %}

Since we are also displaying the controls on the form, we need to add JavaScript code to hide the controls and set the value of the next page on the last page completed, so that when the page is submitted that will be written to the entity record. The code below shows the JavaScript.

$(document).ready(function () {
   var url = window.location.href;
   $("#bac_lastpagecompleted").parent().parent().hide();
   $("a").filter(".page-link.cvd-link-navigation.cvd-custom-event").each(function () {
      if (this.href == url) {
         var maxPageNumber = 0;
         if ($("#bac_lastpagecompleted").val() != "")
            maxPageNumber = parseInt($("#bac_lastpagecompleted").val());
         var displayOrder = parseInt($(this).attr("adx_displayorder"));
         var nextPage = displayOrder;
         if (nextPage > maxPageNumber)
            $("#bac_lastpagecompleted").val(nextPage);
      }
   });
});

Now that we have completed our review, we can take a look at the final result.

The post Showing page status of multi-page forms in Power Apps Portals appeared first on Aric Levin's Digital Transformation Blog.

Power Virtual Agents allows user to quickly and easily create powerful bots using a graphical no-code graphical experience. To start creating our first bot, we navigate to powerva.microsoft.com or aka.ms/TryPVA which will redirect to powervirtualagents.microsoft.com.

Sign in to your account or Sign up for a trial, and you will be ready to start developing your first Bot. The Home Screen of Power Virtual Agents is similar to other Power Platform applications. On the left side you will have the Navigation, and on the top right your shortcuts and settings.

To start with your first bot, click on the bot button in your Office 365 Navigation Header (shown as #1 in the image below). This will pop open the bots panel. The bots panel will display the New bot button (shown as #2 in the image below) as well as any existing bots that you may have already created and want to edit.

Once you click on the New bot button the Create a new bot popup will be displayed. Enter the name of the bot that you want to create, and under More options you can select the environment where you want to use the bot (in case you have more than a single environment). Click on the Create button when you are ready to create the bot.

Once the Create button has been clicked, Power Virtual Agents will start the process of creating the new bot. This can take a few minutes to complete. In the interim the screen below will be displayed.

There are many different things that we can do to create a fully functional bot, but in this case we will create a simple bot with just a few questions.

When the bot has been created, we can click on Topics to start authoring the different topics that we want to use for our bot. Topics have trigger phrases, which are phrases, keywords or questions that are likely to be entered by a user regarding a particular issue. These topics are used to define how the bot should answer and what actions it should perform. There can be up to 1000 topics in a bot.

To start creating Topics we first need to click on the Topics link on the left hand navigation.

Once the Topics page opens up, we click on the New topic button in order to create a new Topic. We can also click on an existing topic to make changes to it. The Topic window shows up. We enter a name and optional description for the Topic, and then start entering Trigger phrases.

For example, if we want to respond to questions regarding a Tax Payer Id Number, we can add a few triggers such as:

• How many digits is my Taxpayer Id Number?
• Do I need to enter a hyphen or dash in my Tax Payer Id?
• Can I enter an ITIN instead of EIN?

The screenshot below shows a sample Required fields trigger for First Name, Last Name and Email Address and a few possible triggers.

When all the triggers have been specified, we Save the Topic, and click on the Go to authoring canvas button on the right hand side to start authoring the logic that will be displayed when the user asks the question.

Within the authoring canvas we will see a first node containing the Trigger Phrases. We can add different nodes after the Trigger Phrases which include:

• Ask a question
• Call an action
• Show a message
• Go to another topic
• End the conversation

In this particular example we will just add a couple of messages after the questions to display information about the reasoning for asking the information that we asked.

After authoring the topic, we can save the topic and will see it in the list of Topics on the Topics page. You will notice the Topics have an On or Off Status, which means that you can create Topics and disable them until they are ready to use.

The final step in designing the bot is publishing it. After a bot is published, it can be used in a wide variety of applications such as Custom Web Site, Portal, Teams and more.

Click on the Publish navigation link on the left hand side, and on the Publish page, click on the Publish button to Publish the bot.

After the bot has been published, we can click on the demo website to see how the bot will look and behave in response to particular actions.

When we are satisfied with the bot, we can add it to our Power Apps Portal site or page, by adding the custom code to the Portals page. We navigate to the Channels page by clicking on Channels on the left navigation, and then select the Custom website channel.

First, we copy the code from the Custom Website under the Embed code panel. Then we open the required page on our Power Apps Portal site, and click on the code editor. In the area where we want to display the bot, we will paste the code:

<iframe src=”https://powerva.microsoft.com/webchat/bots/00000000-1111-2222-3333-444455556666″ frameborder=”0″ style=”width: 100%; height: 100%;”></iframe>

Save the changes to your Power Apps Portal page, and navigate to the page to see how it looks. You should now be able to see the bot on your page in Power Apps Portal.

You should be able to create a bot and embed it on your web page in just a few minutes. For developing more comprehensive bots, visit the Microsoft Power Virtual Agents documentation site by following the link below:

https://docs.microsoft.com/en-us/power-virtual-agents/

The post Embed a simple Power Virtual Agent in Power Apps Portal appeared first on Aric Levin's Digital Transformation Blog.

A total of 74 new features will be released across the different Microsoft Dynamics 365 applications and the Power Platform. You can check out the full list of features by viewing the Microsoft Dynamics 2019 Release Wave 2 Documentation.

Amongst the newly released features are enhancements to the Timeline control, Softphone dialer, Business card scanner, customization of the Opportunity Close dialog box. In addition to that, the Power Platform is getting quite a few additions including the addition of AI Builder, PowerApps Portals,  UI improvements to Unified Interface, Reusable Canvas components and more.

To view the full release plan for Dynamics 365 and the Power Platform, click on the links below:

Dynamics 365 2019 Release Wave 2

Power Platform 2019 Release Wave 2

The post Microsoft Dynamics 365 and Power Platform 2019 Release Wave 2 appeared first on Aric Levin's Digital Transformation Blog.

WIth the announcement of the October 2018 release of Microsoft Dynamics 365 (version number yet to be determined), which includes a mass number of features, one of the features that was included was management of SharePoint documents inside Dynamics portals.

This feature extends the document management capabilities of Dynamics 365 to portals, providing a consistent experience and allowing users to leverage their investment in SharePoint with Dynamics 365 for document management. Documents that are associated with entity records can be managed by portal users and stored in the SharePoint document library, providing seamless collaboration capabilities offered natively by SharePoint. SharePoint document libraries configured with entities in Dynamics 365 can be surfaced via the portal entity and web forms.

The additional of SharePoint documents for portals provides the following features:

• Adding documents to a SharePoint Library via Portals
• Viewing and downloading documents in a SharePoint Library via Portals
• Creating folders in a SharePoint Library via Portals
• Deleting documents in a SharePoint Library via Portals

The screenshot below shows adding a new file to the document library, a much cleaner interface than the existing Azure blob (notes) option.

Enjoy reading the new features that are available in the October 2018 release of Dynamics 365 available here. You can also download the 236 page pdf which contains the contents of the link and the features in this release.

The post SharePoint Documents are back in Dynamics Portals October 2018 Release appeared first on Aric Levin's Digital Transformation Blog.

The Options tab on the Entity List form contains a custom JavaScript section, which we can control what happens when the document is loaded or when the grid refreshes/loads. We can use the $(“.entitylist.entity-grid”).on(“loaded”, function () { }) to process anytime the grid is reloaded, sorted or paged through. The image and code snippet below provide us with an example on how this can be accomplished.

When the grid is loaded, we retrieve the existing query string and place it into a variable. We then loop through all the results of the table (entity list), by using the jquery each function. We get the current url that is in the anchor attribute, and append the existing query string to it. We finally write back to the anchor attribute the new url. The code below shows everything withing the document ready function.

$(document).ready(function () {
  $(".entitylist.entity-grid").on("loaded", function () { 
    var url = window.location.href;
    var queryStrings = url.substring(url.indexOf("?") +1);
    $("[href^='/business-info']").each(function(){
        var currentUrl = ($(this).attr('href'));
        var targetUrl = currentUrl + "&" + queryStrings;
        $(this).attr("href", targetUrl);
    });  
  });  
});  

If your page was start-business?id=999, when you click on the link the page you will be redirected to would be business-info?slid=12345678-1234-1234-1234-1234567890AB&id=999. The querystring from the previous page is now appended to the new page.

The post Changing the details page link url for Entity Lists appeared first on Aric Levin's Digital Transformation Blog.

Microsoft Dynamics Portals does not provide a way to implement this out of the box, but the path to implement this is simple and straight forward. The first thing that we need to do in order to get this working is get a jQuery mask plugin. The most common plugin that I have seen is the jQuery Mask Plugin created by Igor Escobar. It is available for download from github in the following link:

http://igorescobar.github.io/jQuery-Mask-Plugin/

Next we need to add that plugin to our Dynamics Portals application. In order to do this, I would refer you to a previously published article that I wrote called JavaScript Web Files in CRM Portals. You can read it on the Dynamics Community or my business web site using one of the links below:

https://community.dynamics.com/crm/b/briteglobalsolutions/archive/2018/05/02/javascript-web-files-in-crm-portals or https://www.briteglobal.com/blogs/community/portals-web-files/

Add the script file to the Tracking Code Content Snippet and upload it as a Web file so that it can be accessed across the application. At this point, the hard part is done. In the sample below, on the On my Entity Form Custom JavaScript, I will add the following code to mask my Tax Id and Social Security Numbers.

jQuery(function($){   
   $("#new_ein").mask("99-9999999");      
   $("#new_ssn").mask("999-99-9999"); 
});

The github site above contains plenty of examples for masking. The above was just a simple example. Finally, in the form that I would like to open, what I will see when I click on the control is the masking of the Tax Id number.

Next as I fill it out, it will only allow me to fill the numbers that I have specified in my jQuery function.

The post Adding masking to form controls in Dynamics Portals appeared first on Aric Levin's Digital Transformation Blog.

Using JQuery we are able to easily add this functionality by using the attr function. The code sample below add placeholders for the Tax Id and Social Security Number fields. This code can be placed on either the Entity Form JavaScript section or on the Web Page JavaScript section.

$(document).ready(function () {
 // Add Placeholders for Tax Information
 $("#new_ein").attr("placeholder", "Enter your Tax Id Number" );
 $("#new_ssn").attr("placeholder", "Enter your Social Security Number" );
});

The screenshot below shows the result of displaying the placeholder on the Portal Form.

The post Using Placeholders in Portal Entity Form Text Controls appeared first on Aric Levin's Digital Transformation Blog.

The first thing that we wanted to do was customize the label above the lookup control, so that it looked like a hyperlink, so we set a couple of styles on the label and modified the text.

$(“#accountid_label”).css(“color”, “#0039e6”);

$(“#accountid_label”).css(“cursor”, “pointer”);

$(“#accountid_label”).text(“Lookup Company”);

We then wanted to hide the actual lookup control

$(“#accountid_name”).parent().hide();

Then we added an onclick attribute to the label of the lookup control

  $(“#accountid_label”).attr(‘onclick’, ‘showLocationLookup()’);

The onclick attribute that we added called a function that would perform the click event of the lookup control to display the dialog.

function showLocationLookup()

{

$(“#sbs_site_locationid_name”).parent().find(‘.input-group-btn’).children().first().next().click();

}

Finally we added an onChange event to the lookup control so that we can retrieve the values from it, and display the control if we wanted to.

$(“#accountid”).change(function(){

    var accountId = $(“#accountid”).val();

    var accountName = $(“#accountid_name”).val();

  $(“#accountid_name”).parent().show();

    $(“#accountid_name”).parent().find(‘.input-group-btn’).children().first().next().hide();

});  

The image below shows the end result. Notice the Lookup Company label at the bottom of the page…

The post Changing Portal Lookup Control to Hyperlink Style Control appeared first on Aric Levin's Digital Transformation Blog.