Fault Scope Activity

The Fault Scope activity is used to contain activities in a subprocess that are likely to raise errors. If a fault is somewhat predictable, the Fault Scope activity can invoke preset resolutions that deal with the fault and permit the workflow to continue at the point immediately following the scope.

The benefit of fault scopes is that they have built-in resolutions to these failures. Scopes have fault handlers that deal with these issues so that the workflow instance can resume after the scope runs if an error occurs. So, if the fault is handled, the workflow continues at the point immediately following the scope. There can be many levels of scopes, which are nested in the subprocess.

The fault scope activity allows a series of activities to be contained in the scope. If a failure during a workflow instance is predictable, you can add a fault handler that is associated with the fault to resolve these circumstances. For example, if you can predict that a new process designed on a production floor may fail some of the time, a special set of fault handlers can be assigned to this scope to deal with the failure.

The fault scope activity is also associated with fault handlers as they pertain to level promotion. Within a fault scope, there are a series of fault handlers at various levels to try and catch any error or failure that is occurring. The fault scope searches for handlers to run. If the scope cannot find a handler to deal with the fault (that is, if no resolution to this fault is found), the fault is promoted to the next level of fault scope where it could possibly be handled by its fault handlers. The next level could be another fault scope activity (if the scope is nested), or upwards to the subprocess/step itself. The same sequence of events happens until there are no further levels to promote to. If there are no more levels (that is, the fault reaches the workflow level), the workflow stops and an error is logged.
Note: You cannot configure a fault scope at the workflow level.