I have a question about the use of 'Stop Workflow' with status of Success. Can anyone explain (with evidence) why it should be used at the end of a workflow? I cannot find any blog posts, or documentation that explains why so many people are being told to put it at the end of every workflow. So far, everyone I have asked just shrugs and says "I was told to do that" and I feel it is not a best practice.
I can (sort of) understand using it in the middle of a workflow, for example if the person is not a programmer and cannot understand IF logic more than 1 level deep and therefore they are taught to use it to prevent unexpected things to happen. But I cannot understand why people are being trained to put it at the end of every workflow.
Stop Workflow step makes Dynamics 365 behave differently on real-time workflow compared to background workflow. While the workflow design is exactly the same in both scenarios, real-time workflows rolls back the transaction, if workflow is stopped with status Canceled. This is due to the fact that real-time workflows behaves same as a post-operation plugin which if failed rolls back the complete transaction.
Since the background workflow runs outside of the main transaction, it executes each step independently and when workflow is stopped with Canceled status, complete transaction is not rolled back.
NelsonYes, there seems to be no benefit to mark workflows with Succeed(especially with self destruct workflows).
But in situations where keeping a workflow log for audits is required, it may be needed. One could argue that a successful run status is enough to indicate that it succeeded, but how do you know for sure? What if one of those steps just decided to quit for some unknown reason?Ex:If (GoToFunctionThatReturnsTrue(SomeParameter))elseCanceledNow one can "assume" (and we know what that word stands for :) ) that if it doesn't return cancel then it succeeded, but we all know that is not true.
In this case we KNOW for sure that the function worked and returned a true value because Succeeded was returned.
So basically you are sacrificing certainty if you don't return a Succeeded value. This can be VERY PAINFUL during audits.It's the same argument in the SQL realm, is a null bit field false? We know common sense would say, well if it's not checked then it's false. But SQL developers know that is not the case.
If you've found this thread useful, dive deeper into User Group community content by role