Share
ReportI've seen several videos and read blogs debating the purpose of actions and how to use them. For you who never seen them or not knowing what I'm talking about is the extra choice when you go to settings->processes and press new, instead of selecting Business process or workflow you select Action.
Inside you will see that it looks very similar as workflow. But with a few exceptions. First, Actions can only run synchronous. It can take input parameters and return several values. It has similar activation features as a workflow and name.
One of reason it took me so long time to find actions was simply because I could not see were in the system I can run them. In later version they can be activated through workflows. But the interesting part is not this. The interesting part is that they can run from a JavaScript file, custom workflow activity or stand alone application which can connect to the CRM server. You simple call the action by its name, which you can set by your self, with input parameters. Compared to running an on-demand workflow by referring to its id or do an extra lookup.
So, to the question and my idea that I would like to get your thoughts on. If I use actions then I can hide parts of the CRM internal data model. The input and output parameters simple acts as an API for this specific service/action. Just as workflows actions keeps a log for failed and successful runs (depending on settings). Which will save you a lot of time when the day comes that there is a bug. Depending on your type of business logic it can be simpler to implement and maintain it in actions steps compared to do it in code in a JavaScript or C#. You also have the possibility from the server to activate it and deactivate it. Don't forget that it runs in a single transaction.
A couple of cases where I found this useful
1) A custom made web platform which was used to create opportunities and drive the sales process. I could move big parts of the business logic which was placed in the custom platform to CRM hence make a more loosely coupled architecture. Simplified testing and enable other application to connect to same business logic.
2) Integration, use action instead of going directly on record. This simplified testing mapping and any business logic used in integration. Possibility to turn it off to ensure nothing deprecated is running (should be a minor benefit if you have your system documentation in place). Also if you have ever created an extra field on a record only to use its values to select which workflow run on it. Here you can have that field as input parameter and not dirt the entity.
3) Web resources / JavaScript. Free logging, Transactional safe. Can be used both for front end and back end logic, an example, special calculations which cannot be done by calculated fields and should be shown both in form and for imported or Web API modifications.
Cons with it is of course the additional performance impact by moving all to server side and is run in a transaction. The additional complexity added by wrapping the platform in one more layer.
What is your thoughts? Both pros and cons are welcomed
*This post is locked for comments
All responses (
Answers (
292,516
