Any kind of change to the task details page, such as changing a priority or adding a comment or attachment, requires you to save the change before you go on to make any other changes.

Task details can be viewed inline (see the lower section in Figure 32-2) or in the same window or a new window (Modify settings in Edit Inbox Settings.)

Figure 32-19 shows the task details page.

The task details page has the following components:

• Actions—Lists the system actions that are possible for the task, such as Request Information, Reassign, Renew, Suspend, Escalate, and Save.

• Action buttons—Displays buttons for custom actions that are defined in the human task, such as setting task outcomes (for example, Resolved and Unresolved for a help desk request or Approve and Reject for a loan request). For the task initiator, manager, or administrator, Withdraw may also appear.

• Details—Displays task attributes, including the assignee, task creator, task number, state, priority, who acquired the task, and other mapped attributes. It also displays dates related to task creation, last update, and expiration date.

• History—Displays the approval sequence and the update history for the task. See Task History, for more information.

  Table 32-6 tells what the icons used in the Task Details History section signify.

  Table 32-6 Icons for Task Action History

  Icon	Description
  	Indicates an approver in an ad hoc routing scenario.
  	Indicates that the task has been approved.
  	Indicates that the participant is an FYI participant—that is, this participant just receives a notification task and the business process does not wait for the participant's response. Participant cannot directly impact the outcome of a task, but in some cases can provide comments or add attachments.
  	Indicates that a set of people must work in parallel. This pattern is commonly used for voting.
  	Indicates that the participant belongs to a management chain.
  	Indicates the simple case in which a participant maps to a user, group, or role.
  	Indicates that the task is untouched.

• Comments—Displays comments entered by various users who have participated in the workflow. A newly added comment and the commenter's user name are appended to the existing comments. A trail of comments is maintained throughout the life cycle of the task. To add or delete a comment, you must have permission to update the task.

• Attachments—Displays documents or reference URLs that are associated with a task. These are typically associated with the workflow as defined in the human task or attached and modified by any of the participants using the worklist. To add or delete an attachment, you must have permission to update the task. When adding file attachments, you can use an absolute path name or browse for a file.

  Note:

  In an environment with servers clustered for high availability purposes, file uploading is not supported if a failover occurs. If the active server shuts down, then the uploading process is not assumed by the other server and the upload fails.

Comments and attachments are shared between tasks and subtasks. For example, when you create a business task and add comments and attachments, subtasks of this task include the same comments and attachments.

The Task Details page may appear differently depending on the tool used during design time to develop the task form it displays.

A user can view a task when associated with the task as the current assignee (directly or by group membership), the current assignee's manager, the creator, the owner, or a previous actor.

A user's profile determines his group memberships and roles. The roles determine a user's privileges. Apart from the privileges, the exact set of actions a user can perform is also determined by the state of the task, the custom actions, and restricted actions defined for the task flow at design time.

The following algorithm is used to determine the actions a user can perform on a task:

1. Get the list of actions a user can perform based on the privileges granted to him.

2. Get the list of actions that can be performed in the current state of the task.

3. Create a combined list of actions that appear on the preceding lists.

4. Remove any action on the combined list that is specified as a restricted action on the task.

The resulting list of actions is displayed in the task list page and the task details page for the user. When a user requests a specific action, such as claim, suspend, or reassign, the workflow service ensures that the requested action is contained in the list determined by the preceding algorithm.

Step 2 in the preceding algorithm deals with many cases. If a task is in a final, completed state (after all approvals in a sequential flow), an expired state, a withdrawn state, or an errored state, then no further update actions are permitted. In any of the these states, the task, task history, and subtasks (parent task in parallel flow) can be viewed. If a task is suspended, then it can only be resumed or withdrawn. A task that is assigned to a group must be claimed before any actions can be performed on it.