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 (126.96.36.1994). 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=188.8.131.52, 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.