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

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.

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.