Mahsud's Dynamics CRM Blog

A plugin that throws a clear error is easy. The ones that cost you an afternoon are the quiet ones: the step that never fires, the update that silently does nothing, the async job that fails at two in the morning and leaves no trace anyone thinks to look for. This is the order I work through when a Dynamics 365 plugin misbehaves, from the cheapest check to the most involved. It follows on from the plugin development guide and from the older post on enabling tracing on-premises , and it assumes you are working against a sandboxed plugin in Dynamics 365 online, where you cannot attach a debugger to the server. Step 1: establish whether the plugin is running at all Before you write a single line of diagnostic code, answer one question: is your code even being invoked? A surprising share of “my plugin does not work” turns out to be “my plugin never ran.” Open the step in the Plugin Registration Tool and check five things. Message. Create and Update are not the on...

Alongside the Web API series, this blog has carried a handful of very short posts over the years — a code snippet, a sentence of explanation, and not much else. Individually they were notes I wrote so I would not have to work the same thing out twice. Together they cover something more useful: the small pieces of JavaScript and metadata plumbing you end up needing on almost every Dynamics 365 form. I have merged five of those posts into this one, kept the code exactly as it worked, and added the context that was missing the first time round: when to use each one, what breaks, and what has changed now that Xrm.Page is deprecated. 1. Make every field on a form read-only This comes up whenever a record reaches a state where it should be locked — an approved order, a closed case, a submitted application. Rather than disabling forty fields one at a time in business rules, walk the controls collection and disable everything. function makeFieldsReadOnly() { var controls = Xrm....

Between 2018 and 2022 I published a series of short posts on this blog, each covering one Dynamics 365 Web API operation: create, retrieve, update, delete, associate, disassociate, calling actions. They were written as notes to myself while working on real implementations, and over the years they became the posts people landed on most often. The problem with that format is that nobody works on one operation in isolation. When you write JavaScript for a Dynamics 365 form you usually need three or four of these at once, and jumping between ten browser tabs to copy each helper is a poor way to spend an afternoon. So I have merged the whole series into this single reference, corrected a couple of mistakes that were in the original snippets, added the missing helper function they all quietly depended on, and brought the guidance up to date for Dynamics 365 in 2026. Everything below is code I have actually used in production environments. Where something is now deprecated I have said so and ...

I had a requirement to upload a document to the SharePoint document library (integrated with the Account entity in dynamics CE) from the power apps portal, the portal supports uploading and displaying SharePoint documents as documented here ( by placing the document location subgrid on a portal basic/advance form), but our requirement was to allow portal users to upload documents only to specific folders. For achieving this specific requirement, I have used an Html file uploader and a power automate flow that receives the request and creates a file in the SharePoint document library specific folder. The file uploader HTML code snippet, that I have used. The JS code that I used for posting the form-data with "mimeType": "multipart/form-data" , to my power automate flow. Following is the power automate flow that, triggers When a HTTP request is received . For convenience 😋 one can copy the expression below. A successful run output. After a succ...