I ran into an unexpected issue today working in Quick Edit mode on a SharePoint List. Specifically, I couldn’t add new items based on a custom content type where I’ve hidden the Title column. Quick Edit is requiring a value for the Title column even though I have Hidden it on my Custom Content Type and can add / edit items just fine (i.e. with no Title specified) using the standard List forms.

There’s a bit of setup to this, but please stick with me through the background and demo of the issue. I think this behavior is important for any SharePoint designer to understand. Also, I have a few solutions to the issue, but I don’t want to implement any of them for reasons I explain for each of these potential ideas / work-arounds at the end of this post.

Content Type with Hidden Title Field

I’m writing a blog dedicated to solutions and ideas for using SharePoint in the Personal Trainer space. That blog is basically brand new as of the date I’m writing this post, so I only have a few articles published. Disclaimer aside, one of the most recent articles was based on the idea of creating a “Client” content type and hiding the Title column. As that post explains, the “Title” column does not apply to Clients. At the end of that post, here’s what the Content Type looks like:

Note that the Title field is hidden on the SharePoint content type and also on the list forms.

New List Items Do Not Require the Title Field

Well…not when I add them through the standard New Item form. Here’s a demo:

You can see that the Title field is truly empty if I add it to the view and launch the SharePoint list filter pane:

SharePoint List Quick Edit Mode Requires Title

I found the issue (bug?) when I went to bulk-load some entries for demo purposes using the SharePoint List Quick Edit option. What I’ll demo next is:

• If I don’t have Title in the view then I cannot add new items.
• If I have Title in the view, and I leave it blank, then I cannot add new items.
• If I have Title in the view, and specify a value, then I can successfully add new items.

I also added the “Content Type” field in the view so that you can see it’s definitely adding my custom Client content type:

You see, the only way I can add a new Client type in Quick Edit mode is if I specify Title. Also, as shown at the end, the other items definitely do not have a Title specified. There was no issues adding items that way as long as I use list forms instead of Quick Edit.

Possible Solutions – And Why I Don’t Like Them

Solution 1: Use a formula to set a default value on “Title”, or just set it to ” ” (space).

The main reason I don’t like this solution is because it’s going to mess up Search results. The “Title” field is a primary searchable / queryable / filterable field for Search, and Client items could end up being returned erroneously on unwanted matches against the Title field.

Also, though not so critical, is that this is a waste of storage space. This is trivial, but it just adds on another reason why I don’t like this “solution”.

Solution 2: Stop using “Client Name”. Just rename the Title column to “Client Name”.

This is a User Experience disconnect. Within the list, a user will be filtering by a column they perceive to be named “Client Name”, sorting by a field they perceive to be named “Client Name”, and everything in the view tells them that the name of this column is “Client Name”.

But, now if they want to build a Search Page, they have to build queries, refiners, sort settings, etc. using “Title”.  If they want to setup a Content Search Web Part, they have to remember this nuance that the actual field in the back-end is “Title”.

There’s a big disconnect here.

Solution 3: Go up to the Site Collection settings and modify the Item > Title site column to be optional.

No way.

Conclusion

I’m surprised I’ve not run into this before. I must have never bulk-edited a list that I built from a content type where I hid the Title field.

There’s solutions and work-arounds to the problem, but I don’t like them because they set users up for confusion and a disconnect…especially with Search. I won’t even consider the third solution.

Maybe the answer is right under my nose or in some obvious setting that I’m not seeing. I’d definitely appreciate your feedback in the comments.

Categories: Office 365 and O365, SharePoint

Tags: Office 365 and O365, SharePoint