Introduction: In this blog we will be discussing about the Business Rule validation issue in  Editable grids caused when the fields are not present in the views. Scenario: In our demonstration we will take the example of a contact form and design a business rule to lock the email field if the Job Title field is blank. Implementation: Step 1: First we enable editable gird for the contact entity as shown in the image below. Step 2:  Then we create a business rule for the contact form  to lock the Email field if the Job Title field is blank. The Business Rule is shown below. Step 3: Now in the editable grid we can see that the Email field is locked as the Job Title is blank. The field is unlocked once the job title is entered. Step 4: Now we edit the criteria of the Business Rule and add a new condition to also check if the Description field contains data  as shown in the image below. Step 5: When we go to the editable grid we see that even though the Job Title field is blank the Email field is unlocked which should have been locked. Step 6: The reason behind this is that the My Active Contacts view does not contain the field description hence the validation fails. Step 7: To solve this we add the Description column to the view as shown below. Step 8: Now if we check in the editable grid we see that the validation works correctly and the email field is locked. Conclusion: This is important to be noted as, if there is some validation done using business rules, JavaScript and field is not present in the views the validation wont work and there will be incorrect data entries made using the editable grid.

Introduction: In this blog, I will detail how to migrate Activity Parties of Emails from one CRM to another. In my previous blog, I outlined the first step of the Email migration process which is migrating the body of the email. Migrating the corresponding Activity Parties of an Email is the second step of this process, as the Email body now exists in the Target CRM. What are Activity Parties? Other than the Body, an Email Activity consists of: Sender: The person(s) sending the email. Recipient: The person(s) receiving the email. CC & BCC: The person(s) that are copied in the email. Owner: The person who is the owner of the email. Regarding: This generally links to an entity in CRM which pertains to the email. For example, a Case or a Project in CRM. ‘Sender’, ‘Recipient’, CC’, ‘BCC’, ‘Owner’ and ‘Regarding’ are each stored in CRM as a separate Activity Party of that email with a ‘Participation Type’ code (field name: ‘participationtypemask’) to establish the field that specific party belongs to i.e. 1 = Sender, 2= To Recipent and so on (as shown below). Generally, in an Activity Party, the person(s) are either System Users or Contacts. This is specified in the field ‘partyobjecttypecode’ as shown above. Keeping this in mind, one can lookup to these entities to obtain the corresponding GUIDs in the Target System and map it as the ‘partyid ‘. After the Activity Party is created, the owner of the Activity Party should be updated as per its owner in the Source environment. The ‘Owner’ Activity Party is automatically created by CRM as the same User as the Owner of the Email (configured when you migrate the Email Body in Step 1). The ‘Regarding’ Activity Party links to a Case/ Project and not a ‘person’, however, the same logic applies i.e. map the required GUID and its type. Migrating Activity Parties is not as complicated once understood. Unfortunately, not much is easily available online about this. I hope this blog demystified a few concepts about Activity Parties of an Email and how they can be migrated from one CRM to another. My next blog will detail how to migrate Email Attachments and update the status of an Email.

Introduction: Data migration can be a little challenging, especially when it comes to Emails. In this blog, I will outline the steps that need to be followed to successfully migrate Emails as well as important things to keep in mind during the process. Steps: There are four main steps to follow to successfully migrate an Email from Source to Target: Send the body of the Email. Send all the related Activity Parties. Send the details of the related Email Attachment(s). Update the Status of the Email. In this blog, we will be dealing with the first step i.e. creating the map in TIBCO Cloud Integration to send the Body of an Email. Migrating the body of the Email is straightforward compared to the next step but there are a few aspects to keep in mind: 1) Send the email as Open so that Activity Parties and Attachments can be migrated in the following steps. Not sending the email with an “Open” status could lead to Activity Parties and Attachments not being migrated to the corresponding email. 2) When an email is migrated, the owner of the email will be the User configured in the CRM Connection in Scribe. In order to maintain the same owner as in the Source, you can update the email with the correct owner after it is created. In the screenshot below, I am using a Lookup Table in Scribe to map the User GUID of the Target System. 3) If you want the GUID of the email to remain the same in Source and Target, do not forget to map the ‘activityid’ of the Email entity. Conclusion: I hope this blog provided some insight into the migration process for Email Activities. In the next blog ‘Email Migration from CRM v8.2 to CRM v9 using TIBCO Cloud Integration: Activity Parties‘, I will talk about migrating ‘Activity Parties’ which can be the most challenging part of Email Migration.

