Friday, March 6, 2015

Stop workflow with a status of Succeeded, not Canceled

I learned a valuable lesson when working with a workflow recently. There is a difference between Stop workflow with status of: Succeeded and Stop workflow with status of: Canceled. (scroll to the final paragraph if you just want a sentence-long description of each status)



Based on what I had seen elsewhere, the difference in these two workflow statuses was in name only.

In my scenario, I have a workflow set up to create some cases at the creation of an opportunity (or when certain fields change), unless the user who created the opportunity is a particular user. I thought by selecting a status of canceled, I would be able to easily distinguish between instances where the workflow went through all of the steps and instances where the workflow stopped itself on the first step. However, I had a misunderstanding of what changing the status of canceled would do.


Setting the status as canceled was causing business process errors when this users was trying to create opportunities, and it was causing errors for a plug in that we have installed. Changing the workflow to a status of canceled not only stopped the workflow, but it also stopped the event that triggered the workflow. For me, this was unintended behavior.
Essentially, using the status of canceled is a way to cause an error that can be tracked when a certain condition is met. Using the status of completed will stop the workflow from moving any further, but will not prohibit the event that triggered the workflow in the first place.

2 comments:

  1. Hi
    If you would have used Async Workflow not real time then this won't have been an issue.

    ReplyDelete
    Replies
    1. Thanks, Kanta. I meant to mention that I realized that by using an asynchronous workflow, this wouldn't have been an issue. For the needs of this particular job, it functions in a more user friendly way as a real-time workflow.

      Delete