Do not use any CDN links for any .js or .css file, include them in your own project. Do not give multiple references of any .js or .css file on the same HTML. If any .js or .css file is going to be used on multiple Html web resources, then keep them at one common location and include the same URL reference on all the HTML page, do not try to create same web resources repeatedly. Always try to write minimum codes and re-use the code where possible. Always try to use objects where possible. Minimize the use of global variables (use local variables). Avoid multiple API hits try to get maximum data in a single hit where possible. Use joins in fetch XML queries to get data from all the related entity to avoid multiple API hits. Use Try and catch for exception handling. Minify .js and .css file before releasing the same on production.

Using Xrm.WebApi needs you to be careful with the field names and what to use when. Especially, when you are dealing with Lookups. One of the most common errors you’ll come across is the one like below – “An undeclared property (fieldname you entered) which only has property annotations in the payload but no property value was found in the payload.” This is confusing as to what needs to be put in while setting the lookup. If you have done the below, entered the name of the field which is all in small caps  – object[“msdyn_resourcerequirement@odata.bind”] = “/msdyn_resourcerequirements(<Guid>)”; This will result in the above error!!!   You’ll need to put the Schema name of the lookup field instead and this should solve your problem – and the code should look like this – object[“msdyn_ResourceRequirement@odata.bind”] = “/msdyn_resourcerequirements(<Guid>)”; And this should totally work for you!! Hope this helps! 🙂

Introduction It is important for the end-user to understand the error displayed on D365 Portals. In this blog, we will display D365 Plugin Error on the D365 Portals. By default, the error will be displayed as shown below: Implementation Step 1: Create a new Site Setting record. Step 2: Set the values given below in the fields: Name: Site/EnableCustomPluginError Value: true Now you can see the Error thrown by D365 Plugin. Custom plugin errors will appear on the following screens: Entity list Retrieval of records Entity form Retrieve Create/Update and so on Web forms Retrieve Create/Update and so on

Introduction In this blog, we will resolve “Operation has timed out” error in D365 Portals. Steps to solve this issue: Restart your portal by going to the admin center. Steps to restart the portal: Go to the Dynamics 365 Administration Center page and select the Applications tab. Select the name of the portal, and then select Manage. Click on Portal Actions –>Restart.  Click on Restart. Wait for a few minutes and go back to your portal, it should be working now. Reference: https://docs.microsoft.com/en-us/dynamics365/portals/portal-faq

In Dynamics plugin implementations, you might have lengthy complex plugins that makes calls to Dynamics several times. I agree that calls to Dynamics should be as less as possible and use Link Entity as much as possible and the plugin should be well designed to handle such lengthy executions. However, there are instances where these plugins are probably updating some fields that in-turn trigger some other sync processes and the execution begins to take longer than it should. At times, such lengthy executions result in the plugin timing out. In the case of Dynamics 365 Online, the timeout is 2 minutes and you can’t change it. (In on-premise, you can) And now, you need to know what’s taking so long! So I want to propose a method which proved effective for me to identify this. First, in case you are looking to work with Tracing for plugins, here’s a great blog on the same – Debugging Your Plug-ins with the Plug-in Trace Log Add DateTime to Trace Logs One of the best approaches to identify what portion of the plugin execution is actually taking time to process is to keep adding Trace logs and that too, with a timestamp! This will give you an idea of what part of your plugin is taking long to execute and will give you a fair idea if anything needs to be redesigned. Set these traces at the very beginning of your plugin and at all necessary places as well as the very end to cover execution cycle well. And your logs will actually record the time when that operation was hit. So now, you have an idea of how the 2 mins are spent and maybe start troubleshooting in that direction. I hope this quick tip helps!

Most of us need this in our workflow conditions to check against – to have today’s date handy and then use them in If conditions in workflows. But, the filter in If conditions in workflows don’t let you dynamically select On or after ‘Today’. And when you want to compare to today’s date on selection of On or After, you are forced to enter a date and not dynamically select Today. To overcome this, here’s what you can do to simply store Today’s Date in all records. Calculated Date and Time field So workaround this, you can simply create a new Date and Time type of Calculated field to store the current date and use it in your workflow conditions or wherever you need it. Make sure the type of the field is Calculated and then, Edit the criteria. Select Now() function to set the value of the field. And the final criteria condition will simply look like the below Once you save and publish all your changes, you’ll see that the field is automatically populated with today’s date. Using in Workflow Conditions Now, you can use the same in the workflow conditions as shown below – and you should be able to use this in your workflow conditions which could look like this Hope this quick workaround comes handy!    

