We have the following business requirement: A user submits a IP form starting a new process instance that goes into a client event activity whose destination users are different from the originator. Until the client event is opened, the process originator should be able to 're-submit' the process - i.e. he/she should be able to open the original form that was submitted, change the content, and then submit the form again within the same process instance.
To implement this I was thinking about the following design: When starting the process the process enters 2 parallel activities; activity A which is the 'original' activity (whose destination users are different from the originator) and activity B which is the 're-submit' activity (whose destination user is the originator). For this to work either activity needs to be expired when the client event of the other activity is executed; e.g. if the originator decides to re-submit the process and opens the client event of activity B, then activity A needs to be expired. Upon completing activity B the process enters activity A (and B) again.
Is there any was of achieving this in a more or less elegant way? (I would like to avoid adding code to the IP form). Or any other suggestions how to solve this?
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.
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.
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.
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.
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.