forge

GETting SPWorkflowManager.StartWorkflow()

Sometimes when you start a workflow you need to collect information user in order to make sure that the workflow has all of the information it needs to start.  Perhaps it needs to know the people to send the document to for approval, or perhaps it’s something simpler like the due date.  That’s what the workflow initiation form is for.  It’s designed to capture the data necessary to get a workflow going.

However, what happens if you already have all of the information that you need to start the workflow.  The user has entered a due date into a field in the item, or you’re fetching the list of approvers from a third party system.  When you hit the workflow initiation page you’re ready to start the workflow and move on – without prompting the user.  The net effect is that they only see the initiation form when they need to provide information or confirm something which is ambiguous.

Help Your SharePoint User

This a great idea, but out of the box with SharePoint and Workflow it won’t work.  You’re going to have to do a workaround.  There’s a design limitation that prevents you from calling the StartWorkflow() method of the SPWorkflowManager from a HTTP GET.  It only expects to be called from a HTTP POST and because of that you won’t be able to directly start the workflow even if all of the information is available to you.  If you’re thinking that you should be able to do it if you use SPSite.AllowUnsafeUpdates – you’re right you SHOULD.  However, it doesn’t work that way.

The work around is to cause the form to post back to itself, say through JavaScript.  You’ll end up with one more round trip between the browser and the server, but it will allow you to effectively hide the workflow initiation form when the user doesn’t need to enter any information.