I ran into such an issue this week and boy it was painful. The workflow in question while working fine required changes that an action would a natural fit for (mainly passing params into it and getting a meaningful return value). The prospect of recreating the Workflow was daunting, 22 steps, 6 record creations, 4 record updates and various conditions. To make matters worse many of the fields in the create or update steps had subsequently been changed to disabled. To re-implement the workflow as an action I would need to change the disabled fields to enabled, create the action and make sure I hadn’t made any mistakes along the way. It’s not a terribly difficult task, just takes a long time to do and is frankly mind-numbing. If only Microsoft had a Save As button for processes to Save As Action, Save As Workflow etc.
After a Skype chat with the CRM go to guy George Doubinski being told no can’t do it or to wrap the Workflow in and Action, I thought maybe a bit of solution.zip hackery would work and to my pleasant surprise it did!
It has been a serious time saver for me as some of the workflows would have easily taken a day to convert to an action. Now it’s possible to get through the whole process end to end in about 30 mins.
I’m impatient and a CRM gun, just give me steps dude
Ok before we go there, this solution is still quite raw and I sure some will have problems, but I have used it to convert about 5 quite complex workflows to actions, you may need to do some troubleshooting (I’ll cover this at the end) but if you follow the broad steps you should be on your way:
- It’s best to start with a Realtime workflow then you don’t need to worry about wait conditions that are not supported by actions. Converting a background to workflow is quite easy, just deactivate and “convert to realtime workflow”
- Make sure you are working in a dev environment, backup solutions (and preferably the organization database just in case, here be dragons)
- Create a temp solution (let’s call it: Workflow To Action Conversion)
- Add the existing Workflow that you want to convert to an action into this solution (eg: Generate Sales Metrics)
- Create an empty action in the temp solution (eg: Generate Sales Metrics Action)
- Export the solution (WorkflowToActionConversion.zip)
- Extract WorkflowToActionConversion.zip and browse to Workflow folder
- If everything has gone to plan you should have two files in here that correspond the workflow and the empty action. Open both *.xaml files into a tabbed editor (I like Notepad++)
- In the Action*.xaml file search for: <mva:VisualBasic.Settings>Assembly references and imported namespaces for internal implementation</mva:VisualBasic.Settings>
Select this line and everything below it and delete (yes delete)
- In the Workflow*.xaml file search for: <mva:VisualBasic.Settings>Assembly references and imported namespaces for internal implementation</mva:VisualBasic.Settings>
Select this line and everything below it, copy to clipboard and paste into the Action*.xaml file (replacing what you deleted in step 8. Save the Action*.xaml file.
- Inject the Action*.xaml file back into the WorkflowToActionConversion.zip
- Import the WorkflowToActionConversion.zip
- Bask in your awesomeness
So to summarize, we created a solution including the existing workflow and created an empty action. Export the solution and replace the contents of the action with the contents of the workflow, re-import the solution and done!
OK so what’s the catch (troubleshooting)
I have run into some glitches with this process (I’ll keep adding to this section as find more).
The Workflow was calling an action that previously had required parameters and now they are optional (failed on re-import)
In this scenario the workflow I was trying to convert to and action (Generate Sales Metrics) was calling an action (Update Sales Targets), previously when the workflow was first built the action had 3 input params and of the 3, 2 were required and 1 was optional. Over time the Actions behavior was changed to all 3 being optional and the logic inside the action that worked out what it needed to do with the 3 input params. What this meant it when the contents of the workflow were copied into the Actions 2 params were marked in the metadata as required when they were all optional, this caused the re-import to fail. I can only assume the original workflow still keeps working as it may be versioned against the earlier version of the action. Weird! Solution followed my nose and as I had already been converting importing simpler workflows I suspected something was up with the Process Action step. Experimented by removing that step and retrying, the import worked. At that point, I knew the issue was with Action. Re-added the Process Action to the original workflow tried the steps again and it worked!
Huh? Because the second time around the all 3 params are optional. When I compared the XAMLs of the two workflows and noticed the earlier version had tags for required params and the latest one didn’t.
Check the first line XAML files closely
The first line of the XAML file will contain the “imports” for the workflow or action, compare both and make sure they are broadly the same. I have noticed that if I’m converting a workflow with conditions, in my empty Action I need to a similar condition in the Action first, eg something like: If Account Name = Test then.
Below is a: Workflow, Action that is compatible (added the condition first), and completely empty (won’t reimport)
Update: 2017-03-15, I came across another scenario where a workflow was calling an action (process action). This step adds some declares to the top of the XAML file. In this case same trick, just add a process action step to the empty action, save and continue to step 5.
Action (will reimport)
Action (won’t reimport)