I’ve made two posts about this in the past: one about running previous versions of workflows and another about workflows not publishing.
In the first post, I discovered that when running workflows in the 2010 platform previous versions may need to be deleted; in the second, I found that the activity cache on your local machine can prevent new versions of your workflow from being published.
This post is related. If a workflow fails to run with the error: something went wrong to try again reload the page and the start the workflow, you may need to restart two services. To do so check the server SharePoint is on and look for the two services:
- Service Bus Gateway
- Service Bus Manager Broker
If either of these services is stopped, restart them and try to rerun your workflow.
So this can be incredibly frustrating. You update a workflow, save it without errors and then publish, but the next time the workflow runs your changes aren’t there and it’s running an older version. I have a post about dealing with an issue like this, but after following my own advice and clearing out the previous versions, I still had the same problem . I stumbled upon this blog post that explains the problem. There is a SPD activity cache for your local machine and clearing that out will solve the problem.
The path for me on 64 bit Windows 7 looks like this: %System Drive%\Users\%user name%\AppData\Local\Microsoft\WebsiteCache. Inside that directory there was a folder for each SharePoint site I have worked on and occasionally an identically folder with “01” or “02” after the name. All of these directories can be deleted. Make sure you have closed SPD designer before deleting the directories, then reopen designer and publish a workflow.
I recently had a requirement to have a choice column with check boxes and have all options selected by default. After a little hunting I came across the syntax which is rather easy:
In the default value box, select Calculated Value and enter the above.
This leads to check boxes being selected on item created.
Stumbled upon this post when trying to use the ULS logger to see an error:
See the blog above for full details but here is a simplified way to get an error:
1. Get correlation id from window
2. in PowerShell (run the following commands):
Merge-SPLogFile -Path “.\error[x].log” -Correlation “85ea729c-071c-d0b1-d6c7-065c6284a50f”
I name my log errorx where x is a number and delete them after I I’m done.
Saves to C:\Users\ [your user name]
3. Open ULS Viewer > Open File and select error[x].log
Way easier than hunting through ULS logs.
By default Content Query Web Parts (CQWP) don’t display any text on a page when no results are returned. The message is only displayed in “edit mode” when a content manager or developer is editing the page. This can be frustrating because you might want to display a message that says that nothing has been returned. In my case we wanted to query a calendar for upcoming events that meet some conditions and a message if there wasn’t any. The solution is simple:
1. Open Designer and your root site collection (http:// [site collection name])
2. Select All Files > Style Library > XSL Style Sheets
3. Open ContentQueryMain.xsl (good idea to make a copy called custom)
4. Look for the item template OuterTemplate.Empty:
Note the xsl:if tag that indicates that the message will only be shown when in edit mode. Add a custom message above.
Recently, we upgraded to SharePoint 2013 from SharePoint 2010 and one of the strangest things that happened in the transition was several workflows were running incorrectly. Simple solution: recreate them.
Thankfully none were too complex and were recreated quickly. Our most important workflow is arguably a feedback workflow that allows users to click on a “Contribute Feedback” link at the bottom of every page. There are two workflows attached to this list: Feedback and FeedbackClosed. Feedback runs on Item Created and captures the user who created the item, the page they are on (which the feedback applies to), the message in the feedback, the category (typo, missing information, incorrect information, etc.) and the urgency (Low, High). This workflow sends an email to our dev team with links to the page the feedback applies to and the feedback record.
Feedback also contains a status field and the dev team can change this to completed which triggers the FeedbackClosed workflow and sends a response to everyone on the dev team and the user who created the item with a message of the resolution.
The issue was during recreating the Feedback workflow I misspelled Feedbacik, so I ran the workflow and then saw this in the email: . So I opened the workflow in SharePoint Designer and corrected it. I saved and published and created a test workflow to see the same problem: . After a few hours of trying to figure this I realized the mistake I made. I navigated to the Feedback list and selected Workflow settings to see about twenty previous versions on this page as well as my Feedback current version that I wanted to run. I selected “Remove” for all previous version and “Allow” for the current version. This ran the correct version.
TL;DR: If previous version of workflows are running navigate to the list > Workflow settings and remove all previous versions.
Lately, for me, it seems we have to come up with creative solutions around SharePoint constraints. Recently, I found a quick way to display the attachments column of list in a Data View:
<xsl:attribute name=”ItemId”><xsl:value-of select=”@ID”/></xsl:attribute>
The result is a clean Data View with all attachments for that list item shown. Quick trick to make sure attachments are displayed when you might need them.