I'm trying to implement a parallel split task using a workflow system. I'm using .NET but my process is very simple and I don't want to use WF or anything heavy like that.

I've tried using Stateless. So far is was easy to set up and run, but I may be using the wrong tool for the job because I'm not sure how you're supposed to model parallel split workflows, where you have multiple sub-tasks required before you can advance to the next state, but the steps don't require being performed in any particular order.

I can easily use the dynamic configuration options to check my data model manually to see if the model is in the correct state (all sub-tasks completed) and can transition to the next state, but this seems to completely break the workflow paradigm. What is the proper, orthodox way to implement a parallel split process?


  • 1
    The system keeps a list of what needs to happen and displays the next one, but there can be different users responsible for the processes. I've based the design on recommendations from Wil van der Aalst on modeling business workflows.
    – Paul
    Commented Nov 3, 2013 at 0:23
  • As I mentioned, I'm open to using a different tool, but WF is just too big, too heavy, and too cumbersome for my particular project, and reading the comments on StackOverflow it doesn't sound like many people have had a positive experience with it...plus Google suggest "Is Windows Workflow Foundation Dead" as the top suggestion for "Is Windows Workflow".
    – Paul
    Commented Nov 3, 2013 at 11:58

1 Answer 1


In this new answer I will try to explain based on the "Stateless" library mentioned in OP.


More information will be added after I get my hands on Stateless.

In any sense, extension to Stateless is required. Fortunately this is highly doable because Stateless is highly extensible using its partial class approach.

A simple description is that:

  • One business process = a bunch of activities
  • Each activity requires one StateMachine object. See link to library.
    • This is necessary because in some circumstances, each activity can have their own state transitions, as explained in "parallel split workflow" by OP.
  • Some activities are non-trivial (requires an extension to the Stateless library object), which might be implemented in several ways.
    • One kind of non-trivial activity is to embed (or nest, or delegate to) another business process.
  • The business process must mediate the state transition rules across all activities, and this requires an extension to the library as well.)

The typical states in a Activity object:

  • NotConfigured
    • Only exists programmatically. Compare this to a non-fully-initialized object.
    • An activity may require some parameters (e.g. for an Email activity, a email address needs to be configured) before this activity can be triggered.
  • NotNeeded
    • Indicates that, in its current configuration, this activity does not need to be executed in order for the containing business process to be "completed".
    • This state is reversible. It can be "reactivated" upon receiving a trigger from another activity.
    • Example: citizen needs to fill out a SSN. Non-citizen needs to fill out either ITIN or W8-BEN. In either case, one of the activity is not needed. However, if the employee makes a mistake in the option, this mistake should be correctable by clicking a checkbox. This has the effect of deactivating the activity no longer needed, and reactivating the activity now needed.
  • Succeeded
    • This state is final (irreversible). Once set into Succeeded, it cannot be set to any other state.
  • Waiting, with the following substates:
    • WaitingOnPreconditions
    • WaitingOnInternalTrigger
    • WaitingOnBusinessProcess
    • WaitingOnExternalTrigger
  • Faulted, with the following substates:
    • TimedOut,
    • InternalError
      • Contains a stack trace (if it is a programmatic error)
      • Captures a snapshot of the state machines of each activity inside the business process (if it is caused by some invalid state transition requests or mis-configuration of the business process)
    • ExternalError
  • Canceled, with the following substates:
    • CanceledByBusinessProcess (the containing business process is canceled)
    • CanceledByInternalInvoke (this activity is "nested", and the parent activity requested this to cancel.)
    • CanceledByUser (by someone with a user ID)

Sometimes, a single activity in human sense must be broken down into multiple activities in software implementation. This will have implications on the design of the Graphical User Interface (GUI). In short - GUI can get very complicated.

Example: a business process modeler will regard "wait for email approval" as one activity. Internally, it is broken down into these activities:

  • Format email template and send email with email server.
  • Choice: (both are waiting, but only the first one will become Succeeded, as the other will be promptly set to NotNeeded.)
    • Wait for approval email reply.
    • Wait for disapproval email reply.
  • An exception catcher for timeout.
  • An exception catcher for anything but timeout (e.g. problem with sending the email, or parsing of the approval/disapproval response)

Displaying all these details on the GUI will make it difficult for the user. Instead, the user should only see options that the user intends to configure.

Almost all interactions (dependencies) between activities are modeled as the "Waiting" state.

WaitingOnPreconditions is the simplest type. Simply speaking, it can wait on final states but not states that flip-flop. Usually, it waits for a set of activities to all transition into the "Succeeded" state. (On the opposite side, it can also wait on "any activity that transitions into the "Faulted" state - this makes it an exception catcher.)

Because the inputs to WaitingOnPreconditions are not allowed to flip-flop, the outcome of WaitingOnPreconditions will also not flip-flop. This is the essential distinction between WaitingOnPreconditions and WaitingOnInternalTrigger, described below.

WaitingOnInternalTrigger is more dynamic than WaitingOnPreconditions. It waits on some observable variables on the business process object to change to a certain value, or some other activities to change their states.

Once entered this state, the activity's StateMachine stays there, unless requested (programmatically) to re-check. The check might be performed with a predicate, Func<bool>, or lambda expression.

The business process object contains some variables that have INotifyPropertyChanged interface. When that event is raised (that is, when the variable value is updated), activities that are in this state (WaitingOnInternalTrigger) will be re-checked.

To avoid indeterminacy or deadlock, the re-check is only allowed to use variables which it can observe. Otherwise, nobody will notify the activity of the relevant changes, and the activity will thus stuck in this state forever.

WaitingOnBusinessProcess is used when an activity embeds another business process. That other business process runs somewhat independently (in software sense), and the current activity will wait for it to finish, cancel, or fault.

WaitingOnBusinessProcess is re-checked whenever the business process it is waiting on has changed state.

WaitingOnExternalTrigger is a mechanism to block the activity until it is unblocked by some other means. For example, it might be waiting on some user interaction, or an approval email. Unblocking is done programmatically - not by another activity or business process.

Every WaitingOnExternalTrigger must have an associated exception catcher (mentioned earlier). This is because all external processes are presumably unreliable, e.g. the employee responsible for this business process might be fired on the spot, (or the email server was struck by a disaster) and thus unable to continue the process.

Other references (not used in my answer)

Disclaimer: my employer makes BPMN software. However, I do not work in the BPMN product team, and my answer is not representative of my employer's viewpoint. I do not have any privileged knowledge of the BPMN product.

  • Many thanks for all the effort involved here!!! I think the key for me is to use the state machine as a lower level component than I was attempting to.
    – Paul
    Commented Nov 3, 2013 at 12:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.