Monday, August 28, 2017

Debugging Quick Create Form Parameters

I’ve been working with Microsoft CRM since the release of CRM 2011 (Yes, I know it’s now called Dynamics 365 for Customer Engagement, but just like Jar Jar Binks, let’s just pretend that didn’t happen).  But every now and then it forces me to peel back a few more layers to reveal something new that I’ve never known before.  This is the story of one of those “special” times.

TLDR: When adding form parameters to a quick create form, add them to the default main form as well.  Not doing so will cause your quick create form to throw a server side error and not load.

The Task

I recently received a fairly straight forward task: use the zip/postal code from the parent form (the form from which the quick create is opening from) to populate the tax rate on the quick create.  At least those were the fairly straight forward business requirements.  In order to implement it, I had to trigger a call on load of the Quick Create Form to auto-populate a field based on the results of a CrmWebApi query that used the value of a zip code field on the parent in the query filter.

So the first question was how to get access to the parent form’s attribute.  There are 3 basic options:
  1. Setup a field mapping in the entity relationship
  2. Pass in the value as a query string parameter
  3. Perform a call to the server from the onLoad of the quick create form, to query the data.
Option 1 was codeless, but I didn’t need the zip code field on my quick create entity and I avoid adding data that further denormalizes CRM, so it was at best, a last option.

Option 2 made sense, I just wasn’t sure if CRM supported adding parameters to a quick create form.

Option 3 was doable, but I’d have to make another call to CRM which I also avoid doing.

I quickly opened up the quick create form and saw that it did indeed allow adding parameters, so Option 2 became my saving grace.  I added “DLaB_ZipCode” as a form parameter to the quick create form (who am I kidding?  I totally didn’t read the requirements and attempted just “ZipCode” only to receive a nasty error that an underscore was required), and updated the Xrm.Utility.openQuickCreate call site to include the new “DLaB_ZipCode” parameter".

Finally I updated the onLoad of the quick Create form to get the newly added form parameter, and use it to query the CrmWebApi for the tax rate:

It Works On My Machine

I tested the new functionality by triggering the quick create form, and verifying that I did get the correct tax rate.  Everything worked smoothly, so I pinged my BA and told her it was ready for testing, and went onto my next task.  She ran through a couple quick tests as well and also declared it “programming complete.”  The next day during our daily stand up, a new BA to the project, we’ll refer to him as “Roger”, complained that he couldn’t get that particular quick create form to load.  I quickly ran another test on my machine and it still worked fine.  I asked Roger to test again; still broken for him…  weird. “Hmm… must either be a user issue, or a machine issue… “ I thought to myself.  It also didn’t help that the error was less than helpful: “Error: An Error has Occurred”.  I downloaded the log file but it too lacked anything helpful.  I then asked the original BA to try logging in on Roger’s machine and seeing if she should access the form from there.  A quick log off/log on later, and the results were unchanged.  Roger’s machine was still getting an error.  On a whim, after receiving the error on Roger’s machine, the BA cleared her browser cache, and discovered she was getting the error now as well.  I then opened up an incognito window and found that yes, I was now receiving the error as well.

Spinning A Web

My first assumption was that there was a JavaScript error occurring somewhere.  After diving down a couple rabbit holes, I was unable to find any errors being thrown that I could step into and debug. 

I then decided I must have the parameter name wrong somehow, so while debugging I cleared the parameters array that was being passed into the the openQuickCreate call.  This resulted in the form loading just fine but sans tax rate, obviously.  I closed the form and tried to open it again, this time leaving the zip code in the parameters, and to my dismay it opened just fine, with the correct tax code!  “What sort of magic is this?” I said to myself.  I asked Roger to test it on his machine again, but, even though I managed to fix the problem on my machine, he was still seeing the error.

Ok, so something must be getting cached on my machine that somehow allows the parameter on the form.  I started up a new incognito session and this time, after triggering the quick create from, I typed “localStorage” in the console window and hit enter:
I had never actually done that before and had no idea what I was looking for.  I took note of the 15 items in the storage, and then triggered the openQuickCreate call once more, but this time I removed the zip code parameter.  I once again spit out the localStorage and noted that now there were 18 items in the storage.  Doing a quick visual comparison one of the new keys stood out to me:

