The workflow framework in SharePoint 2013 is significantly changed from the previous versions. The following sections provide brief summaries of the most significant updates and enhancements to the workflow infrastructure. SharePoint 2013 workflows are powered by Windows Workflow Foundation 4 (WF), which was substantially redesigned from previous versions. Windows Workflow Foundation, in turn, is built on the messaging functionality that is provided by Windows Communication Foundation (WCF).

Perhaps the most prominent feature of the new workflow infrastructure is the introduction of Microsoft Azure as the new workflow execution host. The workflow execution engine now lives outside of SharePoint, in Microsoft Azure.

Another of the prominent changes is that workflows on the WF 4 platform are fully declarative. That is, workflows are no longer compiled into managed assemblies and deployed to an assembly cache. Instead, XAML files define your workflows and frame their execution.

So SharePoint 2013 workflows are completely declarative. Means, No code. Wow! Isn’t that awesome? Then your workflow development journey should be a smooth drive. Just drag and drop, build your workflow, deploy it and Job done!

It all looks like a cakewalk!!!! Isn’t it?

No…But it is definitely not that easy. I have done extensive SharePoint 2013 Visual studio Workflow development and here are the pains I have gone through. Via this blog I want to make the developers’ life easy and disclosing solutions for some of the common issues that crops up.

Things go wrong while developing SharePoint 2013 Workflows (high level)

List GUID not referenced

Reason:

GUID of the list is not retrieved properly by the workflow after selecting the list name from the dropdown. Exception as in the screenshot:

Solution1:

Add the list url as a property in elements.xml to all the associations for which the workflow should be triggered.
Example: Manual start, Item Added, Item Updated
Entry:
;}”/>

Solution2:

Get the list GUID via REST API call

Dlls that drive you crazy

There are 2 Dlls which may make your workflow fail in any other environment other than dev server (where Visual studio is not installed)

1. Microsoft.SharePoint.DesignTime.Activities.dll
2. Microsoft.SharePoint.DesignTime.Activities.Design.dll

Exception:

System.Runtime.InteropServices.COMException: 0x81020089Microsoft.Workflow.Client.ActivityNotFoundException: The activity named ‘WorkflowXaml_8aee245d_2683_4bf2_aaef_099471b37a40’ from scope ‘/SharePoint/default/5c3cc640-0769-40e4-b474-466218d420bd/5c6c812e-59c7-439d-9d17-3fc9018dbfe1’ was not found. HTTP headers received from the server – ActivityId: 6122ef7d-1c9c-439d-a8ae-4f914a5f99b6. NodeId: HFSP2013STG01. Scope: /SharePoint/default/5c3cc640-0769-40e4-b474-466218d420bd/5c6c812e-59c7-439d-9d17-3fc9018dbfe1

Reason:

Microsoft Product Bug

The path for the references by default is as below:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\PublicAssemblies
Any environment where the visual studio is not installed will fail to execute the workflow.

Solution:
Either of the below solutions
• Copy the dlls to Bin folder and reference it from there
Create a folder to form the above path and place the dlls in that folder

Updates do not reflect when I deploy the workflow – Farm Solutions

• Add new activity or do any changes to existing workflow and deploy the solution. The changes do not reflect if I start a new workflow.

Reason:

SharePoint site collection keeps workflow definition in the store even after removal of workflow association from list and feature deactivation.

Solution:
Development Server (deployment using Visual studio)
Configure the Pre deployment command as below:
tasklist /FI “IMAGENAME eq vssphost5.exe” 2>NUL | find /I /N “vssphost5.exe”>NUL if “%ERRORLEVEL%”==”0” taskkill /f /im vssphost5.exe exit 0
Staging/Production Server : Perform the below steps
• Remove the WF association from list(Recommended only for DEV or QA). For production, it stands good only before any instances of workflow are created
• Deactivate the associated feature Workflow_feature from the Site/web
• Remove workflow association using SharePoint designer
• Retract and uninstall the solution
• Run a console to remove the WF definition from the SPSite. Pass following parameters in order
• Site URL: http://<servername:port>
• GUID: ded935ab115e4949a0980b4e261f4a74

Freshly add and deploy the workflow package

Task Email Not sent if Task is assigned to a SharePoint group

• Scenario: You have many tasks that are sending out emails in the workflow, however only the tasks that has an individual user assigned are sending emails and the SP Group assigned tasks are not sending out emails.
Reason: The workflow initiator does not have visibility to the members of the assigned group. (Yes! even the user ‘System Account’ will not have access).
Solution: Go to the respective SharePoint group -> Settings and change the settings as shown below and the emails will be sent.

Error when Sending Email

Reason:

Sometimes “SendEmailActivity” does not parse when we pass the email id as parameter. It gives the following error even though the user’s Email ID is valid.

Solution:

Pass the complete display name/login name as input to this activity instead of passing Email ID

Token Service Issue

• Restart the “refresh Trusted security token service” and do an iisreset

Sending Custom Task Email after Task Creation

• What if you do not want to use the OOTB task email and want to send a custom email after task creation? – Unfortunately there will be 2 emails sent out.
Reason:

• There is no way to stop the email sent by “Single Task” or “Multi Task” activity in workflow. Only reminder emails can be stopped and not assignment emails. Hence, when we use “Send Email” activity for custom email, we end up sending 2 emails, one from task activity and one from “Send Email” activity.

Solution (Probably a work around):

Set transport rule in exchange server to filter by email by subject. Subject should be specific to that particular workflow so that no task emails from other workflows will be stopped.

New Transporter rule – Exchange Server
Subject should be so that any other out of the box task emails should not be stopped for any other workflows

For detailed list of issues and their analysis while developing SharePoint 2013 workflows, stay tuned for my next blog post which is coming soon…