These fields which are everywhere but you don’t really pay attention to really mean something worth. So if you feel you want to get hold of someone for modifying a record. Maybe also take a look at Modified By (Delegate) just in case so that the actual user might be someone else who wanted to do another thing on that record. 🙂 Impersonation is one of the basic aspects of a plugin step that you need to carefully design to let another user (usually Admins for most implementations) make the plugin run under their context instead of giving more security roles/privileges to every other new user. Well, the same goes for Created By & Created By (Delegate) also! Modified By Usually, when you update something on a record, the Modified By is updated as expected. But notice that Modified By (Delegate) is not updated. That’s because you are the rightful owner of the record and there’s no other person involved. But what is someone else is modifying the record (who don’t have access to that record)? In that case, the Modified On (Delegate) field is populated with the name of that user. In such scenarios, Modified By (Delegate) the user is the one who caused changes to the record. Why Modified By (Delegate) was populated The reason this was populated was that the record was updated through a plugin by a user who doesn’t have write access to the record. But because the user invoked a plugin which was Impersonating as a User who has rights to the records, the record was successfully updated. And this, the actual user who called the plugin is the one who will be populated in the Modified By (Delegate) field. Hope this quick tip helps!

Let’s say you need to create a new store with multiple registers on CPOS.   It is now possible to have a retail store with multiple registers each running CPOS and each having their own dedicated hardware.   For example: A store with two registers both running CPOS and both having their own receipt printer, scanner, etc. . Here comes the concept of a shared hardware station for CPOS, It may seem impractical to have multiple registers sharing the same scanner, pin pad, etc but it is actually possible.   You’ll need to install a hardware station per CPOS and then you should be good to go.   Sharing hardware can be handy in scenarios with limited space or lesser sales persons moving around taking the sales and so on and it’s valid for CPOS.   Note: However, for MPOS you need a dedicated hardware.   Please notice that you can’t have multiple hardware stations installed on the same machine. Please do correct me anyone if that has changed 🙂 This can be done absolutely and is perfectly possible. Just deploy a Hardware station on each device and it will work as discussed in the example above.

“Run Jobs” – as the name suggests is a process between Retail Channels and Retail essentials through which we transfer data between channels and database. Please Note: Jobs Run at a specified time which may be different for every Retail Scheduler. Be aware of what the time is set for jobs to run automatically.  Running jobs at a specific time requires setting to be done so that we can schedule a specific job to run at specific time. It can be easily done manually. You’ll have to follow the below steps: Step 1: Go to distribution schedule or Channel database in Retail Dynamics 365. If the job doesn’t run from distribution schedule run it through channel database. Step 2: Go to download sessions and make sure your Job is available or in applied state. If it is in available state, go to “Batch Jobs“. Step 3: Now you will have to find the same batch job that you were searching and need to run it at a specified time. Step 4: Here, since the Job is in waiting state, you need to change it’s scheduled date and time to current time. This change must be according to the time at which you want your job needs to be run. The specified time will make your job run immediately.   Step 5: You can check if Job is being applied in “Download sessions” whenever required. Step 6: You can also change how often the job should run from going to Recurrence. Step 7: Only things highlighted in Red boxes should be checked. Hope this helps!!! Thank you! Please feel free to post any doubts you have.

Wave 2019 Updates brought some really sought-after features. Another one which I would like to bring up is the Lead Qualification experience. I’ve written this post when I enabled the Early Opt-in of Wave 2 Oct 2019 Updates. To enable Early Opt-in, please refer this post – Early Opt-in for October 2019 Wave 2 Updates This is set to release for the Oct 2019 Updates. Default Behavior So when you Qualify Lead by default – Account, Contact and Opportunity records are created. Notice that by default, the created Account and Contact are always auto-filled. Lead Qualify Experience in System Settings By default, D365 will let you create all three – Account, Contact and Opportunity records when you Qualify a Lead. When you select No, you’ll be asked which all entities should be created when you Qualify a Lead.   Lead Qualification for selected entities No, when you click on Qualify button, you’ll be treated with this Dialog box where you can choose what records should be created. I’ll select only Opportunity this time   And only Opportunity will be created and notice that the Contact and Account are blank this time. Hope this is useful! Thanks. Related Blog on one of Wave 2 2019 Update: Customize Opportunity Close dialog box in D365 CE v9 Unified Interface – Wave 2 update I’m also listed on the Top 100 CRM Blogs and Websites on Feedspot. It has a curated list of awesome bloggers.