Introduction: In this blog we will look into How to Replicate your View to all the Views   Steps: Navigate to Solution > Expand the Entity (Account) > Views > Click on Quick Find Active Account Click On Add View Columns3. You can Add fields for the view based on what you want to view.4. You can modify the width by clicking on the column name and then click Change Column Properties. Choose the quantity of pixels you’d just like the width of the column to seem as in the view.5. Click on Save And Close and  then Publish your Customization Replicate View to all other Views Together To Copy the views Start Your XRM toolbox > Connect to your organization. Search View Layout Replicator Click on Load Entities > Click on your Entity (Account) > Click on Quick Find Active Accounts. Check all your customization’s are correct, Then select all the views which you want to get reflected Save and Publish your View

Initially for parsing object to Json or json to object in Asp.net an additional Newtonsoft.Json Api was required, but now Microsoft has developed their own Apis “System.Test.Json”. Below Steps will guide you on how to use this api. Install the System.Text.Json NuGet package. To use the api make sure you import the following two namespaces: using System.Text.Json; using System.Text.Json.Serialization; Using the serializer as follows: The System.Text.Json serializer can read and write JSON asynchronously and is optimized for UTF-8 text, making it ideal for REST API and back-end applications. class WeatherForecast { public DateTimeOffset Date {get; set;} public int TemperatureC {get; set;} public string Summary {get; set;} }   string Serialize (WeatherForecast value) { return JsonSerializer.ToString<WeatherForecast>(value); } Api also support asynchronous serialization and deserialization. async Task SerializeAsync(WeatherForecast value, Stream stream) { await JsonSerializer.WriteAsync<WeatherForecast> (value, stream); } You can also use custom attributes to control serialization behavior, for example, ignoring properties and specifying the name of the property in the JSON: class WeatherForecast { public DateTimeOffset Date {get; set;}   // Always in Celsius. [JsonPropertyName(“temp”)] public int TemperatureC {get; set;}   public string Summary {get; set;}   // Don’t serialize this property. [JsonIgnore] public bool IsHot => TemperatureC >= 30; } Note: In the above point isHot property will not get parsed to json and json will look like below:      { “date”: “2013-01-07T00:00:00Z”, “temp”: 23, }

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.