Well the fun is over and I am on my way home after what I would call a great experience at another conference.

I think I have talked to at least 1000 people this week, about all kinds of topics as I have mentioned before. A few really stick out

This gentleman is very bothered by some experiences in building workflow in WF. Primarily due to his perceptions and or experience as follows:

1. IF you are doing sequential workflow in WF, doing parallel activities is impossible
2. If you are doing state machine workflow rejecting the workflow and rerouting dynamically to one of several other steps in the workflow is impossible.

So his question to me in short is can you fix this using your product, and if so how? If we are built on WF how is that possible?

Well the answer is pretty simple and that is that yes we use WF and as you are walking through the various wizards in our design canvases you are generating WF schedules. BUT, The power of K2 is that it abstracts the creation of the WF schedules from the process.  The logical business steps and events in the workflow created through the K2 graphical design tools do in fact create WF schedules for these activities, events and lines.  However, these WF schedules are separate and called by the K2 Host when needed to execute that part of the process.  This allows K2 to provide a higher level of abstraction and additional capabilities than what the WF platform provides OTB.  Through the K2 Host we can provide parallel business activities and rerouting of work to any step in teh workflow that WF currently does not provide using a single WF schedule.

Here is what he wanted to do

1. Imitate Request
2. Goes To initial Reviewer. This person can approve or reject
3. If Reject WF stops originator gets notified
4. If approve it branches into "parallel" where a task gets assigned to a level 2 approver as well as a COO type person
5. This coo type person can reject the request and send it back to the level 1 approver or reject it and send it back to the originator. With BP this could just be an additional outcome
6. If approve it goes on to another along this path.
7. After this person approves it the parallel part ends and the paths rejoin.
8. Final approval and WF END
9. ALSO it was his requirement that at ANY point in time persons along the secondary "parallel" route can override and reject and kill the whole process. This can be done through API expire activity and or GOTO events that will kill the other path,

A second one that sticks out is a company that is using MOSS currently and started leveraging the OOB workflow and SharePoint designer right away. They were very excited about what it was able to do, and how it started to help them collaborate, manage documents, do some level of list and task management etc. However as people started to use it, and like it, they started coming up with more and more ideas of how they could use it to do more. Something very common in IT and probably other areas. As soon as you get a taste of something you begin to try to figure out other ways to get that etc.

So the result of this is that they are starting to have to use more and more IT resources to be involved and not only get more heavily into SPD but now because the processes they need and or want are becoming more complicated or involved they are having to use VS a lot. So its consuming resources mainly him since it's a small IT team. So as I walked him though our SharePoint workflow designer and how this may satisfy some of his users I could see his brain racing and some ideas of exactly where he could use it come into his thoughts. Now we just eliminated SOME of his work. So he was somewhat happy. But as I started to show him what he could do in Visual Studio and how he could build workflow in that, QUICKLY and how integrated it could be with MOSS even showing up in the workflow lists in the office client. He realized that even if IT needed to be involved in creating the workflow using blackpearl would save him A TON of time. Once he started to figure out how by using blackpearl he could latterly get a request for a workflow and crank it out in a matter of hours rather than telling the user that he would get to it later this month. Which means happier users, which means happier everyone. Talking someone though this and having them "GET IT" and agree with what you have been presenting, seeing that what you have been telling others in that blackpearl is going to be a huge time saver, it is going to allow people to create better process, better applications, better workflow, faster. It is a VERY satisfying rewarding experience. As I type this on the airplane home I am still feeling it again. It is my hope that the more people hear about us, the more people play with the software, the more people we have a chance to talk to the more we can have these similar experiences. And the more IT shops we can make look like rock starts to their users.