Here are three ways this can be accomplished (this is not an exhaustive list):
I. You can set destination to a process data field (string data type). The value of the data field must be the fully-qualified user name. Assuming you are using Active Directory as your primary authentication provider, it would look like this: DOMAIN\Username (you can also use the K2 fully-qualified name, which would be: K2:DOMAIN\Username) It would be best to take steps to ensure the user name meets the requirements above.
II. This can also be done using a process xml field with a repeating node where the repeating node is set as the Destination. For example, for the following XML field called DestUsers, the ’Name’ element is a repeating node that includes two users:
<User xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Name>K2:K2DEMO\Administrator</Name>
<Name>K2:\K2DEMO\suzans</Name>
</User>
When the Destination is set to the repeating node of the xml field, each user in the repeating node will become a Destination User. Note that the xml field name will display in the Destination Rule as "DestUsers_Name", where "DestUsers" is the xml field name and "Name" is the repeating node that contains the name of each destination user.
III. We also found that you can set value of a process data field (not XML) to a role name. Therefore, you could assign the worklist item(s) to different roles dynamically. This document available on K2 Underground can help clarify these matters:
http://k2underground.com/files/folders/technical_product_documents/entry20948.aspx
- Sam and Blake
--------------------------------------------------------------------------------
The statements and opinions made in my postings are my own, and do not reflect the opinions of SourceCode Technology Holdings, Inc. or its subsidiaries. All information is provided as is with no warranties, express or implied, and grants no rights or licenses.