LocalStorageCache/EntityDefaultForm/DLaB_Payment: “5F5CC9D7-1E84-4381-AA14-32EA68536233”

Squashing The Bug

Apparently CRM was failing to cache the default entity form.  I then took a wild guess, and added the form parameter to the default main form for the entity and retriggered my test.  No error!  After another request to Roger to test it on his machine, it was confirmed that the bug had been resolved!  I then kicked over the trash can next to my desk in sheer joy and nearly gave my BA a heart attack…  I wouldn’t recommend that.

So What Happened?

Apparently before opening the Quick Create form, CRM attempts to load the default form.  This will cause the default form id to get cached in the localStorage.  Since my BA and I had both already cached this value in my localStorage before adding the “DLaB_ZipCode” form parameter, we didn’t have any issues after it was added.  Since Roger was new to the project, he had never cached the value and since I hadn’t added the “DLaB_ZipCode” parameter to the default form, he was getting the server error.  Adding the form parameter to the default form allowed the initial lookup of the default form to be successful and prevented the error from occurring. 

So if you’re adding form parameters to a quick create form, always remember to add them to the default form as well, even if it “works” on your machine…

Friday, August 4, 2017

TypeScript Makes Writing Cleaner Code Easier


Clean Coders know that Boolean Arguments can be dangerous and as a general rule, should be avoided.  I had this thought in mind when writing a TypeScript unit test recently.  I had this bit of code which is rather ugly and not immediately obvious what it was doing.
getPaymentMethodsSpy.and.callFake(() => ActionsStubs.GetPaymentMethods.fakeResponseWithPaymentCount(1));
await Payment.setPayments("");
CommonLib.setValue(Payment.fields.paymentMethod, 1);
The fakeResponseWithPaymentCount sets the getPaymentMethodsSpy to generate the given number of fake existing payments for a count (1 in this case) as a response from the custom action, GetPaymentMethods.  Each odd numbered payment is a bank, and each even numbered one is a credit card.   So for this snippet, line 1 fakes a response of 1 Bank Payment, line 2 sets the Payment on the form, and line 3 selects that payment as the payment to use.  Simple right?  Not.  Good luck remembering this and re-creating it for processing a Credit Card.
So how does TypeScript here help make this cleaner?  Before we get there, lets do the obvious first step and refactor these statements out to a method:

