This concept has been a common discussion point with customers. Ultmately the customers have said that they wanted a 'Rollback option" for when a workflow fails they've also agreed that it is better to STOP and identify what went wrong, and to not automatically rollback. Also, some workflows will not be possible to 'rollback'. Think decommissioning in this instance. if some volumes are offlined and destroyed as part of a 'Decommissioning' workflow... then it will not be possible to "rollback" those actions. Once the volumes are gone... then they're gone. Another workflow would have to be run to recreate them.
The current method for "Rollback" is to have a specific "Decommission" or "DeProvisioning" workflow that can remove the objects that are created as part of a workflow. The "Decommissioning" workflow would look to see if the volume, qtree, vFiler, aggregate... whatever exists in the environment and would offline/destroy, remove that object if it exists... or skip it if it doesn't exist (workflow doesn't "find" it). Yes, this would require another workflow to be created, but it would put control into the customer's hands for if it would be necessary to remove compnents created by a particular workflow.
Conversly, there have also been discussions for having a "Restart Workflow". This is where a workflow could be restarted where it failed, if necessary. Think of a workflow failing for an out of space condition or a possible socket error where some options on the storage controller weren't configured properly. Once the issues were corrected, then the wokflow could be restarted where it failed. A "Restart Workflow" feature is being planned for a future WFA release.
If everyone viewing this discussion can go and vote either for or against the idea (http://communities.netapp.com/ideas/1094) we can have a better understanding for IF this is a priority and should be focused on for one of the upcomming releases.
I voted up. I like the idea of WFA generating a workflow that contains the commands to roll-back what was done so-far - but not automatically executing it. That way, its up to the workflow administrator to determine if he/she wants to execute that "rollback" wokflow. If they don't, they can just ignore or delete that "rollback" workflow.
Definitely a nice-to-have feature, but I'm not sure its a must-have feature.