Wednesday, 16 September 2020

Power Automate - Get Common Data Service (CDS) Record Count


Hi Everyone,

Welcome to the Power Guide Mentorship Program. Today I am going to share PowerGuideTip19, where I will teach you, how can you calculate the count of CDS records.

There are many business requirements, where you have to perform the logic based on CDS/Dynamics 365 record count.

For Example- Retrieve Contact where the email address is arpit@dynamics.community. If count is 0, return no contact found, if the count is 1, return contact exists, if the count is greater than 1 then return duplicate email found. Now, based on the return value you may have to perform various logic in PowerApps, Portals, SharePoint, etc

Let's see how this can be achieved.


Step 1- Initialize a variable to store Contact Record Count

Step 2- Retrieve Contact from CDS where email equal to 'arpit@dynamics.community'.

I have hardcoded the email address in the fetch XML itself, however, you can pass it's value dynamically based on your business need.

Step 3- Calculate the Count/Length of all retrieved contact records.

Use the following expression to count the length of all retrieved contact records

length(body('Get_Contact')?['value'])

Here 'Get_Contact' is the name of the previous step. If your previous step name is Get Account Records then you have to change this value to 'Get_Account_Records'. 

Note: Space must be replaced with an underscore

Step 4- Use Count in Condition and Perform your logic accordingly

Step 5 - Test the Flow

Sunday, 13 September 2020

Power Automate Issue - Resource not found for the segment 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'.

Introduction

Hi Everyone,

Welcome to the Power Guide Mentorship Program. Today I am going to share a very important PowerGuideTip18 to all the developers related to the Power Automate and CDS.

I have seen many folks have posted an issue on the community regarding the Power Automate issue while creating/updating records in CDS (Common Data Service).

Issue: 

Resource not found for the segment 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'.

Issue Description: 

