This blog is to help fellow consultants to start their journey on PowerApps. We all know how easy it is to put together a screen on Canvas Apps but as and when we need a specific action on it or from it; we fall short of formulas/functions. That’s because we never required these formulas in Model Driven Apps.
But as Business/Functional Consultant, you want to deliver value to your client, make their life easier, Don’t you?
I am sure you do, so here I am providing you with 20 essential functions you must know as a functional consultant. This can be a starting point for you; well, Microsoft is trying hard for Business Users and Functional Consultants to get in the rink of Power Platform. Their learning path is specially designed for Business Users and Functional Consultants, check it out here Learn PowerApps.
Today while exploring the CRM, I found “status reason transitions” option of status reason field. This option is introduced many years back but I haven’t noticed. Status reason transitions are an optional additional level of filtering to define what the status reason value can be changed to for each status reason. That means it will restrict the users to select the status reason which is not valid based on current status reason. Follow the below steps to configure this in your environment.
Open the Default solution.
Navigate to the entity (Case for example).
Go to Fields and open “statuscode” field.
Click on the “Edit status reason transition” button on the top.
A window will open to configure the status reason transition . The Current Status Reasons are available on the left and for each of the Current Status Reason you can specify the available New Status Reasons.
Select “Enable Status Reason Transitions” check box and add the new status reasons based on your business need.
Save and publish the changes.
In the above example, one of the business scenario is, I will not allow the users to select “Problem Solved” status reason from “On Hold”. User has to change it to “In Progress” in order to move to any other status reason.
Like this you can configure all your scenarios based on your business needs. This can be configured on both System and Custom entities.
In one of my previous post, I explained about the navigation property naming issue when working with Lookup fields using the WebAPI endpoint in “CDS/CRM Connection Manager”. Recently, I got a mail from Kingsway Soft support team with a Hotfix to resolve this issue. I installed this Hotfix in my machine and ran a simple package successfully to update custom lookup (account) on Contact entity.
This Hotfix is part of the most recent official release (18.104.22.1684). You can download this from the below link.
Today while updating one of my plugin assembly in plugin registration tool, I got the below error.
Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=22.214.171.124, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: PluginType not found in PluginAssembly which has a total of  plugin/workflow activity types.
Detail: <OrganizationServiceFault xmlns="http://schemas.microsoft.com/xrm/2011/Contracts" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<a:value i:type="b:string" xmlns:b="http://www.w3.org/2001/XMLSchema">Plugin/Microsoft.Crm.ObjectModel.PluginAssemblyService</a:value>
<a:value i:type="b:string" xmlns:b="http://www.w3.org/2001/XMLSchema">Microsoft.Crm.CrmException: PluginType not found in PluginAssembly which has a total of  plugin/workflow activity types. ---> Microsoft.Crm.CrmException: PluginType not found in PluginAssembly which has a total of  plugin/workflow activity types.
After a bit of research, I found that I forgot to change the “Copy Local” property to false of “Microsoft.Xrm.Sdk” and “Microsoft.Crm.Sdk.Proxy” dlls. In our case, we are using ILMerge to merge different dlls but these Microsoft dlls should not be part of the Merged dll. After setting the “Copy Local” property to “false”, Plugin assembly updated sucessfully.
Recently Microsoft have released quite a few updates to it’s client API and one such is the update to API for getting the currency name of the logged in user.
All this time, Microsoft had an API to get the transaction currency id of the logged in user using the API – . You needed to run a separate query to fetch the currency name based on currency id. However it is being deprecated now and now the replacement API is
This wonderful api returns the name of the currency as well as the id and entityType.
Nested Grids – as the name suggests is a grid-within-a-grid (or rather, Grid-ception!). Nested Grids will let you expand a sub-grid entry to look at another grid of the expanded record. This depends on how you configure it.
Be aware, Nested Grids work with Editable Grids and only for Tablet, Phones and Unified Interface. This is not available for the classic Web UI.
Configuring Nested Editable Grid
Here’s my entity structure – I have Account, having multiple Contacts and each Contact, having Opportunities under them. Like in the below diagram –
Now, I have a Contact grid on my Account form (just like we usually do).
I now will have to choose the grid to be a Editable Grid Control as follows. Also, click on the Nested grid view control as pointed
On clicking the Nested grid view pencil, the next dialog box will let you select what entity…