I struggle with being a SharePoint “developer”…

This is one of those posts that I have to write, as it’s how I deal with things I’m feeling. In this particular case, it’s how I feel about being labeled a SharePoint “developer”. It sort of bubbled up inside me as I was reading various reactions to yesterday’s announcements during the Future Of SharePoint event.

When I hear someone use the word “programmer” or “developer”, I think (as do probably most people) of someone slinging code and spending all day in a IDE like Visual Studio. These are the people who integrate one thing with another using all sorts of code frameworks and protocols. And to be certain, they are worth their weight in gold (provided you can actually talk with them as a normal human being).

But there’s another world of “development” that is where I live. It’s the skillset of taking existing parts of the system (I like using the term “out of the box”) and wiring them together to create solutions for a customer and organization. Yes, a power user could do this, but the vast majority of people who use SharePoint don’t want (or don’t have the skills or mindset) to do that. They want to have someone who understands the software and their issues wire all that up for them. They want a quick solution that’s easy to use, and they don’t give a rat’s a** what is happening behind the scenes. They just want results.

And that’s what I deliver… quick solutions that meet a business need and add value to the organization.

So what’s wrong with that? Well, I’ve technically been a programmer my entire 35+ years in IT. I’ve done time in the COBOL world. I’ve created RPG III programs. I coded rather cool LotusScript agents in Notes. But realistically, I’ve always been the type of developer you could put in front of the business, and that was focused on a solution that could be implemented quickly. But compared to the people I naturally compare myself to (the hardcore developers), I’m pretty much worthless. Or at least that’s what I beat myself up with…

In yesterday’s Future Of SharePoint webcast, I saw a LOT of things that will make a huge difference to how my customers will be able to work. I saw a LOT of things that will be fun to play with, and to hook up to create new solutions. Based on the reactions from others, they saw the same things I did. But there was a number of people who pretty much didn’t care for anything that was announced. In their opinion, it was either not enough or was focused in the wrong area. They didn’t show real code. They were “consumerizing” SharePoint and destroying the abilities of ISVs to add value.

It seemed like most of those people were what I’d consider “real developers.” And so I wonder… am I just not good enough to understand why I shouldn’t be excited? Am I wrong for not being up in arms about the direction of things? Am I following a path that is a dead-end?

Once I pull myself out of that mental spiral, here’s what I come up with…

I’m not an IT Pro, in that I’m not the person who knows all the networking/configuration/etc that comes as being an admin. I’m probably not a “programmer”, in that I don’t sling real code much. I *am* a developer, in that I develop solutions for my organization that make a major difference and add value. I also serve as a SharePoint Help Desk, a technical consultant to the business, a training and adoption driver, and I wear whatever hat is necessary to keep SharePoint (and soon to be Office 365) running and my customers happy.

None of this is an excuse to not learn new skills. That’s a whole different list of things that I beat myself up over on a regular basis. I am a charter member of Imposter Syndrome Anonymous, and I don’t think that will ever go away until I retire or die. I often wonder if I’d be able to find a new job if I had to leave this one for some reason.

But having said all that… I deliver value. I build things. I’m open to being labeled whatever reflects that, whether developer, programmer, engineer, or internal consultant. I’m pragmatic, in that I’m sure there are a number of “flaws” in SharePoint and Office 365 that should be addressed. But I’m excited about where things are at, I’m excited about the direction that Microsoft is going, and I’m excited that I get to play in that sandbox.

And with that, I’ll head back to my happy world of making others happy. It’s how I roll…

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 "http://foo.com/website"
$List = $Web.Lists["LibraryName"] 
$List.AllowDeletion = $TRUE 

Reverting to a SharePoint 2010 default list form once it’s been customized…

20160122Image01.pngSo today’s adventure involved fixing someone’s custom list form that had “broken”. They said that it used to look one way, and then something happened and now it looks different and things at the top of the form are gone. Not a lot to go on, but that’s my job… figure things out based on people explaining issues in terms they understand.

After some thought and observation, I figured out that someone had gone into Customize Form on the list’s Ribbon Bar and saved/published a new version of the form. It’s close to the same look as the default form, but things like the Attach File icon and the buttons at the bottom of the form disappear. I also confirmed that the displayifs.aspx, newifs.aspx, and editifs.aspx versions of the forms (customized versions) were showing up as present in SharePoint Designer.

Now… how do I revert back to the default form?

It was easier than I thought… If you go into List Tools > List > Library Settings, you’ll see an option titled Form Setting under General Settings. When you open that option, select the Use The Default SharePoint Form option, and your customized forms will no longer be the default.


I tried to solve this earlier in the week for someone, and I ended up having to recreate the list from scratch and copy over the data. Obviously, this approach is MUCH easier…

How do you get a home page when you open a SharePoint wiki library?

In short, you make sure there’s a page out there named… Home.

I had a question today related to clicking on a SharePoint wiki library link. The customer wanted the library to open up to a home page, not a view of all the pages in the wiki library. Sounded easy enough, especially when she also sent me a link to a site where someone was doing just that.

Being a dev/tech person, I’m looking for settings for the library to set her Intro page to be the library home page. However, everything I tried would end up setting the Intro page to the SITE home page, not just the wiki library home page.

After considerable searching, I found a passing reference to a behavior that I didn’t know (and I admit I’m not a huge wiki fan). Apparently, if you open a SharePoint wiki library, it will attempt to open a page actually called Home. If it doesn’t find one, it opens the AllPages view of the wiki library.

I tossed a Home page out there, and voila… the library opened to that page. I then asked her to change her Intro page and rename it to Home. Worked like a dream…

Sometimes, we techies over-complicate simple things.🙂


Getting Open In Explorer for a Picture library

Another one of those “I never noticed that before” questions today…

One of my customers wanted to get their pictures out of a Picture library, and said that they couldn’t find the Open In Explorer option in the Ribbon Bar. My first guess is that they were having a problem with the Internet Explorer SharePoint add-ons, but no… there’s basically NOTHING in the Ribbon Bar for a Picture library!

We have Sharegate, and I know I could have exported the Picture library to a file share, and it would have been fine. But still… how could I allow the customer to do that themselves?

A little digging around found an answer in the form of a nice little hack (elegant solution to a problem).

Open a Windows File Explorer window, click in the address bar at the top of the screen, and enter the SharePoint site address in the following format:

For example: \\sharepoint.foo.com\sites\MyTestTeamsite

That opens up the site in Windows File Explorer, and you can drill down into any library that’s out there… including Picture libraries.

I passed along the information, the customer tried it, it worked, and everyone was happy.