Monthly Archives: April 2016

How we fixed the “Failed to render Wiki Content column” error

This is one of those errors that doesn’t have a lot of history to pull from if you Google/Bing it to find help. I’m putting this one out here to help rectify that in some small way.

We have a site where we built a small custom list and then customized the form in InfoPath. As part of that form, we had a formatting rule that used pattern matching in order to hide a section. This was used to get a form of validation on a People Picker column.

All was going well until we embedded the form in a wiki page using an InfoPath Form web part. Then all hell broke loose. The page (AND the form) started returning this error:

Failed to render “Wiki Content” column because of an error in the “Multiple lines of text” field type control. See details in log. Exception message: Function ‘xdUtil:Match()’ has failed..

The form was easy and fast enough to rebuild when it appeared the first time. But when the form and page broke again later in the day, we knew that something had to be done. Breaking and rebuilding the form every time you want to change it really isn’t very scalable. 🙂

The xdUtil:Match portion of the error seemed to point to some type of issue with pattern matching. We wondered if perhaps the pattern matching rule we had in the form wasn’t playing well in an embedded form scenario. Once we removed that rule from the form and republished it, everything returned to normal and our problem was resolved.

While I still don’t know the details of why that broke the page and for what reason, I’m happy enough to live with “don’t do that ever again” when it comes to this situation… especially since I found a way to get the same formatting rule in place using something other than pattern matching.


The pesky “The workflow could not update the item” error

Recently, Sandra (my SharePointBuddy) and I built a peer-to-peer recognition site on SharePoint, and it’s really cool. However, we had a couple scenarios where the notification workflow would error out with the following message:

The workflow could not update the item, possibly because one or more columns for the item require a different type of information.


If you’ve run into this issue and done any research, you know that there is no set answer for how to resolve it. Furthermore, many of the answers are “I did this and it started working again, but I don’t know why.” And of course, none of these answers addressed our problem.

After a few days of trying to figure out the “why” behind our particular variation of this, we finally stumbled across the issue.

The recipient of this particular “High Five” had a regular and a test AD account. Unlike most of the test account scenarios, his test account had his regular name with all the associated data fields filled in. When the workflow got to a point where it was trying to build a new list item, we were using the “Display Name” variation of the Recipient People Picker field for the email address. Unfortunately, the Display Name for this person’s account was not unique, so SharePoint Designer was choking on a multi-value data field that was only supposed to be a single-value occurrence.

Once we figured that out, we changed all the usages of that field to use the Login Name (which *was* unique), and then the workflow worked just fine.

I put this out here so that anyone trawling for an answer has at least one more option to choose from…

Fixing the AllowDeletion flag on a SharePoint list or library

Today is the second time I ran into this issue, and I figure I better post it out there before I once again forget how to solve it…

I got a call from one of my customers saying that they didn’t have the option to delete a document library from Library Settings. Odd, as they had full control permissions for the site. When I looked (and I’m basically God when it comes to permissions), I didn’t have it either.

After some digging around, I found that there’s a setting called AllowDeletion that you can manipulate to keep someone from deleting a list or library. I’m still not entirely sure *how* that got get set to false in this case, but it was.

Following is a short PowerShell script you can use to fix that. The actual deletion of the library is commented out here, because I’d prefer just to set the flag and then delete it myself… less chance of something going wrong that way. 🙂

#This allows you to delete a list or library where the AllowDeletion flag has been turned off...
#Load SharePoint PowerShell Snapin
if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null) {
    Add-PSSnapin "Microsoft.SharePoint.PowerShell"
$Web = Get-SPWeb ""
$List = $Web.Lists["LibraryName"] 
$List.AllowDeletion = $TRUE