Workflow for "Process Application" website

Question

Hi All,

We are in the process of designing a web site were users can fill an application form and submit it. Once an application is created, it goes through different departments for review.After each review, the department persons log on to the website and update the status of the application. Once review is completed, the application is said to be 'approved'. Also, communication(email) is sent to the applicants updating them about the status of their application. I am thinking of using Windows Workflow for this application, but am new to it. Can anyone tell me if it would make sense to use WF for such an app..or would it be an overkill..I was thinking of using a State machine workflow, as each application created goes through different states. One of my major concerns is, this process also involves manual work such as reviewing the application(this could take days) and then updating the status(say by clicking a button on the website). Can workflow handle this kind of thing?

I have gone through many websites, but they talk about very basic examples where states change automatically.But in my case there is a lot of human interaction.

Any help is appreciated

Thanks!!!

Answer 1

Here is a sample on MSDN that describes a very similar workflow that you've described - although they use a Windows Forms client rather than a web client - but those details shouldn't matter given the use of the Workflow Runtime.

I would say that your situation would be well suited to Workflow - long-running workflows are supported by having the runtime automatically persist workflow details at certain points while it runs, so steps that take days or weeks to fulfill are perfectly fine.

Answer 2

"my case there is a lot of human interaction".

That's the easiest kind of thing to build. It's just transactions.

Each stage in the process is a simple web application.

1. Fetch all items that are waiting at this state. Display them in a list. User picks one.

2. Display that piece of work. User makes changes. Saves it. Some change will move it to the next state. It's still just an update.

That's it. Nothing fancy.

• You just need to very, very clearly define each state.

• You must have a simple query that finds work in this state.

• You must have a simple update that moves work on to the next state.

The states must be very, very clear and simple definitions. One column with a state name, for example.

The state transition rules, however, may be complicated. If the work is highly manual, it may be as simple as a drop-down list of available states.

If the state transitions are complex, then, perhaps you need something more sophisticated to embody the transition rules. But since it's manual, you don't need much.

---

1. Do I need a separate workflow instance for each application created?

   I don't know what this can possibly mean. Each "application" that's moving through the pipeline of manual processing steps has a "state" -- the step of the pipeline where it's waiting, right now.

   Each application also has a complete history of each state change. I don't know which of this is a "workflow" that could have an instance. They're just states of being of an object.

2. It is a web application. So it will have some other logic such as view an appln., navigation etc. do I need to accommodate this in the workflow as well?

   Yes and No. Yes, each processing stage which show the application so the user at that stage can do whatever value-add thing they do. They add information or they approve information.

   Each stage in the workflow is a place where some human being makes a decision and takes an action. So each stage displays all the information the person needs to make the decision. There's no additional view required.

   Navigation isn't terribly interesting. People go to pages to see their queues of unprocessed work. I guess you'll have to build a page with some URL's, but there isn't much to that.

3. Would it be ok to have just a part of the application based on workflow.

   Sure. Why not? I'm not sure I understand the question.

   Your web apps just queries a queue of stuff out of the database and present that queue of stuff to a person. The person can request details and make changes to a specific item in the queue. One change the person can make will be to move the stuff out of their queue and into someone else's queue.

   This isn't very complex. It shouldn't be. What's hard is defining the allowed state changes.