Introduction: Xrm.Navigation provides navigation related methods like openAlertDialog, openConfirmDialog, openErrorDialog, openFile etc. In this blog we will be discussing about openForm method which opens an entity form or a quick create form. There might be requirements to open a new form with certain fields pre-populated on certain conditions or to open a specific record. Implementation: Step 1: Syntax:Xrm.Navigation.openForm(entityFormOptions,formParameters).then(successCallback, errorCallback) Here the parameter entityFormOptions is an Object and is a required parameter. Step 2: In the below example taken, we have written a script on the contact form to trigger on Save which will open up the quick create form with values filled in some of the fields. As we can see in the below image we have passed the execution context as the first parameter. Step 3: The code for the same is given below: scripting={ myfunction:function(executionContext){ debugger; var formContext = executionContext.getFormContext(); var entityFormOptions = {}; entityFormOptions[“entityName”] = “contact”; entityFormOptions[“useQuickCreateForm”] = true; var formParameters = {}; formParameters[“firstname”] = formContext.getAttribute(“firstname”).getValue(); formParameters[“lastname”] = formContext.getAttribute(“lastname”).getValue(); formParameters[“fullname”] = formContext.getAttribute(“fullname”).getValue(); formParameters[“jobtitle”] = “Developer”; Xrm.Navigation.openForm(entityFormOptions, formParameters).then( function (success) { //Any Specific action to be performed console.log(success); }, function (error) { //Any specific action to be performed console.log(error); }); } }; Step 4 : After updating the value and saving the form a quick create form opens up with some of the fields filed out. We get the value of the fields using the formContext.getAttribute(“fieldname”).getValue(); The successCallback and errorCallback are optional. In the Unified Interface the successCallback and the errorCallback function will be executed only if the we are opening the quick create form. Step 5: As seen in the image below we make some changes to the contact form and save the changes. After saving a new contact quick create form opens up with the first name, last name and job title fields filled. Here in our case we have specified entityFormOptions[“useQuickCreateForm”] = true; If this property is not set a normal form open’s up with the values filled in the fields in the same window. If we want to open the new record in a new window we should specify entityFormOptions[“openInNewWindow”]= true which is a Boolean value and it is an optional field. Step 6: If we want to open a specific record we just specific the following entityFormOptions[“entityName”]=”account” entityFormOptions[“entityId”]=”Specify Guid Here” Hope this helped!

A fiber optic link service organization utilizes the application to react to blackouts by dispatching specialists to issue zones. An in-home medical care specialist organization utilizes the application to timetable and dispatch medical services laborers to direct medication and other considerations to various patients. A facility manager uses the Dynamics 365 Field Service management software to deliver maintenance and repair services for heating and cooling equipment.  A medical device manufacturer sells machines to hospitals and clinics and uses the application to manage maintenance services over the lifetime of the machinery. Customer Service will typically use the desktop application to prioritize different requests so that work orders and on-site visits can be created from cases. Service Managers will use the software to oversee service delivery and track performance metrics over time. Introduction: This blog explains how to create Record in CRM using PowerApps with Microsoft flow. Steps to be followed: Create Blank App. Insert Label, Text Input and Button controls.(Fields which you want to create in CRM.) Select the Button (Add To CRM) and go to Action –> Flows. Click on Create a New Flow. Click on New step –> Add an Action. Select Dynamics 365 –> Create a new record. Enter the Organization Name and Select the Entity for which you want to create record in CRM. For Last Name, click on “Ask in PowerApps”. Repeat for Email and First Name. For Description we will add text. Give Name to the flow and Create Flow. Now change the OnSelect Property of button.(here lastname, firstname and email are the name of text input control) Enter Details and Click on Button. Record will get created in CRM.Description:

Introduction: Package deployer is used to simplify the deployment process. It has the ability to automate the import of one or more solution.In this blog we will discuss about the error “Verify the state of the solution in CRM” which is shown while importing solution using package deployer.  Implementation: Step 1: In the ImportConfig.xml file we give the name of the solutionpackagefilename, that is the name of our solution. Step 2: Then we build the project and copy the folder containing the solution and the Package.dll file created. Step 3: Then we run the Package Deployer application and connect to the  organization the below screen shows the solution is successfully unpacked. But after clicking Next when the solution is imported the error shown is as follows. Step 4: In the Log file we can see that the import was not successful due to the missing dependencies. Once the missing dependencies are added the solution is successfully imported using the package deployer . The missing components can be verified if the solution is imported manually.

Overview Xrm.Panel is a new additional to the client-side scripting in Dynamics 365. This feature is still in preview in the D365 December 2016 update. Panel is a simple static place on your D365 web client which loads a Web Page inside it. Perhaps, the best use of the same could be a Web Chat application implementation. Implementation Simple – I’ve made a JS Web Resource that has a function to call the Xrm.Panel.loadPanel(url, title); method and I’ve invoked the same on change of a Phone Number. Here’s a simple JS snippet I’ve written: oAccountCustomization = { loadPanel: function() { “use strict”; Xrm.Panel.loadPanel(“https://cft89.crm.dynamics.com//WebResources/new_SamplePage”, “Hello”); } }; And redirected it to another HTML page in my own D365. Then, I’ve added this to the onChange of the PhoneNumber on the Account record. And saved and Published the customization. Seeing it work: Now, when I change the Phone Number field on the Account, the slider appears on the right hand side of the page. You can click on the arrow to bring it in focus. Here we go! The Panel is now seen. Remember, this works only on the Web Client.

Introduction: This blog consists of information on how you can find the users having specific privileges and in which role they have the privileges. Solution: Make use of the below Fetch XML to identify who has access to prvReadAccount related to his Role. The fetch can be performed on System User level or for teams. <fetch version=”1.0″ output-format=”xml-platform” mapping=”logical” distinct=”false” > <entity name=”privilege” > <attribute name=”name” /> <link-entity name=”roleprivileges” from=”privilegeid” to=”privilegeid” alias=”pu” link-type=”inner” > <link-entity name=”role” from=”roleid” to=”roleid” alias=”rpu” link-type=”inner” > <attribute name=”name” /> <link-entity name=”systemuserroles” from=”roleid” to=”roleid” alias=”sr” link-type=”inner” > <link-entity name=”systemuser” from=”systemuserid” to=”systemuserid” alias=”srr” link-type=”inner” > <attribute name=”systemuserid” /> <attribute name=”fullname” /> </link-entity> </link-entity> </link-entity> </link-entity> <filter type=”and” > <condition attribute=”name” operator=”eq” value=”prvReadAccount” /> </filter> </entity> </fetch> Response: <fetch version=”1.0″ output-format=”xml-platform” mapping=”logical” distinct=”false” > <entity name=”privilege” > <attribute name=”name” /> <link-entity name=”roleprivileges” from=”privilegeid” to=”privilegeid” alias=”pt” link-type=”inner” > <link-entity name=”role” from=”roleid” to=”roleid” alias=”rpt” link-type=”inner” > <attribute name=”name” /> <link-entity name=”teamroles” from=”roleid” to=”roleid” alias=”tr” link-type=”inner” > <link-entity name=”team” from=”teamid” to=”teamid” alias=”trr” link-type=”inner” > <attribute name=”teamid” /> <attribute name=”name” /> </link-entity> </link-entity> </link-entity> </link-entity> <filter type=”and” > <condition attribute=”name” operator=”eq” value=”prvReadAccount” /> </filter> </entity> </fetch>

Introduction: This blog explains how to Integrate PowerApps with Dynamics 365. Keep the following restrictions in mind: Only PowerApps users in the same tenant can access the embedded app. To access PowerApps using Internet Explorer 11, you must turn off Compatibility View. Steps to be followed: In powerapps.com, on the Apps tab, click or tap the ellipsis ( . . . ), then Details. Copy the App ID. Substitute the [App ID]value in the URI.: https://web.powerapps.com/webplayer/iframeapp?hideNavBar=true&source=iframe&appId=/providers/Microsoft.PowerApps/apps/579938ff-e1a0-4891-a8b9-8d69c103fd84 Embed your app in a website: Embedding your app is now as simple as adding the iframe to the HTML code for your site.http://<iframe width=”[W]” height=”[H]” src=”https://web.powerapps.com/webplayer/iframeapp?hideNavBar=true& source=website&screenColor=rgba(165,34,55,1)&appId=/providers/Microsoft.PowerApps/apps/[AppID]”/> To add PowerApp inside CRM  as web resource: Keep the following points in mind for authenticating users of your app: If your website uses Azure Active Directory (AAD) based authentication, no additional sign-in is required. If your website uses any other sign-in mechanism or is not authenticated, your users see a sign-in prompt on the iframe. After they sign-in, they will be able to run the app as long as the author of the app has shared it with them Steps: Specify the width and height for App. Specify the app id. Sample HTML code: <!DOCTYPE html> <html>  <head> <title>HTML Iframes</title> </head> <body> <p>App Goes here…</p> <iframe width=”250″ height=”250″ src=”https://web.powerapps.com/webplayer/iframeapp?hideNavBar=true&source=website&screenColor=rgba(165,34,55,1)&appId=/providers/Microsoft.PowerApps/apps/579938ff-e1a0-4891-a8b9-8d69c103fd84″ /> </body> </html>  

Overview: In this blog we will see how we can prepopulate lookup and dropdown (option set) fields on an Entity form in D365 CRM Portals using JS. Pre-Requisites: D365 CRM Portals D365 CRM Environment Introduction We know that if we want to prepopulate a lookup or a dropdown field on a form in CRM Portals the best method is to use Entity Form Metadata. But there is an alternative way to prepopulate the Lookup and dropdown (Option set) fields on an Entity form in D365 CRM Portals using JS. Scenario: To implement the functionality of prepopulating a lookup field we will be using the account lookup field on the CRM entity form based on the value entered in the contact field for a created opportunity in the partner portal. For the prepopulating the dropdown field we will be using the opportunity status field. Process: First of most we will see how to prepopulate the lookup field on the entity form based on the value entered in another field. As mentioned in the above scenario we need to prepopulate an account field on an opportunity form based on the value present in the contact field. To insert a value into a lookup field using JS(jquery) we need the following information as mentioned below. The field value to be displayed. For eg. Account full name. The GUID if the record to be displayed. For eg. GUID of the account record. The logical name of the entity. For eg. Logical name of the account entity. Now we will see how to get these details form the existing information we have on the opportunity form. When we open an opportunity record, on the details page in the URL section we get the id of the opportunity record as shown below We will insert this id into the fetch xml using liquid template to obtain details of the contact related to the following opportunity record as shown below. As shown above we have used the opportunity id in the fetchxml to get the contact details. Once we have obtained the contact details from which we will be using the contact name value in the next fetchxml to get the related account information. In the following below shown fetchxml we will get the value and the id of the account record to be inserted. Once we get the account record details we will write the jquery in the following manner to insert the value into the lookup field. Jquery syntax: <script> $(“form_attributeid_name”).val(“record_value”); $(“form_attributeid”).val(“record_GUID”); $(“form_attributeid_entityname”).val(“entity_logicalname”); </script> Once we publish the liquid code we will see that the account field on the opportunity form is prepopulated with the value related to the value present in the contact field. For prepopulating the dropdown(option set) field we need the option set value of the record to be displayed. To set the value in the option set we will write the following jquery. $(form_attributeid).val(“attribute_optionsetvalue”); Hope you all find this blog helpful. Happy coding in CRM portals.