Get Current State

Jun 28, 2010 at 11:44 AM


is there a way to retrieve the current state of a workflow foundation 4 state machine. I'm looking for something similar to myWorkflowApplication.CurrentState.

Using Workflow Persistence, is there a way to select all persisted workflows that have a specific state?



Jun 29, 2010 at 2:21 AM

No, we didn't support GetCurrentState in this release. You could implement a StateMachineExtension, together with a customized activity to provide such a functionality.  The customized activity will be put into Entry action of each State. When the customized activity is executed, it will update the current state info stored in StateMachineExtension.  Then, you could get current state info from StateMachineExtension. If you need current info be persisted, your StateMachineExtension must inherit from PersistenceParticipant.

To find all workflows that have a specific state, you need store customized info via promoted values. These values can be queried and used to identify workflow instances which contain a specific state.

Sep 21, 2010 at 1:54 PM

@manfredsteyer i tried with PromotedProperties to do it.. 

Sep 22, 2010 at 3:41 PM
Edited Nov 11, 2011 at 12:00 AM


Oct 3, 2011 at 5:14 PM

The suggested workaround is logically correct but there is a simpler way than extensions. Just add a normal variable to the root set via the built-in assign activity on each state entry, marking it as "Mapped" then you can pull it out during your existing persistence participant or custom store instance.

When is this basic functionality going to be refactored in then? Can't imagine why it was left out. Would have been the first property written on my design whiteboard. Come on, state machines are typically long running that means status GUIs and reports which means getting the current state is an essential design requirement.

Secondly the "one way" transitions are annoying (each state change has just a condition to stop it, not to "pick" different routes). What about the approve/reject scenario common in state machines, which should have an IF/Then/Else able to SET the current state based on the approval. For now I have to have two different messages (approve or reject) with almost the same content. The "approval" (decision) is only one action so should only have one message, otherwise logic is stuck outside the workflow which should conceptually live inside (whether to call approve or reject based on certain properties of the decision).

Please consider one of these design improvements in a future release:

  1. Expose a CurrentState property.
  2. Separate events and state transitions like in WF 3.5 allowing access to SetState at any time.
  3. If you don't like #2, then at least change the event handler to allow the possibility to "switch" over one or more states. Something like an EventArgs "Continue" boolean and "NextState" string or Activity reference.



Oct 4, 2011 at 4:14 PM

Thanks for your feedback - we have created a new UserVoice forum for Workflow Foundation at

I've created a suggestion based on your message

- Provide a way to get the current state from a State Machine (persisted or in memory)

In your second comment you can have one trigger that invokes an expression and then goes to a different destination (I've included this in the StateMachine Hands On Lab)

I agree that accessing the current state is important and we want to consider how to get this done.

Nov 10, 2011 at 7:56 PM

Im new to WF and State Machines.  @CodeChief, where do i mark it as "Mapped".  More to the point, i don't quite understand how you're are setting current state in the state entry.  Can we get a sample app that shows this?  

This is kind of a deal killer for me. I would like to use WF with our Silverlight app, but it seams it is not quite ready.  Is there any labs on persistence and re-initializing workflow via Silverlight? 

Nov 21, 2011 at 7:08 PM
Edited Nov 21, 2011 at 11:18 PM
zuben wrote:

Im new to WF and State Machines.  @CodeChief, where do i mark it as "Mapped".  More to the point, i don't quite understand how you're are setting current state in the state entry.  Can we get a sample app that shows this?  

This is kind of a deal killer for me. I would like to use WF with our Silverlight app, but it seams it is not quite ready.  Is there any labs on persistence and re-initializing workflow via Silverlight? 

The "Mapped" setting is hidden in the properties window.

You will need to write a custom persistence participant to get it out. Don't get into writing your own store because that will end in a lot of pain I can tell you. More work is needed there! Hopefully WF5 will have nice CRUD base classes we can simply decide how and where to store our data with.

A much simpler suggestion, considering the state machine does not even save the current state name (crazy but true), is to:

1) Don't use the platform update 1 because the state machine does not add any external value because of lack of state name. Less deployment issues then for same benefits.

2) You will have to write out the state of your workflows to use it for display during long running workflows, so just write out the other variables you are interested at the same time, e.g. a copy of the current order form or whatever the workflow is logically processing from start to finish.

This way you avoid all the pain and get the simplest solution.

Silverlight has no workflow, but is a web service client. You communicate with workflows via web services too, like you are probably already doing (at least REST-fully) if your Silverlight app is exchanging any kind of state with it's web server (is anything more than a flash animation or stand-alone game/demo).

Keep your Silverlight app calling a web service business tier (separate class with all your rules in straight flat coded) following the n-tier paradigm. You will save a lot of pain, get your solution to market quicker and MAYBE when WF5 is out can shift your business tier logic into a workflow if there is any value of that.

The workflow designer is great and there is no problem with designing, saving or loading workflows as XAML. But the infrastructure behind it still puts brick walls in your way, at least fewer than WF3.5 but some pretty major ones, need I say the dreaded "versioning" word! The workflow service host wants to persist the workflow "tree" inside an internal class, you have no chance of fixing up. So any change to the workflow hierarchy which affects a persist point means broken workflow again. And don't ask where the rules engine has gone.

I see the benefit of workflow as it forces your logic to be visual like a diagram (customer design friendly) but mainly separate to the main gunk of code, so business rules are forced to be separate and not hidden away in various subroutines of different parts of your code. That makes it dynamic and easy to edit (if it weren't for the versioning issue). Of course "code activities" are still there so it's sure in practice bad designs will just hack in loads of code again anyway. So there you go. Nice idea, but...

If you want to avoid workflow, perhaps you do this already; just make sure you have a clean SOA n-tier design and religiously separate anything which looks like a rule into this tier, even a silly little function if it is really a business rule. Make your business tier a WCF service (like it would be if it were a workflow) then you have a migration path to switch the inside of this black box to workflow 5 or some other open source workflow engine perhaps. Wait for an indication that MS have dealt with versioning and added a rules engine, then perhaps come back.

Sorry no time to write code samples. Don't want to gloat but I have my own SQL persistence store and XML based rules engine which works after a month of work under extreme pressure, so I know what I am talking about. That work belongs to a customer so I can't share it but will get around to writing a different base class/sample anyone can use as a MSDN or Code Project article in the near future because I feel WF still has promise and I want to help.

In my case the customer has over 300 rules which change regularly and reference one another (hence the need for a rules engine) and a system in which many other workflows are foreseen, so workflow was the right choice in this case. I got it working properly in WF3.5 and now 4, but it was not easy both times and never "did what it said on the tin". Surprisingly WF 4 was even harder which is really strange because it promised to solve all the issues of WF 3.5. The main reason for that was lack of documentation (specifically behaviour and really complete samples, like you seek) and over complicated design of the WF infrastructure.