Hi Anders,

I don't think you're going to be able to achieve your suggested implementation without code.

Is there a particular reason why you can't add the originator as a destination on activity A? I would do the following:

- Add the originator as a destination on activity A (in addition to the other activity A destinations)

- Add all actions that were originally planned for activity B to activity A instead

- Ensure you are creating a slot for each destination (so the originator can open the task without removing it from the other's worklists)

- Change permissions on the individual actions via workspace such that individuals other than the originator can't use them (this may not even be necessary in your case)

Now, if the originator selects the "Resubmit" option, this action can loop back into the same activity and all users will get an updated task. If one of the other users completes their task, it will be complete for all.

HTH,

Tyler

Hi Tyler

I've been following this thread and your approach sounds good.  However, the one item I can't figure out is how to restrict the "Resubmit" action to just the Originator?  In my tests the K2 Workspace doesn't know the context of the Originator when applying permissions to the action.

Regards,

Tim

Hi Tim,

You're right of course; there is no "Originator" context from the workspace level.

In my experience, there's usually some predictable group/role of users that are "originators" and a predictable group/role that are "participants" and this is what I was alluding to.

So, in this case, the OP is probably assigning activity A to some kind of group or role. He could explicitly deny this group permission to "Resubmit" via workspace; in this way, there is no need to explicitly allow the Originator permission to use it assuming he's not a member of the same group. Just make sure the originator is a separate destination set on Activity A so he gets his own task.

HTH,

Tyler

Hi Tyler, 

thanks for your reply; I think your solution might be the best practical way to go. However, in terms of process flow I believe it  would make more sense to separate the resubmit into a activity B as the task is not related to either the destination nor the tasks in activity A. By combining everything in activity A the originator will get a task with an activity name on his worklist that does not really reflect what the task is, and the activity logs of the process will also be more difficult to understand for the users. 

I think the main challenge with my initial approach of splitting into two parallel activities is that either activity must be expired when the client event is opened in the other activity (e.g. when originator opens the task B the task A must be removed from the other's worklist as they should not be able to perform the task until the resubmission has been completed). As far as I can see this can only be achieved by either:

- Adding code to the InfoPath OnFormLoad event that expires the other task, or

- Create a custom aspx/service that expires the other task prior to opening the task.

Anders

I agree the expiring of the other worklist item on the opening of the task is the greatest challenge. 

Because expiring another activity will require elevated permissions on the process I would think creating a custom webservice that's called from the InfoPath form is the way to go so that the webservice can run the elevated code on the user's behalf.