It is possible but from how you've designed your form it would be difficult to do with a repeating xml field.

To be able to dynamically add additional users as a destination after an activity starts you want to look at using K2 Roles.  There has been a lot posted about roles so I'll just include some of the links for review:

K2 blackpearl Roles and Advanced Destination Rules whitepaper:

http://www.k2underground.com/media/p/20948.aspx

Video describing and using roles in a process

http://www.youtube.com/watch?v=AySjFjdZwgQ

It sounds like you want the users to be able to select and add users to the destinations in your form.  You can still do this using roles but you'll need to add the users outside of the form as a SmartObject whether its inside a SharePoint list, using the SmartBox database, or some other location.  You can then create your role which can call the SmartObject and retrieve the latest set of users.   You would assign the roles as the destinations for the different activities in your process.

In the past, I have baked changing users into my workflows as potential actions, so that at any step in the workflow the user can add users and select the 'update users' action which basically sends the activity right back to itself (after updating your users xml or wherever you get destination users from), but the destination rules are re-evaluated and work items are assigned accordingly.

Hi tbyrne,

Could you be more elaborative please?

After the instance has been created and running (5 users), how do I catch hold of the same instance and add additional destination users (3 users).

Could you give me a small example.  Do I've to use any K2 APIs.

Please comment.

Regards,

Phanibabu Kandala

What I am suggesting is that each of your client events is really made up of two activities - the first one sets the expected destination users into your repeating xml structure (using whatever logic you need to get the right destination usrs) and the second activity is the actual client event.  One of the actions coming off the client event would be 'reset' or 're-think destination users' or whatever action name makes sense for your process.  This action could be available to your end users just as any other normal action (not sure about your UI for users selecting actions...) and, when selected, will take the workflow back to your activity that sets the destination users.  This will cause the activity to essentially re-create itself for the destination users again, assuming you've modified the users xml to be what you now want it to be.

Hi tbyrne,

First of all, thanks for your information.

This is how my process is designed.

I've a server event in a separate activity which queries the sharepoint list and fetches the users who should be added as destination users in K2 process. The destination users are added to a K2 Xmlfield.

Then I've a SharePoint client event in a separate activity. In the code behind for destination event, I've fetched the K2 Xmlfield value and called the K2 API to add each xml repeating field as a destination user.
K2.Destiantions.Add("Xml Element");

This worked fine.

If I add an extra action say "Add More Users", then where would the logic go (of quering additional destination users and adding it to the K2 Xmlfield)? Is it in the code behind of the action itself?

Once this action is triggered from the UI, where will the process flow go? Is it to the destination rule(code behind). How does this work?

Else, please explain more precisely from the point of adding the extra action and how to proceed.

Your suggestion has given me some idea of how it works but please comment on my thoughts?

Thanks & regards,
Phanibabu Kandala

I think they way your process is currently designed lends itself well to this solution.

The point of the extra action is to take the process flow to your activity that populates the destination users in the xml field.  Presumably, the users that you want to include will now be in the SharePoint list that fills in this xml field?  So basically, executing this action makes your client event 're-think' its destination users by doing the exact same steps that was done when the client event was initially created.  I hope I am explaining myself well

On a side note, you indicated that you set your destination users in code behind by iterating through the xml field nodes - did you know that you can simply drag your repeating xml node from that data field view onto the destination rule wizard and it will automatically assign the task to all users in the xml field?  No code needed.

Hi tbyrne,

Thanks for your suggestions. I'd try this out and let you know.

So, I'd write the code to fetch the destination users again in the code behind of the newly added action and point the action to the same activity.

So, whenever a user fires this action, it would re-fetch the destination users and jump to the destination rule code behind and add the users accordingly if I understood it correctly.

Also, how can the repeating field added to a destination rule. We've tried this out in the past but it did not work for some reason and it threw an error. Could you tell me the exact way of using this repeating xml field in a destination rule. Are there any precautions that needs to be taken?

Thanks & regards,

Phanibabu Kandala

I put a few screenshots together and attached them - hopefully they better describe what I am trying to explain than just text.