Cancellation Regions

Consider the following scenario:

  • at each point of time the user may decide to cancel the order
  • this is very difficult to express with plain Workflow Nets
  • therefore in YAWL there is a special syntactic construction for that


  • at the beginning we have the following
  • yawl-cr-motiv1.png
  • now we need to be able to cancel the task at the bottom:
  • we add a special cancel task for this that takes the token and puts it directly to the final place
  • yawl-cr-motiv2.png
  • then we add more such cancel tasks
  • yawl-cr-motiv3.png
  • so it quickly becomes cluttered and unreadable


A cancellation region consists of

  • a number of tasks and places
  • transitions between tasks - recall that in YAWL they contain "hidden" places
  • the cancellation task


  • upon completion of the cancellation task all tokens in the cancellation region are removed
  • so it guarantees the proper completion property:
  • it makes sure the unneeded tokes are removed and no other activity within the Cancellation Region is performed


  • yawl-cr-syntax.png
  • if there was something in the cancellation region when the cancellation task was activated
  • it will be removed

Usage Pattern

Typical Pattern of Usage:

  • yawl-cr-pattern.png
  • there's a cancellation place before the cancellation task
  • when the job inside the cancellation region is done, close case takes a token away from this place
  • so the cancel task is no longer active
  • but if the cancel task fires, it takes the token from the cancellation regions and finishes the case

Workflow Soundness

In Workflow Nets unboundness always means unsoundness

  • but with cancellation regions it's no longer the case
  • yawl-cr-unboundness.png
  • but Reachability Graph can no longer be used to decide on soundness: it's infinitely large now
  • for that we use Coverability Graph



  • a flight, hotel and car can be booked in parallel.
  • if booking of all three succeeds the payment follows.
  • otherwise task cancel is executed
  • cancel is delayed until all three bookings succeed/fail
  • if something is already booked, nothing is reverted: it remains booked

We model it the following way:

  • each option can either fail of succeed, therefore for each we have two possible output places
  • the waiting is modeled with OR-Join which, because of its Bus-Driver semantics, will wait for all possible tokens to come: we connect it with all fail places
  • the OR-join is the cancellation task that will put the tokens out of succeeded places on activation
  • if we used XOR-join instead of OR-join, then it would fire once there's at least one token in any of the failed places
  • yawl-cr-booking-1.png

Consider a slightly different scenario:

  • cancel is not delayed until everything fails/succeeds
  • if there are booking tasks that have not started yet, they are canceled as well

The model above is changed a little bit:

  • now we use XOR-join: one there's a token, it fires
  • and the cancellation region is expanded to include everything after the AND-split
  • yawl-cr-booking-2.png

Note that in this case the cancel task is itself a part of the cancellation region

  • it's to ensure that all tokens are removed and cancel can never fire twice

Assume it wasn't the part of the CR

  • yawl-cr-booking-3-nocr.png
  • suppose booking of hotel and car failed
    • yawl-cr-booking-3-2tok.png
    • if one is fired first, then this will remove the remaining token
    • but what if both tokens are already allocated and now are in the cancel task:
    • yawl-cr-booking-3-2tok2.png
    • it processes one token and outputs it
    • yawl-cr-booking-3-2tok3.png
    • but now it can fire the second time!