I agree that it wouldn't be a good design to keep those workflows live.  Besides its almost certain it will not be the same 500 users the next year (due to regular attrition) which would need to be manually expired

Possible design ideas (there are probably a more options than what I'm describing).

Build a simple console application that would iterate through all the users and programatically start a K2 process for each user passing in the user name that would be used in the client event.  Since its once a year I'm not sure I would even bother with creating some automatic scheduling besides putting an item in your calendar to remind you to run the console app to kick it off.

Another possible way is you could have a parent process that iterates through the list of users (retrieved through a getlist method of some SmartObject query) and start a child process for each user which would assign the client event to them.  You could even use the scheduling mechanism in the K2 Process Portal to schedule the parent process to start every year at a particular date e.g. something like the first Monday in June for example.   This would have the advantage of potentially being a no code automatic solution but in my opinion its probably a bit more complex to completely configure than the first scenario due to the IPC event and handling the succeeding rule.  The code required in the first example is simple with samples being availabe in the SDK.

Thanks Tim for those suggestions. I might try the no code way and create the parent process to iterate through the list of users.

I agree with the fact that its once a year they need to use this - its overkill. The users may want a dummy proof and want to be informed of when that time comes etc. So I might do a simple workflow to keep an instance ticking for when that time comes, ths is yet to be discussed

Elly