Escalating client events when user is Out Of Office on Exchange

Wouldn't that involve polling each user's Exchange mailbox at regular intervals to check their OOO status? That wouldn't be workable for the number of users we have. Similarly if done at long intervals then the OOO data won't be accurate and worklist items will get stuck with OOO users.

 I was thinking of putting code before the client events in the workflow to get the destination user's OOO status and then change the destination user if necessary. I haven't actually got round to testing this yet so don't know if it will even work. I'm also concerned it will affect the reliability of the workflow, especially if I have to add more references to the project.

 This functionality should really be available out of the box!

I spent some time searching but I couldn't find any way to hook into the Exchange event when a user set's his outlook out-of-office status.

So with that being said, if this is true then the limitation would be on the Exchange side and not K2 side as we do provide API interfaces to allow you to configure the OOO status.

However, I am not an development expert on Exchange so I can't tell if my assumption is correct.  Somebody can proof me wrong here if they know anything to the contrary.  If there is a way to hook into the event when a user changes his status, then it would be possible to automatically set the K2 OOO status without a significant performance hit.

 Does that make sense?

Yes, the Exchange web service works a treat!

 This is what I did:

 - Create a DLL with a method for checking the users OOO status with the web service.

- Reference the DLL from my blackpearl workflow project.

- Store the destination users in datafields.

- Add a Default Server Event (Code) before each Client Event. In the code for the event, call my method for checking OOO and if the user is OOO, use the GoToActivity method in the blackpearl API to go to the next Default Server Event to check for the next user's OOO availability. When using GoToActivity you have to go to an activity before the Client Event, otherwise the destinations users will still be assigned the activity that you're trying to skip. That's why the OOO check needs to take place in a Server Event before the Client Event is reached.

 Thanks for the help guys!

Peter Yao:

You can not check for OOO in the Activity's Destination Rule (on K2_2003)?

If OOO then assign a different user in the destination.

 I expect you can, and I did try that myself. The problem was that I had no idea what the K2 code was doing, especially the AddDestinations method. I had my destination users in datafields anyway because they vary depending on business rule scenarios in the application, so I populate the datafields when creating a new process instance.

 I would be interested in knowing how you can do the OOO stuff in the destination rule for future reference, for workflow projects where I'm not putting the users into datafields.