Can a K2 process s workflow (already running) be changed according to the state of an external datasource?
Example: A Cheque Requisition process is already at the ManagerApproval activity. The Manager is looking at the Approval form (client event), while the cash balance has dropped below the amount the manager is currently viewing on the screen.

There is no provision for real-time triggering of changes in a K2 Process based on any state change in the database. K2 Server does not perform polling of any data variable state, but rather, relies on a listener K2 Service to receive work requests.

If you are looking at performing variable inspection to determine how a workflow should proceed, the method to this is knowing when exactly the data is updated.

We will assume that the data fields to be inspected are implemented as K2 Process Data. Basically, the data must be updated via an external source (that knows the correct process instance ID that needs updating). The K2.net SmartForms make use of the object model to retrieve their data. However, only when the form (and therefore the underlying objects) is instantiated, are the data values read from the database. This means that whilst the form is open on the screen, the K2.net Object Model is not aware of any data change at server level. Therefore assuming we have a variable called Total , and this is set to $1000 when the page is rendered (and $1000 is shown in the text box). If the value is changed in the backend by an external party, possibly via a direct DB update, this change will not be reflected by the UI.

Should the user close the current form, and click on the work item again in their worklist (thereby reopening the item), the new value will then be shown (as the Object Model would have been instantiated again, with the updated values). If, however, the user does not close the UI (and it still shows $1000), if the user clicks on submit (and if the data field is bound to the process), the value of $1000 will be written to the database (effectively overwriting any newer value in the database).

A similar scenario exists where a form is sent to multiple users concurrently, and some of the fields are bound to process (rather than activity) data. If any user has opened up the UI, and another user updates a process data field, the first user will effectively have a dirty read on the data. In situations such as these, it is an implementation issue where data concurrency considerations have to be made to handle the accuracy of process data.