Bring your code 2 life

In this blog post I will not go into detail in how to install all the pre-requisites that are required to build and run PCF controls. My goal was to build a new PCF control and get into coding of PCF controls as fast as possible. Here are a few links to articles that will help you installing the pre-requisites (Microsoft PowerApps CLI)  https://docs.microsoft.com/en-us/powerapps/developer/component-framework/get-powerapps-cli Other good references to get into this topic: https://toddbaginski.com/blog/how-to-create-a-powerapps-pcf-control/ https://docs.microsoft.com/en-us/powerapps/developer/component-framework/create-custom-controls-using-pcf I looked through the Guido Preite’s https://pcf.gallery/ which will help you find appropriate use cases / examples for your own needs. It did not take very long to find a simple example to start with: Andrew Butenko's https://pcf.gallery/address-autocomplete/ A few moments later I had the idea to create yet another address autocomplete

Today I was testing out the profile cards feature and analysed how Microsoft implemented it as there is only little information to find on docs.microsoft.com, like this article: https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/admin/enable-profile-card While using the profile cards I experienced a behavior that was not really self-explanatory for me and my colleagues. Thanks to Chrome DevTools I was able to have look behind the scences to find more information on how it works. Key findings If you use a contact lookup field on an entity form and... select a contact that has the field "emailaddress1" filled you will get a persona card popup if the contact has "emailaddress1" not filled the persona card popup will not show up For system users there are two fields that are used to show the persona card popup: internalemailaddress azureactivedirectoryobjectid The following snippet helped me identify those fields and depende

When go to https://trials.dynamics.com and create a new trial environment the first step I always do is to go to the Settings => Security => User to promote my user as admin. With the new unified interface you might find out quickly that this approach will not help you in the classic way where you tried to open the Dynamics 365 – custom - App in order to navigate to the Security settings. If you try to do so, you will always end up on the default or Sales app. Checking out the personal settings you will find a new option "Advanced Settings" which will navigate you to the classic Settings page: Voilà, now we got the Settings page back: Now you can select your user and promote him to admin:

As the relatively new multi-optionset field type arrived with v.9 of Dynamics 365 the need to set values via workflow is quite a common requirement. So I searched within the community to find some ideas on how to solve and create such a workflow activity and so I stumbled upon Demian Raschkovan’s Workflow Tools with can be found on his github repository: https://github.com/demianrasko/Dynamics-365-Workflow-Tools/blob/master/msdyncrmWorkflowTools/msdyncrmWorkflowTools/Class/MapMultiSelectOptionSet.cs It gave me some basic ideas to reach my requirements which are: Should be generic for any type of entity Ability to specify the attribute name of the required multi-optionset for that entity Provide a list of multi-optionset values (comma-separated) Keep existing values (True/Yes => add provided values / False/No => replace all values with the provided values Remove specific value(s) from an existing set of v

While developing new or extending existing custom workflow activies you might experience a problem that new or updated  input parameters will not show up on the workflow designer UI. In the Plugin Registrations tool you successfully updated the assembly, but still it does not show up on the UI. A simple trick solves the issue: In the Plugin Registration Tool select the workflow activity that you want to update and press the save button in the properties section.