Summary

A developer asks about the following sequence of user interactions with a work object form presented by the standard Work-.Perform harness rule:

1. Clicks the Update button to gain access to fields in the work object form that are not part of the Action area (and so not part of a flow action).
2. Enters or revises data.
3. Clicks the Apply button.
4. Clicks the Close (X) button to close the work object form.
5. Begins work on an unrelated assignment.

The changes made in step 2 are lost, and are not recorded in the work object. Is this expected?

Suggested Approach

This outcome is by design.

Work object forms (based on harness rules) are completely controlled by flow rules.  

The Update button provides users with a way to access fields that are normally not part of a flow action, for example to correct earlier input. However, the Update button does not alter the overall requirement that flow processing controls what happens to the work object.

The Close button is not a flow action. If users could update non-flow-action fields (and save the updated work object) without completing any flow action, they could bypass the checks and logic of the flow actions.

For example, assume a flow contains seven assignments executed in sequence; each provides additional data that depends on all earlier inputs. At assignment 6, a user may discover that data entered in assignment 4 was incorrect, and use the Update button to allow entry of corrected data. But by further completing a flow action, the user allows the application to check the consistency of all data — assignments 1 to 6 — before advancing to the next flow shape..

Based on such considerations, users must complete and submit a flow action to save the changes allowed by the Update button.