List GUID not referenced GUID of the list is not retrieved properly by the workflow after selecting the list name from the dropdown. Exception as in the screenshot:<\/p>\n\n\n Solution1:<\/strong><\/p>\n\n\n\n Add the list url as a property in elements.xml to all the associations for which the workflow should be triggered. Solution2:<\/strong><\/p>\n\n\n\n Get the list GUID via REST API call<\/p>\n\n\n\n Dlls that drive you crazy 1. Microsoft.SharePoint.DesignTime.Activities.dll Exception<\/strong>:<\/p>\n\n\n\n System.Runtime.InteropServices.COMException: 0x81020089Microsoft.Workflow.Client.ActivityNotFoundException: The activity named \u2018WorkflowXaml_8aee245d_2683_4bf2_aaef_099471b37a40\u2019 from scope \u2018\/SharePoint\/default\/5c3cc640-0769-40e4-b474-466218d420bd\/5c6c812e-59c7-439d-9d17-3fc9018dbfe1\u2019 was not found. HTTP headers received from the server \u2013 ActivityId: 6122ef7d-1c9c-439d-a8ae-4f914a5f99b6. NodeId: HFSP2013STG01. Scope: \/SharePoint\/default\/5c3cc640-0769-40e4-b474-466218d420bd\/5c6c812e-59c7-439d-9d17-3fc9018dbfe1<\/p>\n\n\n\n Reason<\/strong>:<\/p>\n\n\n\n Microsoft Product Bug<\/p>\n\n\n\n The path for the references by default is as below: Solution<\/strong>: Updates do not reflect when I deploy the workflow \u2013 Farm Solutions<\/strong><\/p>\n\n\n\n \u2022 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.<\/p>\n\n\n\n Reason<\/strong>:<\/p>\n\n\n\n SharePoint site collection keeps workflow definition in the store even after removal of workflow association from list and feature deactivation.<\/p>\n\n\n\n Solution<\/strong>: Freshly add and deploy the workflow package<\/p>\n\n\n\n Task Email Not sent if Task is assigned to a SharePoint group Error when Sending Email<\/strong><\/p>\n\n\n\n Reason<\/strong>:<\/p>\n\n\n\n Sometimes \u201cSendEmailActivity\u201d does not parse when we pass the email id as parameter. It gives the following error even though the user\u2019s Email ID is valid.<\/p>\n\n\n Solution<\/strong>:<\/p>\n\n\n\n Pass the complete display name\/login name as input to this activity instead of passing Email ID<\/p>\n\n\n\n Token Service Issue Sending Custom Task Email after Task Creation \u2022 There is no way to stop the email sent by \u201cSingle Task\u201d or \u201cMulti Task\u201d activity in workflow. Only reminder emails can be stopped and not assignment emails. Hence, when we use \u201cSend Email\u201d activity for custom email, we end up sending 2 emails, one from task activity and one from \u201cSend Email\u201d activity.<\/p>\n\n\n\n Solution <\/strong>(Probably a work around):<\/p>\n\n\n\n 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.<\/p>\n\n\n\n New Transporter rule \u2013 Exchange Server For detailed list of issues and their analysis while developing SharePoint 2013 workflows, stay tuned for my next blog post which is coming soon\u2026<\/p>\n","protected":false},"excerpt":{"rendered":"
<\/strong>
Reason<\/strong>:<\/p>\n\n\n\n![\"\"](\"https:\/\/viewmyprojects.com\/winwirewp\/wp-content\/uploads\/2023\/11\/vijaya.webp\")
<\/figure><\/div>\n\n\n
Example: Manual start, Item Added, Item Updated
Entry:
;}\u201d\/><\/p>\n\n\n\n
<\/strong>
There are 2 Dlls which may make your workflow fail in any other environment other than dev server (where Visual studio is not installed)<\/p>\n\n\n\n
2. Microsoft.SharePoint.DesignTime.Activities.Design.dll<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Either of the below solutions
\u2022 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<\/p>\n\n\n\n
Development Server (deployment using Visual studio)
Configure the Pre deployment command as below:
tasklist \/FI \u201cIMAGENAME eq vssphost5.exe\u201d 2>NUL | find \/I \/N \u201cvssphost5.exe\u201d>NUL if \u201c%ERRORLEVEL%\u201d==\u201d0\u201d taskkill \/f \/im vssphost5.exe exit 0
Staging\/Production Server : Perform the below steps
\u2022 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
\u2022 Deactivate the associated feature Workflow_feature from the Site\/web
\u2022 Remove workflow association using SharePoint designer
\u2022 Retract and uninstall the solution
\u2022 Run a console to remove the WF definition from the SPSite. Pass following parameters in order
\u2022 Site URL: http:\/\/<servername:port>
\u2022 GUID: ded935ab115e4949a0980b4e261f4a74<\/p>\n\n\n\n
<\/strong>
\u2022 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<\/strong>: The workflow initiator does not have visibility to the members of the assigned group. (Yes! even the user \u2018System Account\u2019 will not have access).
Solution<\/strong>: Go to the respective SharePoint group -> Settings and change the settings as shown below and the emails will be sent.<\/p>\n\n\n![\"\"](\"https:\/\/viewmyprojects.com\/winwirewp\/wp-content\/uploads\/2023\/11\/vijaya2.webp\")
<\/figure><\/div>\n\n\n![\"\"](\"https:\/\/viewmyprojects.com\/winwirewp\/wp-content\/uploads\/2023\/11\/vijaya3.webp\")
<\/figure><\/div>\n\n\n
<\/strong>
\u2022 Restart the \u201crefresh Trusted security token service\u201d and do an iisreset<\/strong><\/p>\n\n\n![\"\"](\"https:\/\/viewmyprojects.com\/winwirewp\/wp-content\/uploads\/2023\/11\/vijaya-4.webp\")
<\/figure><\/div>\n\n\n
<\/strong>
\u2022 What if you do not want to use the OOTB task email and want to send a custom email after task creation? \u2013 Unfortunately there will be 2 emails sent out.
Reason<\/strong>:<\/p>\n\n\n\n
Subject should be so that any other out of the box task emails should not be stopped for any other workflows<\/p>\n\n\n\n