Manual Task Activity

Manual task activities are used to create a manual task instance in a workflow.

Task Template Attributes

AttributeDescription
Task NameThe name displayed in MDW Hub.
Task DescriptionA more detail description about this task.
CategoryOptional mechanism for grouping tasks.
Task SLAFollow this link for information on task SLA.
Alert IntervalAlert interval when SLA is violated. Follow this link for information on task SLA.
VariablesVariables to be displayed in the task detail page in the task manager.
Work groupsThe user group(s) the task is to be placed in.
Auto-assign StrategyStrategy to automatically assign tasks to a user in the specified user groups.
NoticesFollow this link for information on task notices.
Notice GroupsFollow this link for information on task notices.
Recipient VariableFollow this link for information on task notices.

Standard Actions

 The rules governing allowable standard actions are defined in asset com.centurylink.mdw.tasks/mdw-task-actions.xml. Standard actions have specific pre-determined outcomes which may be overridden in your process definition. The following table summarizes the available standard actions and their default outcomes.

Action Outcome for In-Line
Task Activities		 Outcome for Exception Handler
Task Activities
End State
Activity Status Task Status Task State
Abort Process containing task activity is failed Parent process with errored activity is failed Failed Failed Closed
Assign Task instance is assigned to selected user Task instance is assigned to selected user Unchanged Assigned Open
Cancel Process null transition from task activity Process null transition from errored activity Cancelled Cancelled Closed
Claim Task instance is assigned to current user Task instance is assigned to current user Unchanged Assigned Open
Close No workflow outcome No workflow outcome Cancelled Cancelled Closed
Complete Process null transition from task activity Process null transition from errored activity Completed Completed Closed
Forward Task instance becomes selected type Task instance becomes selected type Unchanged Unchanged Open
Release Task instance becomes unassigned Task instance becomes unassigned Unchanged Open Open
Retry No default behavior Invoke main process errored activity again Cancelled Cancelled Closed
Work Task instance becomes editable for assigned user Task instance becomes editable for assigned user Unchanged In Progress Open
Custom Action Process custom transition from task activity Process custom transition from errored activity Completed Completed Closed


Note that the default behavior for standard actions may differ according to whether a task instance was created by an In-Line Manual Task Activity (appearing in a user-created process) or an Exception Handler Manual Task Activity (appearing in an embedded exception handler subprocess).

TaskActions.xml

Standard task actions are configured in the TaskActions.xml file, which is excerpted below: 

    <taskStatus status="Assigned">
      <allowableAction>
        Release
        <navigationOutcome>tasks</navigationOutcome>
      </allowableAction>
      <allowableAction outcome="Undo">
        Cancel
        <navigationOutcome>tasks</navigationOutcome>
      </allowableAction>
      <allowableAction>
        Retry
        <navigationOutcome>tasks</navigationOutcome>
      </allowableAction>
      <allowableAction alias="Finish">
        Complete
        <navigationOutcome>tasks</navigationOutcome>
        <autosave>true</autosave>
      </allowableAction>
      <allowableAction>
        Forward
        <navigationOutcome>tasks</navigationOutcome>
        <forTask>
          Forwardable Task
          <destination alias="Billing">Billing Task</destination>
          <destination alias="Production Support">Production Support Task</destination>
        </forTask>
      </allowableAction>
    </taskStatus>

The TaskActions.xml file is divided into sections which define the allowable actions according to whether they are to be performed at the bulk level (Task List page) versus the individual level (Task Detail page). At the individual level, standard actions are also specified according to the current status of the task instance.

The UI labels for standard actions can be easily customized by way of the "alias" attribute as illustrated in the TaskActions.xml snippet following the table (where the Complete action is rebranded to the label Finish). Also, the default outcome can be overridden by designating the "outcome" attribute which controls the downstream process transition that will be traversed when the action is performed.

Notice that a particular action can be limited to a subset of possible task types via the <forTask> element (although it may be more advisable in this case to utilize custom task actions as described in the next section below). The standard actions configuration can also control the page in Task Manager where the user will be navigated after performing the action by using the <navigationOutcome> element.

See the embedded comments in TaskActions.xml for a more detailed description of how to configure standard task actions.

Custom Actions

Custom task actions are not globally configured but instead are specified for a particular circumstance as part of the process definition. Since custom actions depend on the process definition and are specific to a particular instance, they are only presented to the user at the Task Detail level. The following process definition diagram illustrates how custom task actions are used:



In this example process the left-hand outcome ("Inline") from the script activity illustrates how custom task actions are specified for task activities included directly in your main process, while the right-hand outcome ("Exception") illustrates the usage for embedded exception handler subprocesses.

For the Inline case, allowable actions for the "Activity-Created" task instance are governed by the result codes of its outbound transitions. Here the possible actions called "ActionOne" and "ActionTwo" would be added to the dropdown list on the Task Detail page for any task instance created by "Activity-Created". The Inline scenario also specifies what would happen when certain standard actions are performed (Complete or Cancel would proceed to Stop, and Retry would go back to the "Set Task Type" script activity).

For the Exception case the semantics are slightly different owing to the fact that the task instance is created by an activity within the embedded exception handler subprocess. To distinguish the outcomes which are applicable during exception handling, the event type RESUME is specified for task action transitions. Here if an error is encountered in the "Error Creation" activity, a task instance will be created which on its Task Detail page will include the custom action "ActionThree" in the dropdown list. Also in the Exception case the behavior for the Retry standard action is overridden. Instead of retrying the "Error Creation" activity, process flow is directed back to the "Set Task Type" script activity. Actually in the scenario where a retryable ActivityException is thrown from "Error Creation", automated retry will be attempted the configured number of times before the manual task is even created. When the task is retried manually, only then would the RESUME:Retry transition be traversed.