Entity and EntityCollection as output parameters in Dynamics 365 action – return your custom class objects too

Follow my blog for more interesting topics on Dynamics 365, Portals and Power Platform. For training and consulting, write to us at info@xrmforyou.com
One of the great features that got introduced with Dynamics 2013 was Actions. With time more & more improvement came in with Actions and today Actions are one of the most powerful extending features in Dynamics.
And here I was designing actions for a client. Coming quickly to the requirement, the client had an action where they were determining complex business logic in the action with some input parameters and then based on the calculation, they need to pass back multiple values back to the invoker of the action.
There can be multiple ways to do this and one can be pass each of these values of Output Parameters. But that did not go well with the customer as around 15 properties needed to be returned from the action.
So the client developer came up with a DataModel class something similar to this.

internal class OutputClass
{
public string Property1{get;set;}
:
:
:
public decimal Property15{get;set;}
}

Nothing fancy. all the developer was doing was mapping the properties of this class and then return an object of this class to the invoking action. But how to do it? Does Action allow custom object types to be passed as return parameters. Well,direct answer is No. But where there is will there is way. Let’s see couple of ways here.

• serialize the object into JSON and put the output JSON string through a string Output parameter – Didn’t go well with the customer. Had to abandon
• serialize the object into XML and put the output XML string through a string Output parameter – Didn’t go well with the customer. Had to abandon again.

What I am left with then? We all know that actions support entity and entitycollection as output parameter types. But how do I use them to accomplish my goal here. The customer is not willing to create any Entity specifically for this.
Well a bit of struggle and finally I achieved the below as workaround.
1. Passing a single Object back.
Well for this I used the entity parameter and just selected the Account Entity as Entity Type. You can use any Entity here. Does not matter.

In the plugin registered on the Action step, I am setting the Output parameter like this.

var ent = new Entity("account");
ent["mytestproperty"] = "Test Name";
ent["mytestproperty2"] = 1;
ent["myentityreference"] = new EntityReference("contact", Guid.NewGuid());
context.OutputParameters["EntityParam"] = ent;

Observe carefully the code above. I am just creating an entity at runtime of type “account”. I don’t even need to specify the Guid. And then I can just put my custom property names for the entity and assign values of entity type – string/ int/ decimal/ entityreference etc.
None of these properties are present in the account entity. The trick is CRM framework does not validate the fields of the entity. So you can just return the entity object back with your own parameters. Cool trick. Isn’t it.
And below is the output received by the invoker of the action.

2. Passing Multiple Objects of Different type
For this, I used the entity collection as Output parameter

And below is the code to set the values.
var ent = new Entity(“account”);
ent[“mytestproperty”] = “Test Name”;
ent[“mytestproperty2”] = 1;
ent[“myentityreference”] = new EntityReference(“contact”, Guid.Empty);
           var ent2 = new Entity(“contact”);
ent2[“mytestproperty”] = “Test Name”;
ent2[“mytestproperty2”] = 1;
ent2[“myentityreference”] = new EntityReference(“contact”, Guid.Empty);
           collection.Entities.Add(ent);
collection.Entities.Add(ent2);
           context.OutputParameters[“CollectionParam”] = collection;

First we have to understand that entitycollection is a collection of entities. It does not necessarily imply collection of entities of the same type. This is a common misconception I find among so many experienced consultants.
As you can see, both the entities are of different types and can have completely different properties. Cool isn’t it?
And below is the output result of the action.

Personally if you ask me, I would still prefer serializing the object into JSON or XML. However if your customer prefers Entity or EntityCollection, this workaround I hope helps you.
Debajit Dutta
(Dynamics MVP)
For corporate training/ consulting/ tools, please visit our website www.xrmforyou.com or write to us at info@xrmforyou.com