As per the error description, the resource (which means the record with GUID is - 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx') could not be found in CDS.




Root Cause: 

The issue is due to the lookup field, whose value has not been set correctly.

Solution:

When you use the Common Data Service (current environment) connector in order to create/update records in Dynamics 365/CDS.

To populate a look up field, we need to specify the plural name of the entity and then the record GUID.

For Example - You are creating a Contact record in Dynamics 365 using Common Data Service (current environment) connector. For that, if you want to set the value in the Account Lookup field then your syntax must be as follow:

account/<account guid>

For Example - account/67234568-6543-7867-9878-345647898456

Now, this account GUID can be set dynamically as below:


You can get the Plural Name of any entity as follows:



Hope it helps.

Tuesday, 8 September 2020

PowerApps Portals - Best Practices


Hello Everyone,

First of all, I would like to thank each and every one of you for being with us in the PowerApps Portal Saturday Event organized on 05-Sept-2020.  As per my memory, I never seen such a whole day event dedicated to Portals. I was very pleased to be able to welcome those of you that have been with us for a long time now as well as those who were new to the 365 Saturday (Power Community).

I would also like to express my sincere appreciation to all the Speakers/MVPs as well, who generously helped us make this event come together to become a success.

I hope you all had great learning throughout the day and this knowledge and experience will help you to achieve success in your real-time implementation as well.

In this event, I had also presented a session on PowerApps Portals - Best Practices. And as promised in the event, I am sharing all those stuff with you through my blog as well. This will surely gonna help you to design and deliver an effective, optimize and scalable portal solution.

You can watch my Session Recording on - PowerApps Portals Best Practices along with my response of various queries posted by Community Folks here 👇



So here I am writting all the Best Practices for you, that I have presented in the event. 


General Best Practices
  • Choose the correct Portal type (custom/partner/community etc) as per your business requirement.
  • Identify your Portal users effectively and based on that Plan your portal pricing & licensing correctly to avoid paying extra.
  • Please avoid using multiple portals in the same environment to reduce the portal & deployment complexity. Hence, plan a portal that can fit all your business needs.
  • Make sure you have proper rights before provisioning the portal.
  • All portal components must be in Draft mode unless it is ready to deploy.
  • Don’t use Portal Local Authentication as your default Portal authentication as it has been deprecated.
  • Avoid saving documents/attachments in CRM. Use Azure Blob Storage and SharePoint instead for better performance
  • Always use GDPR Consent settings on Portal.
  • You should opt for early updates in development or testing portals only, which will ensure that your production portal remains operational in the unlikely event that an early update might cause issues with your portal application. However, several Power Apps portals components, such as the Azure web application and the various tools, are updated automatically.

Webpage Best Practices
  • Naming Conventions must be meaningful
  • Manage localized content effectively. Make sure your JavaScript and Form/List associated with the webpage available on all localized content as well.
  • Don’t use white spaces in partial URL.
  • Partial URL of the webpage must be meaningful for example create-case, submit-inquiry etc
  • Always use Webpage Access Control rules to manage your webpage access security or to avoid exposing it to Anonymous users.
  • Don’t use the Change Enable Tracking option on the webpage as it has been deprecated and creates performance issues.
  • Always use very light images (png or SVG) on the Portal to avoid any performance issues.

Entity Form Best Practices
  • An Entity Form must be associated with a webpage for a given website for the form to be viewable within the site.
  • The Connection entity subgrids aren't supported in entity forms. If you add a Connection entity subgrid to the form using Form designer, error messages are displayed when you render the form on the portal and use the Connection entity.
  • Duplicate fields, multi-select option set, custom controls, Party List fields, and business rules aren't supported in entity forms.
  • Image attributes, file attributes, and entity images aren't supported in entity forms, web forms, or when using liquid template tags, such as fetchxml.
  • Business rules and client API can enable locked fields on a read-only form.
  • Always create a new Form for Portal Entity Form. Don’t use existing CRM forms.
  • If you create an entity form in the Insert mode, you can't change a button's alignment or place an action button above the entity form.
  • If you render a lookup control as a dropdown list on the form, the related records filter does not work.
  • It is recommended to create a workflow instead of adding an Activate or a Deactivate button for out of the box entities having defined specific state and status-code values that they require for their business processes. For example, Incident (status options), Opportunity(status options), Entitlements (status options).
  • Request validation, a feature of ASP.NET since version 1.1, prevents the server from accepting content containing un-encoded HTML. This feature is designed to help prevent some script-injection attacks whereby client script code or HTML can be unknowingly submitted to a server, stored, and then presented to other users. We still strongly recommend that you validate all input data and HTML encode it when appropriate. Use Site Setting DisableValidationWebTemplate to disable it.
  • Use Captcha on the Entity Form when it is being exposed to the Anonymous Users

Entity List Best Practices
  • An entity list must be associated with all the localized contents associated with the webpage.
  • Avoid using CRM's existing views to create the Entity List. Always create a new View for Portal.
  • The multi-select option set is not supported in entity lists.
  • If you are filtering by current portal user's contact or parent account then it is recommended that you associate a Web Page Access Control Rule to the Web Page to force the user to sign in. You would create a Web Role with "Authenticated Users Role" checked. Create a Web Page Access Control Rule with "Restrict Read" right and associate the Web Role. This will force users to be signed in to view the page and therefore allow the data to be filled accordingly.
  • Enable Entity Permission, if you’re using Entity List for OData Feeds
  • If you have secured an entity list by selecting Enable Entity Permissions, and want to display the records level actions that are applicable to the signed-in user, you must set the value of EntityList/ShowRecordLevelActions site set to true. 
  • Write the only JavaScript related to Entity List that must be written on Entity List Custom JavaScript. For Example- Perform an action when the entity list finishes loading.
  • Entity List Page Size must be set to less (for example-10) to avoid Entity List Loading and Searching Issues.

Content Snippet Best Practices
  • To display dynamics information or content on the portal.
  • To display text/string message on the portal.
  • In order to edit snippets on the front-side, users must be associated with a Web Role that is associated with a Website Access Permission record with the Manage Content Snippets permission set to true.

Web Templates Best Practices
  • Do not change the OOB Web Template for future reference. For Example, If you want to change the OOB Header and Footer Web Template in order to change the Header & Footer layout/design as per the client needs, then create a new web template for Header & Footer both and associate them with the Website record instead of updating the OOB templates
  • Use Web Template to avoid writing the same code multiple times on different webpages
  • Apply proper Entity Permissions if you are using Fetch XML in your Web Templates
  • Use Web Templates to trigger your Fetch XML on demand. For Example onbutton click
  • Do not hard code text message in your Liquid Code. Always use Content Snippet for that.
  • Do not hard code URL in the Liquid Template Code. Always use Site Marker for that.
  • Always store configuration values in Site Settings For Example Web API URL, Client Id, secret key, etc
  • Don’t’ write your whole code in one web template. Split it into multiple templates and pass the data between them. For Example, One Web Template use to fetch the data from CRM, and One will be used to call the external service and bind the data in HTML Table.
  • Use only required attributes In Fetch XML to avoid performance issues while retrieval.
  • Try to avoid inline CSS in the web template code.

Site Markers Best Practices
  • Never ever hard code the Webpage URL and Partial URL of the webpage in your Liquid/JavaScript code. Use Site Markers instead.
  • The Page that the site marker points to must belong to the same Website as the Site Marker.
  • Do not modify the OOB Site Markers (if possible). Create your custom one instead.
  • Changing the name of the Site Marker is strictly prohibited.

Site Settings Best Practices
  • Do not change the value of OOB Site Settings
  • Sometimes, changes made in Site Setting takes time. Hence, you may be required to Refresh the Portal Cache. If still, it doesn’t reflect then you may need to Restart the Portal as well. Depends on the instance to instance.
  • Use Site Settings to store your CRM and Portal Configuration, instead of creating a custom entity in CRM.
  • Make sure there is no white space in the Site Setting value.
  • Some Site Settings values are instance-specific for example – Azure AD B2C related Site Settings. Hence, don’t include Site Setting in each Portal Deployment.

Web Files Best Practices
  • Do not change the OOB Portal Bootstrap CSS File. Create your own custom CSS file and upload it on top of OOB CSS.
  • Do not attach large files as a Note Attachment in Web File.
  • Don’t use Home Page as a parent page for all the Web Files. Use the specific page name on which the web file is going to use.
  • Don’t use a special character in Web File partial URL name.
  • Always use the Annotation entity in your Portal Deployment to deploy your portal images/CSS/js files.
  • Allow JS file type extension from Dynamics 365 Settings to avoid getting error of Invalid File Type Extension issue while attaching the JS file to Note entity.
  • Don’t enable tracking in web file, because it has been deprecated.

Security Best Practices
  • Ensure that your web role has this entity permission added. If your user is already an Administrator, then the above entity permission need not be explicitly assigned.
  • Don’t give Website Access Permissions to everyone in order the manage the content, site markers, and website links directly from the portal.
  • Make sure the Authenticated User Role checkbox is unchecked while creating a custom web role in the portal. Otherwise, the user gets the authenticated web roles as well along with your custom web role.
  • Portal users must have a unique email address. If two or more contact records (including deactivated contact records) have the same email address, the contacts will not be able to authenticate on the portal.
  • Always use the Webpage Access Control Rule to secure your webpage and the content which is been displayed on the portal. You can still show the web link to a protected page by selecting “Disable Page Validation” in the web link record’s Link Options section. The portal user will still need to login to access the page.

Portal Cache Best Practices
  • Make sure that the change tracking feature is enabled for that entity to avoid cache issues on the portal. 
  • Clearing the portal server-side cache or the configuration entities cache causes temporary performance degradation of the portal while data gets reloaded from Common Data Service.
  • Changes to the configuration entities, or publish changes actions should be performed during non-peak hours. Frequent or too many entity changes may adversely affect portal performance.
  • It is not recommended to use Plugins or workflows to update data in other entities and need these data changes to reflect immediately on my portal. Except for the primary record where the create or update action is triggered, data reflection from Common data Service to portals is never guaranteed to be immediate.
  • The SLA for cache refresh (data transfer between Common Data Service and portal) is 15 minutes. However, transaction performed from portal to CDS gets reflected to the portal immediately.
  • Changes made directly from the Portal Editor doesn’t require cache refresh.
  • Power Apps portals with version 9.2.6.x or later benefit from improved caching functionality to increase consistency and reliability as follows.
  • Capacity-based portals and add-on portals will use the same caching functionality.
  • Capacity-based portals don't have to manually clear the configuration entity cache.
  • Add-on portals with the high load will have improved performance and a reliable data cache refresh.
  • To clear the cache through code you can have a look this article - https://colinvermander.com/2019/08/06/powerapps-portals-api-clear-cache/

Performance Best Practices

  • Disable Webpage Tracking - Enabling a portal web page for page tracking can lead to performance issues in your portal. This functionality is deprecated since the January 2018 release of Dynamics 365 Portals. 
Note: It's important to understand that if you're on Dynamics 365 Portals solution version 9.x, this field won't be displayed on the form and you might need to add it to the form first.
  • Disable Webfile Tracking - Enabling a portal web file for page tracking can lead to performance issues in your portal. This functionality is deprecated since the January 2018 release of Dynamics 365 Portals.
Note: It's important to understand that if you're on Portal solution version 9.x, this field won't be displayed on the form and you might need to add it to the form first.
  • Disable Login Tracking - Enabling a portal login tracking can lead to performance issues in your portal. This functionality is deprecated since the January 2018 release of Dynamics 365 Portals. The portal checker tool will check if login tracking is enabled for your portal and will show a failed check if it's enabled. Login tracking should be disabled by following these steps:
    1. Open the Portal Management app.
    2. Go to Portals > Site Settings.
    3. Search for site setting named Authentication/LoginTrackingEnabled.
    4. Change the value of this site setting to False or delete the site setting.
    5. Restart the portal.
  • Disable Header Cache - Disabling header output cache on your portal can lead to performance issues in your portal during high load. The portal checker tool will check if the header output cache is disabled on your portal and will show a failed check if it's disabled. To enable it:
    1. Open the Portal Management app.
    2. Go to Portals > Site Settings.
    3. Search for site setting named Header/OutputCache/Enabled.
    4. If the site setting is available, change the value of Site setting to True. If the site setting isn't available, create a new site setting with this name and set its value to True.
    5. Restart the portal.
  • Disable Footer Cache - Disabling footer output cache on your portal can lead to performance issues in your portal during high load. The portal checker tool will check if the footer output cache is disabled on your portal and will show a failed check if it's disabled. To enable it:
    1. Open the Portal Management app.
    2. Go to Portals > Site Settings.
    3. Search for site setting named Footer/OutputCache/Enabled.
    4. If the site setting is available, change the value of Site setting to True. If the site setting isn't available, create a new site setting with this name and set its value to True.
    5. Restart the portal.
  • Reduce Number of Web Files - The web file entity is used by a portal to store any static files you want to use on your portal. The main use case of this entity is to store static content of your website like CSS, JavaScript, image files, and so on. However, having many such files can cause slowness during the startup of your portal.
  • The portal checker tool will check for this scenario and will provide you an indication if you've more than 500 active web files in your portal. If all of these files represent static content like CSS, JavaScript, image files, and so on, you can take the following actions to mitigate this issue.
    • Use an external file server like Azure blob storage or CDN to store these files and then reference these files on the appropriate pages either within the page or in the underlying template.
    • If you can't move files outside, ensure that all the files aren't loaded along with the home page. A web file is loaded along with the home page if the parent page of that file is set to home. To avoid this scenario, you can do the following steps:
      1. Create a dummy web page with no content and a blank template. This page would be used to create a direct path to your web files.
      2. For all the web files that aren't needed on the home page, change the parent page to this dummy webpage. Once done, the full path to your web file would be Portal URL/{dummy_webpage}/{web file}
      3. Reference your web file directly in the HTML of the page template or web template of the page where you want to use it. This will load your file on-demand on that page.
  • Loading static resources (css/js) asynchronously - When working on portal implementation, it's important to understand that you completely manage the HTML of the page. That means the standard web development practices should be followed to ensure that your webpage's client-side performance isn't affected.
    • One of the most common causes of performance issues on webpages is loading a lot of static resources (css/js) synchronously on the load of the page. Synchronous loading of a large no of css/js files can lead to the long client-side processing time for your webpages.
    • In portals, whenever you're associating a web file directly to the home page, it creates a dependency in the generated HTML. This means that web file always loaded along with the home page. If this web file is a css/js file, this would be loaded synchronously and can slow down your client-side processing time.
    • To avoid this, you can do the following steps:
      1. If a web file isn't needed on the home page, make sure its parent page isn't set as home page and reuse the mechanism described above to load it on demand.
      2. While loading a JavaScript file on demand on any page, use <async> or <defer> HTML attribute to load the file asynchronously.
      3. While loading a CSS file on demand, you can use <preload> HTML attribute (https://www.w3.org/TR/preload/) or JavaScript-based approach since preload isn't supported on all the browsers yet.
  • Convert Lookup to Dropdown only for static content - Enabling a lookup to render as a drop-down mode in entity forms or web forms can be performance-intensive if the number of records shown in the drop-down exceeds 200 and are changed frequently. Use this option for only static lookups, such as country list and state list, having a limited number of records.If this option is enabled for lookups that can have a large number of records, it will slow down the load time of the webpage on which entity form is available. If this page is used by a lot of users and is loaded a lot of times, it can slow down the whole website and the website resources would be used to render this page. For these situations, full lookup experience should be used or a custom HTML control that calls an AJAX endpoint (created using web templates) should be built for the wanted look and feel.
  • Limit the Number of Web Roles - Web roles are used in portals to enable role-based access control. Typically, the number of web roles in a portal is limited as the number of different combinations of permissions would be limited as well. If the number of web roles exceeds 100 in your portal, it can cause performance issues that can affect all pages of your portal.

Portal Deployment Best Practices
  • Check Portal Availability in your Target Dynamics 365 Instance before planning for deployment
  • Plan for Multilingual Portal – Configure languages in your Target instance before planning for deployment
  • SharePoint Integration – Document Management is configured on Target Instance before planning for deployment
  • CRM Solution Strategy – Always use different solutions to hold all portal related solution components like forms, views, fields, etc.
  • Don’t include Site Settings in your every portal deployment.
  • Include Notes (Annotation Entity) for Web Files Deployment
  • Deployment Order – Always deploy the CRM solution first, then deploy the portal solution to avoid mapping issues.
  • Include Views to avoid OData Query Issues.
  • Use the Configuration Migration Tool for Portal Deployment.
  • Always use Schema File for each Portal Type deployment from here.
  • Don't include user/teams/instance-specific records. (Created By, Owner, etc).
  • Use Fetch XML for selective components deployment.
  • Disable all Portal OOB Plugins.
  • Deploy only Published Components.
  • There must be a proper Collaboration and Communication between all your team members before planning your portal development to avoid any discrepancies.
  • Keep your Portal CI/CD Pipeline separate from D365 Pipelines.
  • Avoid deploying whole Portal Configuration every time. (use Fetch XML for selective components instead).
  • Avoid deploying or publishing changes without the knowledge of other developers.
  • Communicate with Product Owner/Project Manager/IT Manager to find out people who will be involved in the deployment process.
  • Always take a backup before starting your portal deployment.
  • Plan the Rollback process in case of any unforeseen issues occurs.
  • Pause your development activities at least half an hour before your deployment starts.
  • Perform Sanity after each deployment.
  • During the deployment, send an email to everyone actively involved in the process.
  • Disable all AdxStudio/PowerApps Portals OOB Plugins before starting the deployment.
  • Keep your Connection String, Username, and Password in encrypted format in CI/CD Pipeline.

Note: Above all the best practices are my personal opinion and collected based on my Personal Experience while working on the Portal.

Thursday, 23 July 2020

PowerApps Portals - Change Default Landing Page For Portal Users




Hi All,

Welcome to my Power Guide Mentorship Program.

Today, I am going to share a #PowerGuideTip16 for PowerApps Portal Developers, who want to manage the redirection of the Portal default landing page.

Requirement:

Redirect Anonymous Portal User to Login Page and Authenticated Portal Users to Home Page,

Solution:

Option 1 - 
Anonymous User Default Landing Page - Login Page
Authenticated User Default Landing Page - OOB Home Page

Go to Portals > Web Template > Home

Update the code as per the following:

{% if user %}
//if a user is logged in then
// Paste OOB Home web template Liquid Code inside this block
{% else %}

<script>
//if user is not loggedin, redirect user to Login page
window.location.href='~/SignIn';
</script>

{% endif %}





Option 2 - 
Anonymous User Default Landing Page - Login Page
Authenticated User Default Landing Page - Custom Page or other than OOB Home Page

{% if user %}
//if a user is logged
<script>
window.location.href='~/<WebpagePartialURL>';
</script>
{% else %}

<script>
//if user is not loggedin, redirect user to Login page
window.location.href='~/SignIn';
</script>

{% endif %}


Option 3 - 
Sometimes, you might have the requirement to redirect portal users to the same page after login, where he/she left off, even after closing the browser.

To implement this requirement, you need to use the HTML Local Storage feature.

Set Local Storage -

You need to save the webpage name in Local Storage (browser cache) on each webpage load.

For Example - Let say I have a webpage called submit-request (partial url of webpage), which is associated with case entity form. In order to save the webpage name in local storage. I would use following syntax under Custom JavaScript section:

// Store
var getWebpagePartialURL = location.pathname;
localStorage.setItem("webpagename"getWebpagePartialURL); 


Get Local Storage - 

Now, Go to Home Web Template. You need to write the code to get the local storage value in order to know the webpage name that user had accessed last before closing the browser. And redirect the user accordingly.

{% if user %}
//if a user is logged
<script>
// Retrieve local storage value
var lastAccessedPage = localStorage.getItem("webpagename");
if (lastAccessedPage != null && lastAccessedPage != '')
{
window.location.href = '~/'lastAccessedPage ;
}
</script>
{% else %}

<script>
//if user is not loggedin, redirect user to Login page
window.location.href='~/SignIn';
</script>

{% endif %}

Tuesday, 21 July 2020

PowerApps Portals - Lookup Editor Control

Introduction

Hi Folks,

Welcome to my Power Guide Mentorship Program. Hope you all are doing great and staying safe.

Today, I am going to share #PowerGuideTip15, where I'll show you how you can directly update the lookup record on the portal, without navigating away from the Portal page.

There are many business requirements, where a portal user wants to view/update the lookup record.

Though I have already written an article on the same, however in that approach, I am giving a solution to open the portal lookup record in the new tab, where you can edit/update the lookup value.

Can check here.

The drawback of that approach was the user had to navigate away from the main portal page in order to update the lookup record. And it becomes more complex when a user has to update multiple lookup values.
.
To overcome these issues, Today, I am going to share an advanced approach using that, portal users can View/Update the lookup records without navigating away from the main page.

Let's get started...

Requirement

View and Update Lookup record on Portal Entity Forms

Implementation

Step 1 - Download the web template code from my Git Hub Repository



Step 2 - Create Web Templates



1. Portal Lookup Editor - Purpose of this web template is to convert the normal lookup available on the Portal Entity Form into an editable lookup



2. Portal Lookup Template - The purpose of this web template is to open the lookup record in the webpage associated with an entity form (Edit Mode).



Since this web template has to be used on all the webpages (Step 4) that are required to View/Edit the lookup record information. Therefore, we need to create a Page Template as well



Step 3 - Create Site Settings



1. Lookup Editor - Name - The purpose of the site setting is to provide the lookup attributes schema names (in comma separated format) that you want to show in an editable format.

For Example - Let say, I have three lookups: Customer (customerid), Contact (primarycontactid), and Partners(new_customer) on my Case Entity Form. I want to convert these lookups into an editable lookups. Hence, my site setting value would be like:

customerid,primarycontactid,new_customer



2. Lookup Editor - Page - The purpose of the site setting is to provide the webpage partial URL names (in comma separated format) where you want to display/edit the lookup record information.

For Example - Let say, I have three lookups: Customer (customerid), Contact (primarycontactid), and Partners(new_customer) on my Case Entity Form. I want to convert these lookups into an editable lookup. In order to view/edit the lookup records, I have created two webpages and associated them with an entity forms of the respective lookup entities.
  • Webpage - Edit Account (Partial URL - 'edit-account') associated with Account Entity Form, will be used to View/Edit the Customer and Partner Lookup record and
  • Webpage - Edit Contact (Partial URL - 'edit-contact') associated with Contact Entity Form will be used to View/Edit the Contact Lookup record.
Hence, my site setting value would be like:

edit-account,edit-contact,edit-account


3. Lookup Editor - Role - The purpose of the site setting is to provide the web role names (in comma separated format) to whom you want to enable/disable the lookup editable control feature.

I want, that anyone who is authenticated on the portal or either having Team Lead or Team Manager web role could see the lookup editor control. Hence, my site setting value would be like:

Authenticated,Team Manager,Team Lead




4. Lookup Editor - Icon - The purpose of this site setting is to configure the Lookup Editor Icon based on your business need. By default, this site setting value is 'glyphicon glyphicon-pencil', which displays the 'pencil' icon on the portal lookup fields and indicate that lookup record can be Viewed and Edit both.
However, if you have a requirement to allow portal users only to View the lookup record, then you can change the site setting value to 'glyphicon glyphicon-eye-open

To View/Edit Lookup Record - glyphicon glyphicon-pencil

To View Lookup Record - glyphicon glyphicon-eye-open

Default Value - glyphicon glyphicon-pencil





Important Note-  Make sure, there is no white space in all the Site Setting values.


Step 4 - Create Web Pages and Entity Forms

Webpages and Entity Forms need to be created based on your business requirement.

  • One webpage would be required to show an entity form on the portal, where you want to edit your lookup values. In my demonstration, I have created a webpage and associate it with the Case entity form. And case entity form has 3 lookups - Customer, Contact, and Partner.
  • This webpage must include the Web Template (Portal Lookup Editor) created in Step 1. 




  • Rest other Webpages and Entity forms would need to be created based on the number of editable lookup fields you want to have on the portal. For Example, In my demonstration, I have three lookups. One lookup refers to the Contact entity and rests 2 other lookups refer to the Account entity. Hence, I require 2 more webpages along with 2 entity forms (account and contact).







Step 5 - Demo 





Portal Lookup Editor - Security

1. Portal Lookup Editor Control provides Web Role-based Security. That means you can enable and disable this feature based on the portal web role.

For Example - If you want this control to be enabled only for those portal users who are having Webrole1 or Webrole2, then you can manage it using Lookup Editor - Role Site Setting (mentioned in Step 3). However, if you want to provide a more granular level of security, then configure the Entity Permission and enable the Entity Permission Checkbox on your Entity form. So that unauthorized Portal users would not be able to Edit the Lookup record

2 If you have a requirement to allow portal users only to View the Lookup record, then you need to create your Entity Forms (created in Step 4) in Readonly mode instead of 'Edit mode'. Also, change Lookup Editor - Icon Site Setting value to 'glyphicon glyphicon-eye-open'.


Monday, 13 July 2020

PowerApps Portals - Send Auto Generated Username & Password to Invited Portal Users





Introduction

Hello Everyone,

Hope you all are staying safe and healthy.

Today, I am going to share a very useful #PowerGuideTip14 related to PowerApps Portals Authentication, which will help you to design a process, where you require to automate your PowerApps Portals Authentication.

You might know, Portal Users has following ways to access PowerApps Portals:

Local Authentication: User hits the Portal URL in browser > Register and Can start accessing the Portals through their chosen Username and Password.

External Authentication: User hits the Portal URL in browser > Register through either Social Media Accounts, Azure AD, B2C, B2B account and can start accessing the Portals.

In both the type of authentications, any type of audience is allowed to Register and Start accessing the Portal. However, sometimes you want to restrict your Portal traffic and want to allow accessing the Portal to the Invited users only.

Here comes, the Portal Invitation Process.

Portal Invitation is the process where your organisation decides, who'll access the portal by sending the personal email invitation.

Now, this invitation could be sent to either New Users or your Existing Users (Contacts).

You can have a look at this article to know more about the PowerApps Portal Invitation process.

While sending the Portal Invitation there might be a business need where you might require to send Autogenerated Username and Temporary Password. So today in this article, I am going to share the solution of the same.

Requirement

1. Send Autogenerated Username and Password to the Portals Invited Users.
2. Redirect User to Password Reset Page immediately after the successful login.

Local Authentication

Solution

I have designed a Real-Time Workflow (that you can download from my Git Hub repo) to auto-generate the username and password for the portal users. You can update the workflow steps as per your business need.

Solution Component

Workflow Name: Portals - Auto Generate Username and Password
Trigger Point: On-demand (configure the trigger point as per your business need, like on creating of contact record or you can trigger it on the update of any field also)
Scope: Organisation
Type: Real-Time

This workflow has 4 steps

Step 1- Generate a Unique Temporary Password (OOB Custom Workflow of AdxStudio)
Step 2 - Update Contact record with relevant information, that is required to access the Portals. Like

  • Turn On the Login Enabled and Lockout Enabled Field.
  • Copy email address from the Email (emailaddress1) field to the Username field

Step 3 - Update the uniquely generated password (Step1) in the Contact record in the Hash format. (OOB Custom Workflow of AdxStudio)
Step 4 - Generate a Security Stamp, which is mandatory to be generated for the generated password and portal login (OOB Custom Workflow of AdxStudio)
Step 5 - Send an Email to User with Username and Password

Pre-requisites to use the solution

  1. You need to have PowerApps Portal installed (any portal type) in your Dynamics 365 Instance.
  2. Managed Solution (Download it from my Git Hub Repo).
Usage Steps

Dynamics 365:

  1. Import the Managed Solution downloaded from Git Hub
  2. Open any existing Contact record (must have unique emailaddress)
  3. Go To the Flow from the Ribbon Bar
  4. Choose Portals - Auto Generate Username and Password workflow from the list
  5. Provide the confirmation
  6. Open the Portal Contact form > Go to Web Authentication Tab.
  7. You'll see the portal authentication-related information has got updated on the form.
  8. Check the email or can directly open the email record from Timeline.
  9. You'll see the Username (email address) and a temporary password has got generated.
PowerApps Portal:
  1. Hit the Portal URL in the browser.
  2. Enter the username and password received in the email
  3. Once logged In successfully, you'll be redirected to Password Reset Page, where you can reset the password as per your wish.
Note: In order to redirect the user to the Password Reset page immediately after the login, I have written the following script on the Profile Webpage. However, you need to call this code only the first time after the login, not every time. Otherwise, every time when user tried to open the profile page, it'll take the user to the Password Reset page,

May be to do that, you can create a custom field (two option) on Contact entity and update its values to true, as soon as user resets the password (can update the field in OOB Action called- 'Send Password Reset To Contact') and in your Profile webpage, you can put the condition:

If {{user/ firstlogin != 'true'}}
{
window.location.href='/en-US/Account/Manage/ChangePassword/'
}


Live Demo




External Authentication

For External Authentication, if you are allowing customers to register/login on Portal through their Social Media accounts like Yahoo, Gmail, LinkedIn, Twitter, Facebook, etc. Then there is no need to send the autogenerated username and password. Because they already have their username and password for all their social media account.

However, for Azure AD B2C and Azure AD B2B authentication. You need to create the guest user account in your Azure Active Directory. In the normal process, the User chooses Azure AD B2C as a Login option, Sign Up in Azure AD B2C, and then log in to PowerApps Portal. This created a guest user in your Azure AD tenant.

However, if you don't want to allow external users to register on the portal through Azure AD B2C and only want to allow when you send them the invitation then you might need to generate username and password in Azure AD.

Can check this article for more details about Azure AD B2C setup in PowerApps Portals.

In order to automatically create a user in Azure AD B2C, you have only two options available.
either uses Microsoft Graph API or use the Powershell command. As I am always in favour of Low Cede No Code solution, hence I would recommend going with Microsoft Graph API.

Microsoft Graph API can also be triggered based on your business need either through Power Automate or C# code.


I have provided a Power Automate solution that automatically creates a Guest User (Azure AD B2C) in your Azure AD tenant along with Username and Password and sends them the invitation as well.

Pre-Requisites

In order to use this Power Automate Solution, you need to consider following pre-requisites

  1. Appropriate License to use Power Automate
  2. Download my Power Automate solution from Git Hub Repository.
  3. Azure AD B2C setup in Azure and Portals both. Can check this article for more details.
  4. Trigger Point to trigger the Power Automate solution. I have kept my Power Automate trigger is Manual, however you can trigger it as per your business need)


Usage Steps
  1. Import the Power Automate Solution downloaded from Git Hub
  2. Update the Azure AD configurations like Clientid, Secret Key, Tenant ID etc
  3. Change the Power Automate Trigger as per your business need.
  4. Run the Power Automate
To know everything about Microsoft Graph API, it's setup, and how to call it using Power Automate, Please check my following article and can watch my 365 Saturday session recording as well.



Demo




Git Hub Repository

Local Authentication - Autogenerate Username & Password

https://github.com/arpitdynamics/Dynamics365Code/blob/master/PortalLocalAutogenerateUsernamePassword_1_0_0_0_managed.zip

Azure AD B2C Authentication - Autogenerate Username & Password

https://github.com/arpitdynamics/Dynamics365Code/blob/master/Portals-AzureADB2CAutogenerateUsername%26Password_20200713142409.zip


Important Points


  • This article is just a guidance to autogenerate username & password, I am using contact record Guid for unique temporary password generation> However, if you have a need to generate the temporary password more complex, or in a specific format (including Uppercase/Lowercase/Special Character) or as per your business need. You can use Power Automate as well.
  • I have kept Real-Time Workflow and Power Automate Solution On-Demand. Hence, change the trigger point and run it as per your business need.
  • Once you import the managed solution (downloaded from git hub) in your Dynamics 365 instance. Real-time Workflow may be available in Draft mode. You need to Activate it after making the configuration as per your organization need.



Hope you find this article useful and helpful to solve your business need.

Stay Tuned for my next #PowerGuideTip15

Cheers

Tuesday, 2 June 2020

Plug & Play Portal Solution - Automate Backup of Portal Custom Code








Introduction:

Welcome everyone to the Power Guide Mentorship Program.

Today I am going to share PowerGuideTip#13 that will help developers to take the Backup of Portal Custom Code.

In PowerApps Portals or Dynamics CRM Portal, developers often use the following Components to write the Custom Code:
  • Webpage -   Copy/HTML Code, Custom JavaScript, Custom CSS.
  • Web Template - Liquid Template
  • Entity Form - Custom JavaScript
  • Entity List - Custom JavaScript
  • Web Form Steps - Custom JavaScript
  • Content Snippet - HTML Code

Currently, we have the following challenges with respect to PowerApps Portals Backup:
  • No OOB way to take custom code backup like javascript, HTML, and liquid template.
  • Developers have to take the custom code backup manually.
  • Developers need to put extra effort in order to take backup manually after development work.
  • No OOB way available to schedule the portal code backup.
  • Risk of loosing/accidentally removing or deleting the code.
  • As of now, to take the backup, we can only take the whole portal configuration export using the Configuration Migration Tool. We can also schedule the whole configuration backup also using Azure DevOps You can check my article here.
  • Developers have to manually identify the modified code and take the backup on a daily basis.

To overcome all the above challenges and make the every Portal Developer life easy, I have designed a Low Code No Code Solution using Power Automate. By using that, portal developers can Schedule and Automate the Portal Custom Code backup and store it in SharePoint/Local Machine/DropBox/One Drive/Azure Blob Storage, etc


Solution Architecture:








Pre-requisites:
  • Dynamics 365 Instance/Trial
  • PowerApps Portals Subscription/Trial
  • Power Automate Subscription/Trial
  • SharePoint Subscription/Trial
  • SharePoint Site

Steps to implement the solution

Step 1:  Create Portal Site Settings

Portal Backup Site Setting

Name: Portal Backup

Value: true

This site setting will decide, whether you want to automate the Portal custom code backup or not.

If the Site Setting Value is true - Portal Automate will automatically schedule the Portal Backup. 
If the Site Setting Value is false - Power Automate will not schedule the Portal Backup.




Portal Backup Entities Site Setting

Name: Portal Backup Entities

Value: { "BackupEntities" : [{ "WebPage":"adx_webpage", "WebTemplate":"adx_webtemplate", "EntityForm":"adx_entityform","EntityList":"adx_entitylist","ContentSnippet":"adx_contentsnippet","WebForm":"adx_webform"} ]}

This site setting decides, what all portal entities you want to include in order to take custom code backup. 

If you want to take the back up of a specific entity, then the site setting value should be changed accordingly. For Example Following site setting value will take the backup of web template code only.

{ "BackupEntities" : [{ "WebTemplate":"adx_webtemplate"} ]}

For only WebPage Copy/HTML, Custom JavaScipt and Custom CSS code

{ "BackupEntities" : [{ "WebPage":"adx_webpage"} ]}

For only Entity Form Custom JavaScript Backup:

{ "BackupEntities" : [{ "EntityForm":"adx_entityform"} ]}

For only Entity List Custom JavaScript Backup:

{ "BackupEntities" : [{ "EntityList":"adx_entitylist"} ]}

For only Web Form Steps Custom JavaScript Backup:

{ "BackupEntities" : [{ "WebForm":"adx_webform"} ]}

For only Content Snippet Html Code Backup:

{ "BackupEntities" : [{ "ContentSnippet":"adx_contentsnippet"} ]}

For all the above Entities

{ "BackupEntities" : [{ "WebPage":"adx_webpage", "WebTemplate":"adx_webtemplate", "EntityForm":"adx_entityform","EntityList":"adx_entitylist","ContentSnippet":"adx_contentsnippet","WebForm":"adx_webform"} ]}



Step 2:  Download the Power Automate Solution from GIT HUB

Please find my PortalBackupScheduler_1_0_0_0_managed.zip solution from GIT HUB Repository


Step 3: Import the Solution in your Dynamics 365 Instance

The imported solution has Power Automate, that:
  1. Runs every day at 10:00 PM.
  2. Retrieve all Webpages, Entity Forms, Entity Lists, Web Templates, Web Form Steps, and Content Snippets records, that either has been Created or Modified Today.
  3. Create Portal Backup Folder at given SharePoint Site Address.
  4. Create Today's Date Folder inside Portal Backup Folder.
  5. Create a folder for each entity (specified in Site Setting) like Webpage, Entity Form, etc
  6. Store the Html/JavaScript/CSS/Liquid Template code in specific entity folder.


Step 4: Edit the Power Automate and Update as per your need/requirement/configurations

Open the imported solution (Portal Backup Scheduler) > Select Power Automate (Schedule Portal Backup) > Click Edit from Toolbar

Update Power Automate Schedule Date & Time:

Update the Recurrence Step to schedule the Power Automate as per your need.

For Example - I have scheduled the Power Automate- Every Day at 10:00 PM

Update SharePoint Site and Folder to store the backup files:

Find 'Create SharePoint Folder' and 'Create SharePoint File'  Steps in Power Automate and change the SharePoint Site Address as per your SharePoint site configuration.

Update SharePoint Site Address in Create SharePoint Folder step

Update SharePoint Site Address in Create SharePoint File step


For Example, My SharePoint Site name is Power Guide and Site Address is:

https://365saturdaysdemo.sharepoint.com/sites/PowerGuide



Rest all the configuration in Power Automate will remain the same.


Step 5: Run and Test the Solution

You can manually trigger the Power Automate to test the flow.

Documents > Portal Backup


Documents > Portal Backup > Today's Date Folder

Documents > Portal Backup > Today's Date Folder > Web Pages 




Important Tip:

You can reuse this Power Automate solution to store the backup files in other places as well based upon your requirement/licensing model and configuration. You only need to replace the SharePoint Steps with your Storage Connector.

For Example: Instead of SharePoint, if you want to store the Portal Backup Files somewhere else, then you have the following other options as well:
  • Local Machine
  • Dropbox
  • One Drive
  • Azure Blob Storage
  • ....many more



I hope this article finds you interesting and helpful especially for Portal Developers.

Stay Tuned for more such Interesting Solutions and Tips

Cheers

Blogger Widgets