CRM Actions - the mysterious erroneous prefix

Actions were introduced in CRM 2013 and are a very powerful feature of Dynamics CRM. Quite frequently you might have had a particular piece of custom code you wanted to make available in different areas within your code base, such as both JavaScript and plugins. Previously you could not easily encapsulate this code without writing something quite custom and quite frankly a little hacky. For an example of how you could previously achieve this see my blog post about Executing stand alone C# code within crm.

Actions have made this redundant as you can now very easily encapsulate a common piece of functionality that you can call in many different ways and places (See MSDN)

So that's all sweet and awesome, right?

Not quite. As with all new features of CRM you eventually weed out a few bugs, some a little more complex than others. And actions are unfortunately no different. Recently we ran into a mysterious issue on our dev organisation in that it started throwing errors any time we tried to execute an action. The issue did not surface on any of our other environments. On closer inspection I read the error message a little more closely and spotted something

 Request not supported: new_CustomActionName

...Hang on there a second tiger, "new_" is not our default prefix! Where did this suddenly come from?

One thing dawned on us. We had recently recreated our dev from scratch due to some issues with the environment. One of the particular tasks we performed before we reset it was take a backup of the default solution. This was then imported directly after the reset to get us back to base. It all looked hunky dory until we noticed that actions had been impacted by this; they mysteriously got imported with the "new" prefix instead of honouring what our original default prefix was.

The fix?

Luckily this issue had not yet infected our test environment. And doubly luckily the actions hadn't changed since we reset the environment. That meant we could delete the actions on dev, create a fresh solution on our test environment with the (still correct) actions in it, and import this back into dev

I would hazard a guess that if we had changed the default prefix before we imported the backed up default solution we may have avoided the problem. But now I will never know! To be completely safe my advice is to back up all actions in a solution with the correct publisher before you embark on a environment reset under which you intend to restore a default solution.