Task Editor Compensation Tab

The Task editor Compensation tab appears for manual, automated, and transformation task types.

Use the Compensation tab to define your compensation strategy for manual and automated tasks.

Note:

Although compensation strategies are defined on an individual task basis, they must be analyzed within the context of the workflow.

Field Use

When this task needs to be re-evaluated, compensate by:

A task is re-evaluated by the system if it has visibility to order data (data that is defined as significant) that has changed as a result of an order amendment or as a result of amendment compensation performed on another task to which the task has visibility. The default option, which is to redo the task, applies to tasks that are linear in nature and have the same completion status (no branching).

Select Redo (one single operation) to instruct the system to perform Undo and Do operations in a single operation. This option is recommended, when possible, as it performs the fewest number of Undo and Do operations necessary for compensation.

Select Undo then do (two separate operations) to undo this task and all successor tasks and roll back all order changes, then perform the Do operation again. Use this option to rollback all order changes and re-perform the task from the beginning.

Select Do Nothing to instruct the system to bypass updating the affected task. For example, you might select this option if a similar task downstream in the process will be compensated, thereby optimizing the compensation plan.

Select Compensation Expression to create an XQuery expression in the Compensation Expression field that dynamically selects a compensation strategy (Redo, Undo then do, or Do nothing) based on revision order data. See "Compensation XQuery Expressions" for more information about compensation strategy XQuery expressions.

When this task is no longer required, compensate by:

A task or subprocess is no longer required when:

  • The order is canceled. When an order is canceled, the system processes an undo on all of the completed tasks and subprocesses and returns the order to the creation task. The tasks and subprocesses associated with the order are no longer required because the order has been canceled.

  • A branch becomes obsolete. A branch becomes obsolete when the redo processing of a particular task or subprocesses causes that task or subprocess to a) exit with a different completion status and b) start a new branch. Because the tasks and subprocesses in the obsolete branch are no longer required, they are undone, one task or subprocess at a time, starting with the last completed task or subprocess in the branch.

  • When the task re-evaluate compensation strategy is selected as Undo then do and if this option is selected as Undo, then all the tasks are undone based on their corresponding compensation strategy. If this option is selected as Do Nothing, the corresponding tasks are not undone.

In both scenarios, the system rolls back the order changes. The difference between them is the creation of a compensation undo task. Undoing the task and rolling back order changes creates an undo task; automatically rolling back order changes does not create an undo task. Undo compensation tasks created for manual tasks appear in the Task web client Worklists and must be manually acknowledged in order to be rolled back.

This also applies to a task which has an Undo then do compensation strategy for when the task needs to be re-evaluated. When the task needs to be undone (as a part of Undo then do), it follows the compensation strategy for when the task is no longer required (either Do nothing or Undo). When the task needs to be compensated, it gets undone first and then done. The task does not come into Undo in the worklist, but only goes to Do (in amending) or Do (in progress).

Select Undo to create an undo read-only task in the Task web client.

Select Do Nothing to instruct the system that no compensation is necessary.

Select Compensation Expression to create an XQuery expression in the Compensation Expression field that dynamically selects a compensation strategy (Undo or Do nothing) based on revision order data. See "Compensation XQuery Expressions" for more information about compensation strategy XQuery expressions.

When an amendment occurs this task will be compensated if it is:

Most tasks should only be included in amendment processing after the task has completed. However, you may want to include in progress tasks in amendment processing when the tasks are long running, for example when interacting with a workforce management system where task fulfillment can take hours or even days to complete.

Select Completed to instruct the system to include the task in amendment processing only when the task is completed.

Select Completed or in progress to instruct the system to include the task in amendment processing when the task is completed or when the task is in progress. A task is considered to be in progress when the task is in the Accepted state or in any user-defined state. You can also further refine when an in progress task is included into amendment processing by specifying the In Progress Compensation Include Expression and the In Progress Compensation Complete Expression XQuery expressions.

Select In Progress Compensation Include Expression to create an XQuery expression that further specifies when instances of this in progress task can be included in amendment processing based on revision order data. For example, the expression may determine that the task only be included in amendment processing when it includes product A rather than product B. See "Compensation XQuery Expressions" for more information about compensation strategy XQuery expressions.

Select In Progress Compensation Complete Expression to create an XQuery expression in the Compensation Expression field that runs whenever data is updated on the task that checks when compensation has completed based on the order data changes. For example, the order amendment could specify that the task run in redo mode. The task re-sends a request for a customer service with changes to an external fulfillment system that returns an acknowledgement response that the XQuery expression recognizes as completing the compensation for the in progress redo task. The task can then return to the normal do execution mode and waits for the external system to functionally complete the task and respond so that the task can be completed. See "Compensation XQuery Expressions" for more information about compensation strategy XQuery expressions.

When an amendment occurs if this task is in progress it will:

If amendment processing occurs while a task is in progress, you can specify what kind of grace period should be enforced before the task can run in the compensation execution mode.

Select Wait for the grace period to instruct the task to run in the compensation execution mode when the grace period specified on the order-life cycle for the Process Amendment transition.

Select Be excluded from the grace period to instruct the task to run immediately regardless of the grace period specified on the order-life cycle for the Process Amendment transition.

Select Wait for specified duration to statically configure the grace period for the task by seconds, minutes, hours, or days.

Select Dynamic Expression to create an XQuery expression that dynamically specified the wait duration based on revision order data. This expression runs regardless of what option is specified from the above list. See "Compensation XQuery Expressions" for more information about compensation strategy XQuery expressions.

Note:

If an amendment is received while a task is in a fallout execution mode, the following will happen:

  • If the task is not configured to be compensated if it is in progress, the execution mode of the task will not change as a result of the amendment order.

  • If the task is configured to be compensated if it is in progress, and the amendment contains changes to significant data:

    • If the task is still needed after the changes to the order from the amendment are considered, it will transition automatically to (normal) Redo mode.

    • If the task is no longer needed after the changes to the order from the amendment are considered, it will transition automatically to (normal) Undo mode.

    In both of these cases, your automation code (for either Redo or Undo execution mode) should contain both a check to see if the task has been in a fallout execution mode, and also any code that is needed to resolve any actions that have been taken in the fallout execution mode. For example, if your automation for Do in Fallout mode opens a trouble ticket, your Redo automation should check to see whether it needs to close a trouble ticket.

  • If the amendment order contains no changes to significant data, the execution mode of the task will not change as a result of the amendment order.