async function selectExistingPayment(isBank: boolean) {
    getPaymentMethodsSpy.and.callFake(() => ActionsStubs.GetPaymentMethods.fakeResponseWithPaymentCount(2));
    await Payment.setPayments("");
    CommonLib.setValue(Payment.fields.paymentMethod, isBank ? 1 : 2);
This is way more usable, except when I’m looking at a calls site for it, it’s still really not clear:
What does false mean?  Don’t select it?  Sure, you could create an enum and define “credit card”, and “bank” as the two options, but this is just a unit test helper method.  I’m not exposing it anywhere, and even if I did, that’s a lot of extra work (Ok, so it’s a tiny bit of work, but it can feel like a lot #1stWorldProblems).  The simple solution TypeScript offers is string Union Types.
async function selectExistingPayment(type: "CC" | "BANK") {
    getPaymentMethodsSpy.and.callFake(() => ActionsStubs.GetPaymentMethods.fakeResponseWithPaymentCount(2));
    await Payment.setPayments("");
    CommonLib.setValue(Payment.fields.paymentMethod, type === "BANK" ? 1 : 2);
So now the calls sites look like this:
Extremely readable as to what I’m doing, and you get compile time error checking that "Dad" (or any other values besides "CC" and "BANK" ) is not a valid Existing Payment Method!

Monday, July 31, 2017

How To Define Custom Action Parameters For Plugin Contexts

In my previous post “I’ve Been Doing Plugin Parameters Wrong For 7 Years”, I walk through IMHO the correct way to access parameters from the requests coming in for standard Dynamics 365 for Customer Engagement (hereafter referred to as CRM) Messages.  Applying the same logic for custom action plugins was a little more complicated because naturally, there are no message classes in the SDK for custom actions.  The CrmSvcUtil does generate early-bound classes for custom actions, which work fairly well for input parameters since they are editable, but response parameters by default are read-only.  So any attempt to set a value in the response via the parameter property, is not allowed.  There is also no defined list of parameter logical names, which could be used to set the values in the response context in a late-bound manner.

So, how does one work around the read-only response parameters and lack of a defined list of parameter logical names?  By extending CrmSvcUtil to make the read-only fields editable, and to generate a list of parameter logical names.  This isn’t very simple to do since you have to work directly with the DOM (no, not the html DOM, the C# DOM, it’s way less fun).  The good news is I have already done this, and provide it as a set of options in the Early-Bound Generator (If you aren’t already using the Early-Bound Generator, just download it from the Plugin Store within the XrmToolBox).  On the Actions Tab, just check “Generate Attribute Name Consts” and “Make Responses Editable”:


With those two options checked, when actions are generated, responses will be editable, and both request and response classes will contain a static class with consts for each parameter.  The absolute simplest and most immediate method of taking advantage of these generated action request/response classes would be to manually create them in the plugin like so:

public void Execute(IServiceProvider serviceProvider)
    var context = (IPluginExecutionContext) serviceProvider.GetService(typeof(IPluginExecutionContext));
    var request = new your_CustomActionRequest
                      Parameters = context.InputParameters
    var response = new your_CustomActionResponse
                       Results = context.OutputParameters

    // Use the Request and Response Properties
    response.Result = Process(request.SomeInputValue);

This isn’t horrible, but if you call any other methods, you’ll probably end up passing in the context and the request and/or response to that method.   The request and the response truly are part of the context, so if would make sense if we can make them just appear as a part of the context.  This can be done by creating your own custom context class:

public class ActionContext<TRequest, TResponse> : DLaB.Xrm.Plugin.DLaBExtendedPluginContextBase
    where TRequest : Microsoft.Xrm.Sdk.OrganizationRequest, new() 
    where TResponse : Microsoft.Xrm.Sdk.OrganizationResponse, new()
    public TRequest Request { get; set; }
    public TResponse Response { get; set; }
    public ActionContext(IServiceProvider serviceProvider, DLaB.Xrm.Plugin.IRegisteredEventsPluginHandler plugin) : base(serviceProvider, plugin)
        Request = new TRequest
            Parameters = PluginExecutionContext.InputParameters
        Response = new TResponse
            Results = PluginExecutionContext.OutputParameters

*Note* I’m using the DLaBExtendedPluginContextBase as my base class since this exposes all the IPluginExecutionContext methods for you (this is available on Nuget DLaB.Xrm.2015/2016). If you don’t want to use that, your ActionContext base class will need to implement the IPluginExecutionContext interface. 

Now our plugin code can be written with even less keystrokes:

public void Execute(IServiceProvider serviceProvider)
    var context = new ActionContext<your_CustomActionRequest, your_CustomActionResponse>(serviceProvider, this);

    // Use the Request and Response Properties
    context.Response.Result = Process(context.Request.SomeInputValue);

It might even make sense to create your own specific action context class to perform additional validation.  This would technically be cleaner code as well, since the context should be responsible for determining if it’s valid, not the plugin.  For example, here is a Custom Action class for processing payment that performs some validations:

using System;
using Consoto.Xrm.Plugin;
using DLaB.Xrm.Plugin;
using Microsoft.Xrm.Sdk;
using Input = Consoto.Xrm.Entities.cnst_SubmitPaymentRequest.Fields;
namespace Consoto.Xrm.ExternalRest.Finance.Actions
    public class SubmitPaymentContext : ActionContext<Entities.cnst_SubmitPaymentRequest, Entities.cnst_SubmitPaymentResponse>
        public const int CreditCardPaymentType = 1;
        public const int BankPaymentType = 2;
        public SubmitPaymentContext(IServiceProvider serviceProvider, IRegisteredEventsPluginHandler plugin) :
            base(serviceProvider, plugin)
            switch (Request.paymentType) {
                case CreditCardPaymentType:
                case BankPaymentType:
                    throw new InvalidPluginExecutionException($"Payment Type of {Request.paymentType} is unknown!");

This has the added benefit of not having to redefine the Request and Response Types in the plugin:

public void Execute(IServiceProvider serviceProvider)
    var context = new YourCustomActionContext(serviceProvider, this);

    // Use the Request and Response Properties
    context.Response.Result = Process(context.Request.SomeInputValue);

It used to take me over an hour (depending on the number of parameters in the custom action) to create the correctly defined custom action contexts, and of course I’d usually have a type-o or two that would require time debugging and re-updating.  Now that all the parameters are automatically generated, I get to spend that time on more productive things, like this blog post ;)

If you have any comments/feedback/suggestions/better methods, I’d love to hear them.  Happy coding!

Saturday, May 20, 2017

Making CrmWebApi Entity References Suck Less For Creates and Updates

For those that “grew up” on the 2011 Rest endpoint for CRM, attempting to populate Entity Reference attributes for create or update calls feels rather painful in the new CrmWebApi.
account["primarycontactid@odata.bind"] = "/contacts(E15C03BA-10EC-E511-80E2-C4346BAD87C8)";
Was it “"@odata.bind” or “@bind.odata”? Was it a forward slash or backward slash?  Did the Guid have curly braces?

Yes it’s a small pain, but it is bigger if you normally use field accessors (“entity.field” rather than array accessors: “entity[‘field’]”) because "account.primarycontactid@odata.bind" isn't a valid field name.  It’s probably because of my C# background, but I prefer not to use the object array accessor method when possible.  So the question is, how to make this syntax better and help me remember it.

On my current project I use David Yack’s CRMWebAPI.  It’s simple, and uses standard Promises, so no need for a new library, just polyfill Promises (if you’re using IE 11) and you’re all set.  The calls are wrapped by a custom TypeScript library (CrmWebApiLib) to allow for some custom changes, of which, this implementation is one.  First, the library defines an Entity Reference class (*Note, this is TypeScript, get it, use it, love it)
export class EntityReference implements ODataFormattable {
    constructor(public collectionName: string, public id: string) { }
    toODataFormat = (): string => {

        return `/${this.collectionName}(${CrmWebApiLib.removeCurlyBraces(})`;
    getODataPropertyName = (propertyName: string): string => {
        return `${propertyName}@odata.bind`;
The class has two public properties, “collectionName” and “id”, and implements the two functions of the ODataFormattable interface, “toODataFromat” and “getODataPropertyName”.  The toODataFormat adds the forward slash and formats the guid correctly, and the getODataPropertyName appends the “@data.bind” to the property name parameter.

The ODataFormattable interface just defines the two functions.  Then there is also a User Defined Type Guard to determine if any given object implements the ODataFormattable interface:
export interface ODataFormattable {
    toODataFormat(): string;
    getODataPropertyName(propertyName: string): string;

export function isODataFormattable(arg: any): arg is ODataFormattable {
    const formattable = arg as ODataFormattable;
    return formattable && formattable.toODataFormat !== undefined && formattable.getODataPropertyName !== undefined;
This then is all used in the prepareForOData function:
 * Loops through properties, searching for any ODataFormattable properties or arrays with ODataFormattable, and updates the format to be OData Friendly
 * @param data
function prepareForOData(data: any): any {
    const oData = {};
    for (const propName in data) {
        if (!data.hasOwnProperty(propName)) {
        const value = data[propName];
        if (isODataFormattable(value)) {
            oData[value.getODataPropertyName(propName)] = value.toODataFormat();
        } else if (value instanceof Array) {
            oData[propName] =;
        } else {
            oData[propName] = value;
    return oData;
It creates a new object, and basically loops through all properties of the data object, copying it over to the new object.  If the value of the property is a ODataFormatable, it will update the value as well as the property name.  There is then a recursive map call to handle arrays as well (think party lists).  prepareForOData is then called from within the create and update methods:
export function create(entityCollection: string, data: any): Promise<any> {
    return instance().Create(entityCollection, prepareForOData(data));
export function update(entityCollection: string, key: string, data: any, upsert?: boolean): Promise<any> {
    if (key.indexOf("{") >= 0 || key.indexOf("}") >= 0) {
        key = CrmWebApiLib.removeCurlyBraces(key);

    return instance().Update(entityCollection, key, prepareForOData(data), upsert);
And now, these two calls, will result in the same exact request made to the CrmWebApi:

No Bueno
const note = {};
note["notetext"] = CommonLib.getValue(fields.description);
note["objectid_allgnt_location@odata.bind"] = `/allgnt_locations(${CommonLib.getSelectedLookupId(fields.location)})`;
CrmWebApiLib.create("annotations", note);

Muy Bueno
const note = {
    notetext: CommonLib.getValue(fields.description),
    objectid_allgent_location: new CrmWebApiLib.EntityReference("allgnt_locations", CommonLib.getSelectedLookupId(fields.location))
CrmWebApiLib.create("annotations", note);

Monday, May 1, 2017

How To Add Custom Filters That Are Asynchronous In Dynamics 365 Customer Engagement

Adding custom filters to lookup entities isn’t entirely simple.  It involves adding a trigger to the PreSearch function in which a call is made to set the filter on the control using addCustomFilter. The PreSearch event must be synchronous since it is triggered once the user has selected the lookup, and needs to apply the filter right then. 

But what if you want to do something like query the lookup entity for the given filter, and relax the criteria if nothing is found (i.e. Search by First and Last name, unless no match is found, then search by Last Name only).  That either involves a blocking synchronous call (Yuck), or some form of black magic to make something asynchronous behave synchronously.  Well, maybe not black magic, just 40 lines of TypeScript:

const _preSearchFilters = {} as { [index:string]:string };
 * Handles adding a PreSearch that is Asynchronous.  To be called in the onLoad of the form.  This will trigger the getFilter method to attempt to assign the filter.
 * The Lookup Attribute will be disabled until the getFilter method has finished executing
 * @param info Object that contains the following properties:
 *             control - Name of the lookup control to add the PreSearch Filter for.
 *             filteringEntity - If entityLogicalName is not specified, the filter will be applied to all entities valid for the Lookup control.
 *             getFilter - Function that returns the Promise of the filter Xml.
 *             triggeringAttributes - List of attributes, that if changed, will result in the filter needing to be updated.

export function addAsyncPreSearch(info: { control: string, filteringEntity?: string, getFilter: () => Promise<string>, triggeringAttributes?: string[]}) {
    const setAsyncFilter = async () => {
        const enablePostFilter = !Xrm.Page.getControl(info.control).getDisabled();
        if (enablePostFilter) {
        try {
            _preSearchFilters[info.control] = await info.getFilter();
        } catch (e) {
            console.error(`Error occurred attempting to get the preSearch filter for ${info.control}`, e);
            _preSearchFilters[info.control] = "";
        } finally {
            if (enablePostFilter) {
    Xrm.Page.getControl(info.control).addPreSearch((context: Xrm.Page.EventContext) => {
        const ctrl = (context.getEventSource() as Xrm.Page.LookupControl);
        if (ctrl && ctrl.addCustomFilter) {
            ctrl.addCustomFilter(_preSearchFilters[ctrl.getName()], info.filteringEntity);
    if (info.triggeringAttributes && info.triggeringAttributes.length > 0) {
        for (const att of info.triggeringAttributes) {

That’s a lot of code, let’s walk through it.

First, a module level field (_preSearchFilters) that stores the filters for each control is declared and instantiated (note there is an assumption that you will only ever have one filter per control, which I think is pretty safe).  For those of you new to TypeScript, “{ [index:string]:string }” is how you define that the field is an object, which is indexable by a string, returning string.  This would be equivalent to a C# Dictionary<string,string>.

Next is a nested function “setAsyncFilter” that wraps the async function “getFilter” that is passed in.  It handles 2 things, disabling the control until the async function finishes, and storing the result of the async function in the “_preSearchFilters”.  If the control doesn’t get disabled, then there is a chance that the user could attempt to perform a search the async function determines what the filter should actually be.

After the “setAsyncFilter” definition comes the first code that is actually executed, a call to get the control, and add an anonymous function as a preSearch.  The function just calls “addCustomFilter” on the control that triggered the action, with the optional filteringEntity parameter.

Next to last is an if statement to trigger the “setAsyncFilter” function, each and every time a field is updated that could potentially change the filter.  This if followed by the last step, a call to “setAsyncFilter” to initialize the value in the “_preSearchFilters: field.

To use this function, just call it in the onLoad of the form:

    control: Lead.fields.installFee,
    filteringEntity: "new_installationfee",
    getFilter: getInstallationFilter,
    triggeringAttributes: [Lead.fields.campaign,
The call above adds an Async PreSearch to the installFee control.  The filter is to be applied to the “new_installationfee” entity, and is generated by the Promise returning function, “getInstallationFilter”.  Finally, a trigger is added to refresh the filter whenever the campaign or callType fields are updated.  That's it.

Chalk one up to TypeScript for handling the async/await.  Just don’t forget to polyfill your Promise call, or your IE 11 users won’t be too happy Winking smile

Friday, April 28, 2017

Refactor Makes “Perfect”

I was recently doing a unit test of some Typescript logic for a Form in Dynamics 365 for Customer Engagement (Hereafter referred to as CRM).  Our CRM instance maintains a list of Localities and when a user selects a State/County it should perform different actions based on the number of localities found for the state/county combination:

  • 1 found: Set the Lookup to the single Locality 
  • 1+ found: Filter the Localities Lookup by state and county
  • 0 found: Filter the Localities Lookup only by state and allow the user to choose.

In writing the test case for the first lookup, this is what I came up with at first:

it("should set locality if a single locality exists for the state/county", async (done) => {
    spyOn(restLibMock.CrmWebApiLib, "getList").and.callFake((r) => CrmWebApiLibStubs.getList.defaultValuesUsingSelect(r, 1));
    new Squire()
        .mock(restLibMock.path, restLibMock)
        .require(["dfnd_/scripts/lead/CustomerStage"], async (m: { CustomerStage: typeof CustomerStage }) => {
            await m.CustomerStage.setLocalityFilter();
            expect(CommonLib.getValue(LeadCommon.fields.locality)).toBeTruthy("because the locality should have been set because only one locality exists for the given city/state");

It works, but it sucks:

  • It’s really confusing (I’m going to explain it line by line, and you still probably won’t understand it)
  • A lot will need to be duplicated to handle the other 2 cases.

First thing it does is setup a fake for the CrmWebApiLib module in restLibMock using a Jasmine Spy.  The fake “defaultValuesUsingSelect” just returns an result where the fields selected are populated with their own values, and the 1 just means that one item should be returned:

spyOn(restLibMock.CrmWebApiLib, "getList").and.callFake((r) => CrmWebApiLibStubs.getList.defaultValuesUsingSelect(r, 1));

The next 3 lines are setup for injecting the mock as CrmWebApiLib module, into CustomerStage.  It accepts a callback with a parameter that has a CustomerStage Property that has the mock CrmWebApiLib injected:

new Squire()
    .mock(restLibMock.path, restLibMock)
    .require(["scripts/lead/CustomerStage"], async (m: { CustomerStage: typeof CustomerStage }) => {

The final lines are the actual test that needs to be performed.  Call setLocalityFilter, and verify that that Locality attribute has had it’s value set:

await m.CustomerStage.setLocalityFilter();
expect(CommonLib.getValue(LeadCommon.fields.locality)).toBeTruthy("because the locality should have been set because only one locality exists for the given city/state");

Even if you do understand how this works now, I’d be willing to bet the “future you” who looks at it in 5 days, will require significant time/energy to re-figure out what it’s doing.  No bueno.

Here is the refactored version with the helper method:

it("should set locality if a single locality exists for the state/county", async (done) => {
    const sut = await getCustomerStageWithMockedCrmWeb(1);
    await sut.setLocalityFilter();
    expect(CommonLib.getValue(LeadCommon.fields.locality)).toBeTruthy("because the locality should have been set because only one locality exists for the given city/state");
function getCustomerStageWithMockedCrmWeb(numResults: number): Promise<typeof CustomerStage> {
    return new Promise((resolve) => {
        spyOn(restLibMock.CrmWebApiLib, "getList").and.callFake((r) => CrmWebApiLibStubs.getList.defaultValuesUsingSelect(r, numResults));
        new Squire()
            .mock(restLibMock.path, restLibMock)
            .require(["scripts/lead/CustomerStage"], (m: { CustomerStage: typeof CustomerStage }) => {

The actual test method is now dead simple, Get the SUT (Subject Under Test), set the locality filter, and assert that the locality was set and the new helper method “getCustomerStageWithMockedCrmWeb” can now be reused in the other three calls with minimal coding required/repeated.  If “future you” looked at that code in 5 months, it would immediately make sense.    Refactor, Refactor, Refactor.


Friday, March 10, 2017

I’ve Been Doing Plugin Parameters Wrong For 7 Years

TLDR: Use request/response classes to get typed parameters in your plugins, and share your knowledge!

I’ve been an active Stack Overflow (SO) user for about 7 years now.  There are 3 ways to increase your knowledge from SO.
  1. Being able to ask a question and get an answer in hours.  It’s not always the correct, or the answer you want, but more often than not, it is a great way to increase your knowledge.  This though, is not the primary conduit to increasing your knowledge, that privilege belongs to way #2.
  2. Finding the answers to the questions that have already been asked, and instantaneously getting the knowledge you want (sometimes by the former, “smarter” you).  This is by far the most common method of learning on SO.  It also brings up a new not quite as beneficial coding paradigms (Stack-Overflow-Copy-and-Paste-Yourself-to-Victory).  If this second option is the bread and butter of learning for developers today, then third option is the dessert, the unexpected delightfulness that makes the SO community a great place to contribute to, and learn from.
  3. Providing an answer to a question that you believe to be 100% correct, but then having someone else respond with an even better/more awesome/even more “correcter” answer, to which you tweet about, and then someone else responds with an even better/more awesome/even more “correcter”/more ludicrous answer.  This third option is the subject of today’s post.
Here is how this particular instance of #3 went down…

  • I posted an answer to a SO question about plugin parameters almost 6 months ago (Feel free to refer to the SO question mentioned here: How to know what InputParameters values are possible in Dynamics CRM Plugin context?).  
  • Then Federico Jousset commented on my answer with a helper web page that he has created that is a better tool, IMHO, to answer the OP’s question.  
  • I then tweeted about it (since this knowledge should be shared among the global Dynamics 365 community).
  • Martin Tange responded with a blog post (which I’m assuming he wrote in direct response to my tweet) that brought to light how I’ve been doing plugin parameters wrong since day one.
  • And now you're here learning about it as well!

The MSDN documented approach to accessing parameters is to use “magic” strings and assumed casting
// The InputParameters collection contains all the data passed in the message request.
if (context.InputParameters.Contains("Target") && context.InputParameters["Target"] is EntityReference)
    // Obtain the target entity from the input parameters.
    EntityReference entity = (EntityReference)context.InputParameters["Target"];
Martin’s technique is so simple, I can't believe I haven't seen it used before:
var createReq = new CreateRequest { Parameters = context.InputParameters };
createReq.Target; // Is typed as Entity vs EntityReference (DeleteRequest)
To which I’ve wrapped in an extension method to help remove some additional key strokes (which I’ve added to the DLaB.Xrm.Plugin namespace):
/// <summary>
/// Populates a local version of the request using the parameters from the context.  This exposes (most of) the parameters of that particular request
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="context">The context.</param>
/// <returns></returns>
public static T GetRequestParameters<T>(this IPluginExecutionContext context) where T: OrganizationRequest
    var request = Activator.CreateInstance<T>();
    request.Parameters = context.InputParameters;
    return request;
/// <summary>
/// Populates a local version of the response using the parameters from the context.  This exposes (most of) the parameters of that particular response
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="context">The context.</param>
/// <returns></returns>
public static T GetResponseParameters<T>(this IPluginExecutionContext context) where T : OrganizationResponse
    var response = Activator.CreateInstance<T>();
    response.Results = context.OutputParameters;
    return response;
So now, this is even shorter:
var parameters = context.GetRequestParameters<CreateRequest>();
So my challenge to you dear reader, get involved in your community.  You may never know when an attempt to share your knowledge with someone else, ends up unexpectedly resulting in others sharing their knowledge with you!