In essence, they are a custom message, something like Create, Update, etc... but the actions that take place when the custom message is invoked are defined as a sort of Workflow, which allows custom code via Custom Workflow activities.
It then it gets a bit weird in that this can only be invoked via code. A potential workaround is to use a workflows with a custom Workflow activity or presumably, JavaScript hooked up to a button or other event.
I thought I would try to create a sample action. The action will create a task related to a Stamp (a custom entity), which is a mandatory input to the request. There is another non-mandatory input variable, if set to false, the action will not trigger. Finally, there will be an output variable, which will effectively confirm whether it's been actioned ...
At any rate, this is how one would create such an action. Navigate to Settings -> Processes -> New
I created this action to be global, it can be limited to an entity.
I added a few arguments and there are a few things that are annoying about this. The first one is that unless the Entity Type is set for Entity or EntityReference, you will not be able to use the argument, at least not from the GUI, so this limits a bit what can be done. Although I suspect no such limitations apply to code ... The second annoying thing is best explained by the next screenshot:Essentially, 0 will be false, everything else is True, if the field is boolean, not sure why not just have True or False?
Make sure that the action is activated before calling it from code.
This is how you would call it:
private static void supadupaaction(IOrganizationService service, EntityReference target, Entity stamp, bool carryOut=true) { var parameters = new ParameterCollection(); parameters.Add(new KeyValuePair<string, object>("Target", target)); parameters.Add(new KeyValuePair<string, object>("RealTarget", stamp)); parameters.Add(new KeyValuePair<string, object>("AreYouSure", carryOut)); OrganizationRequest request = new OrganizationRequest() { RequestName = "new_SupaDupaAction", Parameters = parameters }; var result = (OrganizationResponse)service.Execute(request); foreach (var item in result.Results) { Console.WriteLine("Result - Name: {0}. Value: {1}", item.Key, item.Value); } }
Target is an entity reference to the, yep, target entity, i.e. the entity against which the action/custom message is running. Stamp is the instance of the Stamp entity against which the task will be created.
Note that the RequestName is not all lower case, not sure if this is only for actions or a more generic shift in MS Dynamics CRM 2013 in general.
Frankly, I need to think what the benefit of this is/can be, because with this noddy example I am seeing none. I guess defining a type of operation can be quite handy as stuff can happen pre and post operation, e.g. register plug-ins to do this, so nothing ground breaking but perhaps simplifies things ...
Note that the RequestName is not all lower case, not sure if this is only for actions or a more generic shift in MS Dynamics CRM 2013 in general.
Frankly, I need to think what the benefit of this is/can be, because with this noddy example I am seeing none. I guess defining a type of operation can be quite handy as stuff can happen pre and post operation, e.g. register plug-ins to do this, so nothing ground breaking but perhaps simplifies things ...
Feel free to enlighten me...
Hola - at the end of the day, it's all to do with empowering the user. Say you have a business process which requires a series of activities to be created Instead of the activity description being hardcoded, you give the user the ability to manage that and to be able to add/remove activities as they see fit.
ReplyDeleteAlso, it gives you maximum flexible in terms of how it's triggered (workflow, client / server side etc). Actions act as a central point to allow you to do that.
Enlightened?