At the end of my Seeking Approval article, I promised one on handling the rejection path of an approval. I was thinking that I would go into detail on how to use a rollback activity and the pitfalls you might encounter with them. But after reading the existing wiki docs on the subject, I don't think that's really necessary. There is already some really good documentation on this topic.
- Approval and Rollback Activities - ServiceNow Wiki
- Selecting a Rollback Activity - ServiceNow Wiki
- Designing Workflows with Rollback To - ServiceNow Wiki
- ServiceNow KB: Workflow: Roll back approvals (KB0538562)
If you clicked through those links, your head may be about to explode, because they are loaded with information. As I read those articles, it occurred to me that instead of instead of duplicating them, I should try to create a quick introduction on the basics of rollback, and how the activities work, so that when you do read those docs, you're a little more prepared and hopefully they make more sense.
What's a rollback?
The idea behind rollback is that sometimes a workflow needs a do-over on a section. Frequently this is because of an approval being rejected, but really, any situation where a workflow needs to a chance to recover and get back on track may use a rollback.
Hopefully this is obvious, but a rollback is not fairy dust that can magically un-send emails, un-run destructive scripts, and restart production servers that your Orchestration workflow has shut down. Rolling back is a process that is intended to work with Approvals and Tasks. Rolling back an approval or task activity will reset the records associated with those activities so that the workflow can execute those activities again. With other types of activities, the rollback will cancel them if they are still executing, otherwise it doesn't do anything. Undoing the work of those other activities is the responsibility of the workflow author.
Rollback vs Rollback To
Prior to Eureka, Workflow offered two flavors of "rollback" activity. Rollback and Rollback To. They both do the same work when rolling back a specific activity, namely resetting approval and task activities. The interesting difference between them is in how they determine what activities will be rolled back.
Rollback
The legacy Rollback activity was based on execution order, it would roll back all activities that executed between itself and the activity it transitions to. Here's what I mean:
When this flow starts, its going to run Create Task Activity 'A' and Create Task Activity 'B'. Let's assume that Task A gets completed and the resulting Approval User - 'C' gets rejected. The workflow now hits the Rollback activity, which transitions back to Create Task 'A'. At this point the execution order of activities in the flow looks like this:
The Rollback activity will rollback everything in that execution order between itself (D) and its transition target (A). In this case, A, B, and C get rolled back.
There are 2 problems with that, the first being that the Create Task 'B' gets rolled back. A case can definitely be made for that being unexpected behavior. Create Task 'B' is on a separate branch, so Rollback D affecting it surprises a lot of people. It also makes authoring flows using rollback more difficult. See the wiki articles for more details.
The second problem here is more subtle. Look at the two Create Task activities again. They have no guarantee of execution order. Its just as likely that the execution order could be:
With this second, equally valid, execution order, Create Task 'B' will not get rolled back, because it is not between A and D in the execution order. Same workflow design, different behavior. That's not ideal, and its why we added the Rollback To activity in the Aspen release.
RollbackTo
Rollback To is much more deterministic. It rolls back activities that are on the transition path between itself and the activity it transitions to. In other words, Rollback To is based on how you've drawn the workflow, not how the engine executes the workflow. In workflow above, imagine we swap the Rollback activity out and put in a Rollback To. The flow still has the same two potential execution orders (ABCD or BACD). However, with either of the them, the transition path between our Rollback To and Create Task 'A' is:
As part of a separate branch, Create Task 'B' is never involved in that path and doesn't get rolled back.
So that's the fundamental difference between Rollback and Rollback To. There are a couple other differences:
- Rollback only works in workflows running on tables derived from Task - Rollback To is available to any workflow.
- Rollback is deprecated as of Eureka. - I probably could have mentioned this earlier in the article and saved you a lot of reading. But there are still a lot of workflows out there that use the Rollback activity, so I thought it would useful to explain the difference between the two activities. If you do have a workflow that is currently using Rollback, there's no need to panic. The activity will continue to work. We aren't taking out runtime support for it, we just disabled the ability to add it into new workflows.
See the Wiki
As I said at the top of this post, the wiki has excellent documentation on the Rollback activities, including an article that shows some recommended authoring patterns for workflows with rollbacks. If you're working on a complex approval scenario, they are definitely worth reading. Hopefully, after reading this, you'll get a little more out of them.
4 Comments
