workItem

Specifies additional information about the work item. Contains the following attributes:

views

Contains a list of workflow variables whose values are views. The system uses this attribute to cause view-specific refresh operations when the work item view is refreshed.

Do not change this value.

related

Contains a list of attributes that describe the specified work item.

request

Succinctly describes the purpose of the work item. This description is typically shorter than the value of the description attribute and is often displayed in summary tables.

requester

Identifies the user that initiated the approval.

ignoreTimeOut

Indicates whether the time out should be ignored. A value of true (assigned by the system) indicates that this is a read-only work item that may timeout while being viewed. This is a signal to the system that a check-in failure of the Work Item view should be ignored if the work item no longer exists, rather than displaying an error message. This can be useful for work items that are intended only for status messages that time out immediately so the workflow can continue while the user views the messages.

Do not change this value.

Using the variables Attribute

When writing a work item form, the most common attributes to reference are complete and variables. The complete attribute must be set to the value true in order for the workflow to be resumed. It is typically set by a hidden field in response to pressing button fields with labels such as Approve and Reject.

The variables attribute contains an object whose values are copies of variables from the workflow task. One of the most common workflow variables used in work items is user, which contains a user view. For example, to reference the global.email attribute from a work item form, use the following path expression:

variables.user.global.email

This differs from attribute paths used in a standard user form. First, the entire view is stored in a workflow variable named user, which results in the user. prefix being required in the attribute path. Next, the workflow variables are stored under the variables attribute in the Work Item view, which results in an additional variables. prefix being required in the attribute path.

Because of this nesting of the user view attributes, you cannot use a standard user form with the Work Item view without modification. However, you can define a work item form that references the user form with the base context option.

Example

<Form name=’WorkItemForm’>
   <Include>
      <ObjectRef Type=’UserForm’ name=’Default User Form’/>
   </Include>
   <FormRef name=’Default User Form’ baseContext=’variables.user’/>
</Form>

Although in practice the work item form requires additional fields for buttons such as Approve and Reject, you may not want everything displayed by Default User Form displayed in the work item form. Typically, you can factor out the fields in the user form into a form library that can be referenced by both the user forms and the work item forms.