Using WF4 to build "work queues" and user assignments? Similar to SP2010

Question

[I appreciate this is a little subjective - but there must be people out there who have knowledge of writing systems to handle this type of requirement. Note: we use C#, .Net4 and have SP2010]

I've been evaluating SharePoint2010 and WF4 for custom business applications, involving workflows, that also require back-end system interaction.

(There is also the option of neither SP2010 or WF4 and just writing status changes to DB and writing straight windows services to do any automated stages.)

SP2010 is proving a very steep learning curve and restricted functionality for most of the requirements...however, for the workflow part and especially the "Lists and Tasks" it excels, and the ease of implementing a new List with accompanying security is a bonus.

So, is there a way to emulate some of this functionality in WF4?

Idea

MVC3 application, user's AD group determines what "queues" and functions they can perform.
User can see their own requests and their status etc.

WF4 service(s) to host the workflows, some steps of which are automatic.

Example 1

User NormalPerson (NP) opens site, clicks on "Create New Request"

Form allows them to look up data from back-end system (thousands of rows, SP2010 seriously struggles with this, especially as it requires multiple searches and filters/sorting - however, jQuery+DataTables+Ajax makes this simple)

NP saves the Request

WF4 "gets" the request, sets as "Needs Approval", sends email to BackOffice (BO) group and persists to DB (through BLL interaction)

BO user can open site and see list of "new Requests", opens one and approves it.

WF4 "gets" the change in a field, sends email to NP and Case Management group, persists to DB.

CM user opens list of "Awaiting Action" and performs the actions (which also update back-end system), sets to Completed.

WF4 "gets" the change and sends confirmation to NP, archives the request.

Example 2

NP creates new request

WF4 sends email, sets "Needs Approval"

BO user finds new request in list, opens but Rejects

WF4 sends email to NP with link to request

NP opens link, amends request, saves

WF4 sends "updated" email to Bo group and marks as Re-Submitted

BO user opens "re-submitted" list, picks item and sets to "Needs Manager Approval"

WF4 sends manager email

Manager sees item in his list, opens and Approves.

WF4 sends email to CM group.....carry on as before.

Example 3

NP saves new Request

WF4 gets request, its under limits so straight to "CM" with appropriate emails

CM user picks up........carry on as before.

Example 4

NP saves new Request

WF4 gets request, its doesn't require any manual intervention, so updates back-end system (BLL/WCF calls etc.) and sets to "Completed" with emails etc.

CM user picks up........carry on as before.

Example 5

NP saves new request

WF4 gets request, sends emails and leaves as "Requires Approval"

NP opens request and cancels it before anyone can work on it.

WF4 gets the change and moves item to "cancelled".

Answer 1

From the examples you give, I think you could solve this problem using WF4. WF4 offers great transaction control as well as flow-control capabilities:

• For every new request a NP starts, a new instance of a Workflow is created.
• Each step (NP submits a request, BO approves it, etc.) is enclosed in a Transaction scope, thus ensuring the data involved in the step is saved to the DB, independently of the outcome of subsequent steps.
• After each step, the workflow is persisted to the DB (be careful with session data you use inside the WF here)
• When a new step is started, the same instance of the workflow is raised from the DB, thus making the process unique.
• Sending email notifications would just be and Activity that encapsulates the use of your SMTP server (C# has built in objects and methods for this).

There's a limitation on SP2010, it's based on the .NET 3.5 implementation of the workflow engine (SP2013 is supposed to have support for .NET 4.5). The way I'd approach it would be with SOA. WF4 integrates easily with Windows Communications Foundation thanks to Workflow Services (which are normal workflows, except that they are wrapped in activities that implement WCF functionality). With workflow services, you expose the workflows through WCF, which means you can consume the workflows as if they were services, and do it from SP2010 or create your own SP2010 workflow host and run the WF from SP Workflows (not completely sure about that last thing, but I believe it's possible).

So, combining both WF4 and WCF you can build a solution that works the way you want. Of course, the design of your solution depends not only on WF4 and how you use it, but I think it's a good option. It also gives you the opportunity to abstract the processes from any client (MVC, mobile, etc.).

If you don't want to go with services and all the additional considerations of implementing WCF, this approach is not what you want, I'm just pointing it is possible.

Hope this helps.