This wiki contains Frequently Asked Questions regarding Workflow in SharePoint Server 2013.

Q1: Where can I find the list of resources for workflow in SharePoint Server 2013?
Q2: If a message is picked up by Service Bus, how long does Service Bus wait for the message to be deleted or marked as "processed" before it assumes that something ha failed and it picks up the message again to be reprocessed?
Q3: How many times, or, for how long, will SharePoint attempt to deliver a message to the Workflow Manager Front End?
Q4: What is the implementation that service bus implements for message handling?
Q5: What do I need to do in SharePoint in order to use the Send Email action in workflow?
Q6: How can I monitor the workflow farm once Workflow Manager is installed and processing workflow for SharePoint Server 2013?
Q7: How do I know if there are any Cumulative Updates (CU) for Workflow Manager and Service Bus and how do I install them?
Q8: Do I need to install the CU for Workflow Manager and Service Bus even if I install it using the WebPI link AFTER the CU has been released?
Q9: What tools should I use for developing workflow in Visual Studio 2012 and where can I find them?
Q10: What does the Register-SPWorkflowService cmdlet actually do and what should I know about it?
Q11: How many times should I run the Register-SPWorkflowService cmdlet?
Q12: What is the referenced SharePoint site in the Register-SPWorkflowService cmdlet used for? Should I plan which site to use when running the cmdlet?
Q13: If I add a new Web Application in SharePoint do I need to re-run the Register-SPWorkflowService cmdlet?



Q1: Where can I find the list of resources for workflow in SharePoint Server 2013?
A: http://technet.microsoft.com/en-us/sharepoint/jj556245.aspx


Q2: If a message is picked up by Service Bus, how long does Service Bus wait for the message to be deleted or marked as "processed" before it assumes that something ha failed and it picks up the message again to be reprocessed?
A: If the question is regarding the policies to determine when the message is consumed the answer is that this is determined by the workflow engine based on the retry policy (which is a combination of built-in behaviors in the workflow engine and in the SharePoint activities. From a workflow engine perspective, the messages are stored durably and will actually never expire in Service Bus. There is no amount of time per se that Service Bus is waiting for. Service Bus deletes those messages when they have successfully been processed and the updated workflow instance state has been saved. Activities that fail in unexpected ways while the workflow is processing a message results in the instance becoming suspended and the message being returned to Service Bus.


Q3: How many times, or, for how long, will SharePoint attempt to deliver a message to the Workflow Manager Front End?
A: If the goal is to determine the availability of the workflow layer relative to SharePoint, then that is very much influenced by the deployment topology. 
    - If workflow and SharePoint are co-located on the same SQL database, then the model is pretty much the same as any other service application in SharePoint. In that case, SQL has to be highly available (e.g. mirrored) and SharePoint and Workflow are also highly available via the NLB. If SharePoint is put in read-only mode, there will be no additional transaction traffic going to workflow.
    - If SharePoint and workflow are not co-located, then the option of using MSMQ to buffer messages in the SharePoint farm is available. If you install MSMQ in the CFE, each node will create a local queue on disk. Note: This model is designed for having very short lived messages in the queue as the message store will not participate in the transaction. Long running messages are stored in the Service Bus.


Q4: What is the implementation that service bus implements for message handling?
A: Service Bus implements a peek-lock protocol where a consumer locks a message for a certain amount of time (45 second default) and must either:
    - Call Complete on the message, which deletes it from the queue. The workflow engine does this when it can successfully persist the updated workflow instance state.
    - Call Abandon on the message, which unlocks the message in the queue. The workflow engine does this when encountering an exception in workflow execution.
    - Renew the lock, i.e. if the consumer needs more time. The workflow engine does this automatically via a background thread to allow for long-running execution where necessary (not really that relevant for SharePoint activities since they frequently relinquish control to the runtime for sending outbound messages).
    - Let the lock expire, which unlocks the message in the queue. On a process crash, this would happen.


Q5: What do I need to do in SharePoint in order to use the Send Email action in workflow?
A: You need to setup SharePoint for outbound SMTP. Instructions for doing this can be found here: http://technet.microsoft.com/en-us/library/cc263462.aspx


Q6: How can I monitor the workflow farm once Workflow Manager is installed and processing workflow for SharePoint Server 2013?
A: System Center Operations Manager has a Workflow Management Pack available for monitoring a Workflow Manager farm. For more information see, Microsoft Workflow Manager Management Pack for System Center Operations Manager  and Guide for System Center Management Pack for Workflow Manager.


Q7: How do I know if there are any Cumulative Updates (CU) for Workflow Manager and Service Bus and how do I install them?
A: Yes, Workflow Manager and Service Bus have a CU as of March 7, 2013. You can find and install CU updates by browsing to the Microsoft Download Center and searching for "Workflow Manager" and "Service Bus". The latest CU's will show up in the search along with any other updates for Workflow Manager and Service Bus. Clicking on the link will take you to the Workflow Manager or Service Bus update page with instructions for installing the updates. It is also recommended you install The SharePoint 2013 March CU as well.


Q8: Do I need to install the CU for Workflow Manager and Service Bus even if I install it using the WebPI link AFTER the CU has been released?
A: Yes, the WebPI link does not install the CU automatically. You will need to install Workflow Manager, which installs Service Bus, and then install the CU's. It is also recommended you install the SharePoint 2013 March CU as well.


Q9: What tools should I use for developing workflow in Visual Studio 2012 and where can I find them?
A: Download the Office Developer Tools for Visual Studio 2012 at: http://msdn.microsoft.com/en-us/office/apps/fp123627.aspx


Q10: What does the Register-SPWorkflowService cmdlet actually do and what should I know about it?
A: The Register-SPWorkflowService cmdlet creates a Service Application Proxy which connects the SharePoint farm with Workflow Manager. The cmdlet automatically adds the Workflow Service Application Proxy to the Default proxy group in SharePoint. If you are using a custom proxy group then you will need to add the Workflow Service Application Proxy to the custom group manually using either the Central Administration interface or the Add-SPServiceApplicationProxyGroupMember cmdlet. 


Q11: How many times should I run the Register-SPWorkflowService cmdlet?
A: The Workflow Service Application is farm wide and should generally only be run once. When the Register-SPWorkflowService cmdlet is run a connection to a Workflow Manager farm is created. The connection takes the form of a Workflow Service Application Proxy. The proxy is then used for all Web Applications throughout the SharePoint farm. You can register multiple connections to different Workflow Manager farms using the -PartitionMode flag and then use a custom proxy group to associate different workflow subscriptions to different sites. Note that using the -PartitionMode flag is an advanced scenario and generally not required under most circumstances. After using the -PartitionMode flag you would need to call $wfServiceApplicationProxy.Register cmdlet.


Q12: What is the referenced SharePoint site in the Register-SPWorkflowService cmdlet used for? Should I plan which site to use when running the cmdlet?
A: The referenced SharePoint site in the cmdlet is only to let the cmdlet know how to reference the SharePoint farm. Once the cmdlet has been run the SharePoint site referenced in the Register-SPWorkflowService cmdlet is not important. You can use any current site in the SharePoint farm to run the Register-SPWorkflowService cmdlet.


Q13: If I add a new Web Application in SharePoint do I need to re-run the Register-SPWorkflowService cmdlet?
A: No, the Register-SPWorkflowService cmdlet should only be run once for the entire SharePoint farm. Once a SharePoint farm is associated with Workflow Manager the cmdlet does not need to be run again unless you are restoring SharePoint from a backup.