Workflow is simply an ordered series of steps that accomplished some defined purpose according to a set of rules. By that definition, what I just described is a workflow.

        To a developer, the word workflow typically conjures up images of a highly
        visual environment where complex business rules and flow of control are declared graphically.

        It’s an environment that allows you to easily visualize and model the activities (steps) that have been
        declared to solve a problem. And since you can visualize the activities, it’s easier to change, enhance,
        and customize them.
        But there is still more to workflows than just the development environment. Workflows represent
        a different programming model.

        It’s a model that promotes a clear separation between what to
        do and when to do it. This separation allows you to change the when without affecting the what.

        Workflows generally use a declarative programming model rather than a procedural one. With this
        model, business logic can be encapsulated in discrete components. But the rules that govern the
        flow of control between components are declarative.

        <br />
        General purpose languages such as C# or Visual Basic can obviously be used to solve business
        problems. But the workflow programming model really enables you to implement your own domainspecific
        language. With such a language, you can express business rules using terms that are common to
        a specific problem domain. Experts in that domain are able to view a workflow and easily understand it,
        since it is declared in terminology that they understand.

        <p>
        Workflows allow you to easily model system and human interactions. A system interaction is
        how we as developers would typically approach a problem. You define the steps to execute and write
        code that controls the sequence of those steps. The code is always in total control.
        Human interactions are those that involve real live people. The problem is that people are not
        always as predictable as your code. For example, you might need to model a mortgage loan application.
        The process might include steps that must be executed by real people in order to complete the
        process. How much control do you have over the order of those steps? Does the credit approval
        always occur first, or is it possible for the appraisal to be done first? What about the property survey?
        Is it done before or after the appraisal? And what activities must be completed before you can
        schedule the loan closing? The point is that these types of problems are difficult to express using a
        purely procedural model because human beings are in control. The exact sequence of steps is not
        always predictable. The workflow model really shines when it comes to solving human interaction
        problems.
        </p>

        <p>Why windows Workflow Fundation</p>
        <p>
        If you are developing line-of-business applications, you can use WF to orchestrate the business
        rules. If your application is comprised of a series of human interactions, you can use a WF state machine
        workflow to implement logic that can react to those interactions. If you need a highly customizable
        application, you can use the declarative nature of WF workflows to separate the business logic from
        the execution flow. This allows customization of the flow of control without affecting the underlying
        business logic. And if you are looking for a better way to encapsulate and independently test your
        application logic, implement the logic as discrete custom activities that are executed within the WF
        runtime environment.
        </p>

        <ul>
        <li>
        It provides a flexible and powerful framework for developing workflows. You can spend your
        time and energy developing your own framework, visual workflow designer, and runtime
        environment. Or you can use a foundation that Microsoft provides and spend your valuable
        time solving real business problems.
        </li>

        <li>
        It promotes a consistent way to develop your applications. One workflow looks very similar to the next. This consistency in the programming model and tools improves your productivity when developing new applications and maintaining existing ones.
        </li>

        <li>
        It supports sequential and state machine workflows. Sequential workflows are generally used for system interactions. State machine workflows are well-suited to solving problems that focus on human interaction.
        </li>

        <li>
        It supports workflow persistence. The ability to save and later reload the state of a running workflow is especially important when modeling human interactions.
        </li>

        <li>
        It supports problem solving using a domain-specific model. Microsoft encourages you to develop your own custom activity components. Each custom component addresses a problem that is specific to your problem domain and uses terminology that is common to the domain.
        </li>

        <li>
        It provides a complete workflow ecosystem. In addition to the workflow runtime itself, Microsoft also provides a suite of standard activities, workflow persistence, workflow monitoring and tracking, and a workflow designer that is integrated with Visual Studio which you can also host in your own applications.
        </li>

        <li>
        It is free of charge. Because of this and its tight integration with Visual Studio, it will become the de facto standard workflow framework for Windows developers. A growing community of other WF developers is already in place. They are already sharing their ideas, their custom activity components, and other code.
        </li>

        </ul>