Here you will find a script to cancel all list workflows (not site workflows) running in a given site collection in the most efficient manner possible (that I can think of) while still only using the SharePoint API. A better approach still would be to query the SharePoint workflows SQL table to identify the running workflows so as to avoid iterating all site collection webs and lists. Unfortunately there is no ‘GetAllRunningWorkflows(SPSite)’ method available via the API. I imagine that this approach should be satisfactory in the majority of cases though.
There are a number of posts on the web with code somewhat similar to this, at least with code that aims to achieve the same outcome. Of all the posts which I found they all performed this function in a very inefficiency manner, iterating the SPListItemCollection for every list in the site collection. This may be fine in many circumstances but I wanted something that would run faster with less strain on the server.
I have achieved this by checking for workflow associations on a list before iterating the items as well querying the list items and where a workflow column exists checking to see if the list item needs to be returned at all. When returning the list items, I am querying with ViewFieldsOnly so that less data is returned.
This script also accepts an optional parameter that specifies which workflow associations should be canceled if you are not looking to cancel all of the workflow associations but just those of a specific name.
NB: The script contains a reference to a help function GetNestedCaml which I have defined in a separate post which can be found here.
As the script sample is quite large I suggest clicking the ‘view raw’ link at the bottom of the sample to view it.
In SharePoint 2013, especially when on Office 365, you probably want to take advantage of Office Web Apps (OWA) to open Office documents (Word, Excel, PowerPoint, etc) in the browser.
EDIT: In SharePoint Online the best way to achieve this is by adding ‘web=1’ as a query string parameter to the file URL. E.g. https://tenant.sharepoint.com/Documents/file.docx?web=1
URL to ‘Open in brower’
A common scenario could be an implementation of the “Feedback (SharePoint 2010)” workflow which creates a task with accompanying email for many users. Some of these users may not be able to open Office documents on their client. Unfortunately, the default email content provides a link which only allows the user to download the document (which they are then unable to view) and provides no link back to the document library to find the document in a more manual fashion. In this particular scenario SharePoint Designer (SPD) is a very useful tool to update the email content with a link that allows users to take advantage of OWA. I am not going to go into how to update the workflow using SPD, I will only discuss the link URL format itself.
The URL format you are looking for is: <Site URL>/_layouts/15/WopiFrame.aspx?sourcedoc=<Doc URL>&action=default
Some things of note:
If you inspect the href of a document in a library you will notice that the sourcedoc parameter is not a URL but GUID. This GUID is NOT the unique ID of the document. Providing the unique ID of the document instead of the URL will fail (or potentially display another document).
You can provide either an absolute URL or a server relative URL for the source doc, and ensure it is encoded.
In case you are using SPD the link address you want is: [%Workflow Context:Current Site URL%]/_layouts/15/WopiFrame.aspx?sourcedoc=[%Current Item:Encoded Absolute URL%]&action=default
EDIT 31/30/2015: I’ve been advised by a colleague that this only works when the Site URL and Doc URL are both relative to the same site. This appears to be true in SharePoint Online, however I am almost certain this was not an issue when I wrote this article (I no longer have access to that environment).
A custom SharePoint 2010 workflow which I wrote was occasionally failing (perhaps 1 in 10) when auto-starting upon the addition of list item with a ‘Failed on start (retrying)‘ status. I’ve dealt with this error in the past and it is almost always caused by invalid workflow code (bad correlation tokens etc, there’s plenty about this elsewhere) but in those cases the failure is consistent.
Looking into the logs I found an unexpected error: “AutoStart Workflow: System.ArgumentException: New instances of this workflow template are currently disallowed“. The workflow association was NOT set to ‘no new instances’. In the case of my particular workflow, it was performing a considerable amount of work upon start including creating a dynamic amount of tasks that in most cases counted more than twenty.
With a lack of other options I modified the workflow with a delay immediately after start so that the workflow would sleep and then create tasks at the next timer interval. The error still intermittently appears in the logs but the workflow runs anyway (I believe it fails to run during the first timer interval when this happens, but retries at the next at which it works). Clearly this solution is not ideal, but has resolved my issue from a functional perspective.
If I come across a more elegant solution or any functional problems with this solution I’ll be sure to update this post. Good luck.
