Actions are a type of process within Dynamics CRM/365 that you may or may not have already heard of. They are not as well known as workflows and are viewed as an internal operation rather than something that can be configurable. This mindset could be because we are so used to creating workflows, dialogs, or even plugins that have a starting or ‘trigger’ point, and are so caught up making business logic for those that we forget we can create a component that is in fact, reusable across all of these types of customisation and only have to make it once.
An action in Dynamics is best described really, as its name, if you think of it like a literal action. It can take an input, it does something and then there might be an output. For example, the action of running – how would you describe the action itself? Its the action of putting one foot in front of the other and moving at speed. Thats an action just like in Dynamics. The input could be you set the time for how long your going to go running, or what leg weights your going to use, but the action is still the same. You also may not have an output, or the inputs could determine the outputs – for example, your going to burn more calories with a heavier leg weight.
One of the biggest differentiation of actions from other processes within Dynamics is the fact it is void of a trigger – you don’t set one because what you are configuring is a modular piece of functionality designed to be applicable in different applications or processes. You use an Action in a workflow, a custom workflow, a dialog, or in a piece of code (such as a plugin).
When you design an action, you will probably be designing it to be used in one or more places, but its important you abstract away from the trigger point, and think about if you want the action itself to be configurable for, what the internal logic does, and if you require any output. Go back to our scenario about running – we have not talked about why someone has chosen to go running have we? The trigger point for the action to happen? It could be because they have just eaten a really big meal earlier in the day and want to burn it off, it could be because its part of their daily routine at 6am every single day, it could be because they are training to run a marathon and a personal trainer has set them a schedule. Think about these scenarios just like your business requirements, and having one action called ‘Running’ would be able to be utilised using multiple different triggers.
Input parameters are simply arguments which the action uses in some way, and output parameters are something which the action returns. Lets take a different scenario involving cakes. You have ingredients as an input parameter e.g. butter and flour, the process is the mixing of the cake, and the output is the cake itself. An input parameter could be how long you wish to cook the cake, which then has a direct influence on the output parameter e.g a burnt cake. This is often the case with output parameters but not always – it completely depends on how the internal ‘stuff’ of the action is written and how much of an influence it has.
The next logical step is to deconstruct an action you are likely to be familiar with, or can get familiar with very quickly, from the standard functionality of Dynamics, which is the ResolveIncident action.
When you go into Dynamics and resolve a Case record, you get a window pop up which looks like the below. It prompts the user to input some key information necessary to be able to resolve the case. This information is stored on the Case Resolution entity which is created as part of this process against the Case.
The fields to be completed are the Resolution Type, which is an optionset, Resolution, a text, Billable Time which is a number and Remarks which is also in text. Total time is on there but you’ll notice this is read only, as its calculated from the duration of the related activities set against the case and cannot be changed.
Now, lets take a look at it from another point of view – the point of view from the configuration of the input parameters for the action. I’ve created a workflow and added a step to use the action ‘ResolveIncident’ – you will notice it has a red error next to the step because there are unsolved items within the properties I need to configure.
Opening up the properties of the action via ‘Set Properties’, you can see in the screenshot below the input properties that contain the exact same fields I see on the form of the Resolve Case window, except you can now see the setup of the data type, if they are mandatory and also if i was to use this action in my own process – I could actually input dynamic values (or manual) values into the properties here and it would create a Case Resolution record and attach it to my Case. (This action is only applicable to cases)
So now we have familarised ourselves with what actions are – the next step is to utilise an action in a process. A popular customisation is to create a ‘Quick Resolve’ button or functionality on the case because users don’t want to be completing the dialog window as its extra effort the business wish to minimise. With Dynamics 365, you can now use these standard out of the box actions in workflows where you previously couldn’t (and had to create your own functionality to mimic it) – so thats a bonus – this means this will take even less time.
I’m going to minimise the time even further now and use the Ribbon Workbench to complete these customisations, and use a new feature (currently in beta, soon to be released) called Smart Buttons. I’m going to use a pre-made Smart Button called ‘Run Workflow’ and use it to call my workflow. Normally, i’d have to create the button myself and add all of the properties and workflow ID to it, but Smart Buttons saves me all of this effort. (You can create your own Smart Buttons to perform pre-made templates functionality for tools/your business).
So all I have to do to create this functionality is:
The workflow we want to run is a real time workflow as we want the action to happen immediately and not wait, but we need to make it accessible to be called manually (as from a button press, it is technically the same as a user clicking ‘Run Workflow’ for manual workflows) – Make a workflow for the Case entity and set the scope as required.
Click ‘Add Step’ and click ‘Perform Action’
You’ll notice the red cross because the input properties need to be set. Click ‘Set Properties’ and add in the properties you wish to close the case automatically with. In your process – you could be getting the data from the form to make it dynamic, but for the purpose of this demo, I’ve manually added most of the form values (which has its risks so be careful if doing this in production).
Save and Activate your workflow.
Make sure you have the latest version of the Ribbon Workbench downloaded, and you also have the Smart Buttons solution file to utilise Smart Buttons. Here and Here.
Make sure you have created a solution which only contains the entity (Case (incident) in this example) you wish to customise to optimise loading and publishing times of the ribbon.
Open the Ribbon Workbench and load your solution with the Case entity
Smart Buttons within the Toolbox of Ribbon Workbench
Input to be completed for the ‘Run Workflow’ Smart Button
Click ‘OK’ and your new button will have been created on your form with all the commands automatically for you!
When ready, publish your solution.
Now, lets test the solution and see it in action!
Navigating to an open Case record, we can see the new Quick Resolve button we just created.
Clicking it we get our confirmation straight away.
You can see the Case now has the status Resolved at the bottom, but also the Case Resolution activity has been created with our values as per the workflow.
I hope this post has given you more information on what Actions are, how you can utilise the standard out of the box Actions and also, how you can use the new Smart Buttons feature within the Ribbon Workbench to rapidly decrease your customisation time!