Windows Workflow Foundation

• Workflow Foundation was first released in Version 3 of the .NET Framework,[4] and primarily uses the System.Workflow.Activities, System.Workflow.ComponentModel, and System.Workflow.Runtime namespaces. Workflows in version 3 were created using either the Sequential model (in which activities are executed in order, with the completion of one activity leading to the next), or the State Machine model (in which activities are executed in response to external events). Microsoft SharePoint 2007 uses WF 3.
• In .NET Framework 3.5, messaging activities were introduced that integrated Workflow with Windows Communication Foundation (WCF). With the new ReceiveActivity, workflows could respond to incoming WCF messages. The new features of Workflow in version 3.5 use the System.ServiceModel namespace. Microsoft SharePoint 2010 uses WF 3.5.
• In .NET Framework 4, Windows Workflow Foundation was updated extensively, with new features such as Data Contract Resolver, Flowchart, and other flow control activities added. Workflow in .NET 4 uses the System.Activities namespace. Most notably, there is no longer a Workflow Runtime object in version 4; workflows are executed directly using WorkflowApplication or WorkflowInvoker instead.
• Activities created in previous versions of the .NET Framework can be executed by .NET 4 workflows using the Interop activity.
• Future versions and releases of Windows Phone will include an updated State Machine and Dynamic Update.

Windows Workflow Foundation is used to create applications that execute an ordered business process, such as the steps needed to approve a document, hire a candidate for a position, or make a purchase. These processes can execute in a short amount of time, but are typically long-running, in which the application will need to shut down to conserve memory between steps. Typically, business processes to be modeled as workflows have the following features:

• Have specific business logic that may need to change periodically, such as the tax or shipping calculation needed to determine the purchase price of an item, or the series of steps needed to approve a purchase, hire, or process.
• Have several inputs into the workflow that may come hours or days apart
• Have advanced business logic that might require workflow execution to travel down different branches depending on different circumstances.
• Need to interact with other systems, such as a database, website or other client application, or web service.

Workflows are created either by being defined in XAML Extensible Application Markup Language using the workflow designer, or by being assembled programmatically in a .NET language such as C# or VB.NET. If the designer is used, activities are assembled on the workflow designer canvas by dragging them from the toolbox. Workflow arguments and variables are also created and assigned within the designer. If a workflow is assembled in code, activities are instantiated like other CLR objects, and assembled into collections of a single parent activity, usually a Sequence or Flowchart. The single parent activity is then executed using WorkflowApplication or WorkflowInvoker, and runs as a workflow. The term "Workflow" here usually refers to the root activity that is executed by the host. Workflows can use both out-of-box activities and custom activities. Out-of-box activities include flow control activities such as DoWhile, Flowchart-related activities such as FlowDecision, WCF Messaging activities such as Send, and primitive activities that perform simple tasks like Assign and WriteLine. Custom activities are user-created CLR objects that derive from the class System.Activities.Activity, and provide declarative functionality by allowing the developer to define the execution behavior of the activity in code. Custom activities can benefit from having a custom activity designer associated with them to enhance the visual authoring experience in the Visual Studio IDE.

• Microsoft Docs: Windows Workflow Foundation