Office 365 Update Changes ‘Display Name’ on Required Fields

3 minute read

Observant SPServices user GregRT noticed something on Office365 today that I figured couldn’t be true. He posted the following in the discussions on the SPServices Codeplex site:

FYI – I had left my debug on.
Users were getting errors on there forms that a field could not be found by SPServices.
MSFT has changed the display name of required fields when it lands in the DOM. I had a cascade going from parentColumn ‘Division’ to childColumn ‘SalesCenter’ (both required fields) – working last week with the display names as ‘Divison’ and ‘SalesCenter’ … now when the form renders in the DOM the display names are ‘Division Required Field’ and ‘SalesCenter Required Field’ – no indication in the UI that this is modified.
Hope this helps someone!

My first reaction was to question whether this could be right.

For years, we’ve been able to reliably select a regular dropdown (select) easily by using the column’s Title. The markup has looked something like this (depending on SharePoint version):

<select id="Region_59566f6f-1c3b-4efb-9b7b-6dbc35fe3b0a_$LookupField" title="Region">

2014-01-23_14-39-44so we could use a jQuery selector like this:

var regionSelect = $("select[Title='Region']");

However, GregT is right. In one of my demo sites on Office365, when I set a the Region column to required I’m seeing this markup instead:

<select id="Region_59566f6f-1c3b-4efb-9b7b-6dbc35fe3b0a_$LookupField" title="Region Required Field">

2014-01-23_14-40-50I expect this will be a problem not just for everyone using SPServices, but for many custom scripts as well.

Not only does this become a breaking change, it’s just plain bad practice.

If you run into this issue, a quick fix solution would be:

var regionSelect = $("select[Title='Region'], select[Title='Region Required Field']");

It’s not enough for your selector to look for a Title which *starts* with ‘Region’; you might have a column called ‘Region2’ or ‘Regions’ as well, so you’d get false positives.

I’ll see if I can find out any more details on why this may have happened and whether it’s permanent. Ugh.

[notice]2014-01-24 8pm EST – Based on info from Christophe below and several others, the issue seems to arise somewhere between vti_buildversion:SR|16.0.2308.1208 and vti_buildversion:SR|16.0.2510.1204. You can check your version by going to  /_vti_pvt/buildversion.cnf in your Offic365 tenant. See:[/notice]

[notice]2014-01-24 11pm EST – The PG reached out to me and they are investigating the issue. I’ll post more info as I get it.[/notice]

[notice]2014-01-31 9am EST – Based on the information I’ve gotten from the PG so far (not a lot), I’m going to assume this is a permanent change. The ostensible reason, as suggested by several people in the comments below, is to improve accessibility using screen readers. It’s hard to argue with that, but it’s still an unfortunate change.

I’ve also checked with a few people running non-English tenants, and the titles are localized, like so:

  • Swedish: “Namn Obligatoriskt fält” or “Name Required Field”.
  • Russion: “RegSelect Обязательное поле” or “RegSelect Required Field”
  • etc.

I’ve also received reports (several below in the comments) that this issue is popping up with SharePoint 2010 after applying the December CU. More on that as I get further details.

Based on this, I’m getting a fix ready in the 2014.01 release and will try to get it out there shortly. Methinks it’s going to become a game of catch up from now on.

[notice]2014-02-03 12:40m EST – SPServices 2014.01ALPHA2 posted with a fix for the issue on Office365. As soon as I can get an example of how the issues arises in SharePoint 2010, I hope to have that fix as well. [/notice]

[notice]2014-02-19 SPServices 2014.01 released with fixes for every implication of these changes of which I am aware. If you’ve run into this issue, please upgrade!



  1. I’ve added a few updates to the post. I’m getting some reports that this issue is popping up in SharePoint 2010 installations when the December CU is applied, though it may also be in SP2. More as I find things out…

  2. Fine, here’s my two cents. It sucks. This has been consistent for as long as I can remember with a thousand blog posts referencing the method of using the title attribute, if Microsoft had been paying attention or cared about the developers this would have been addressed differently.

    That being said, I did throw together the following function for getting a field based upon those internal comments that use the internal field name and field type. I’m not crazy about it from a performance standpoint, and what’s to stop Microsoft from changing the way they do the comments? It’s currently only for Text Fields and lookups, but you get the gist.

    	function GetField(internalFieldName)
    		var fieldElement = undefined;
    		var container = undefined;
    		var fieldType = undefined;
    		 $(" td").each(function(){
                if (this.innerHTML.indexOf('FieldInternalName="'+internalFieldName+'"') != -1){
                    container = this;
                    //I don't like this method for getting FieldType, there's gotta be a better way
                    fieldType = container.innerHTML.split('FieldType="')[1].split('"')[0];
                    //break out of each loop
                    return false;
            	case "SPFieldText":
            		fieldElement = $(container).find("input[type='text']");
            	case "SPFieldLookup":
            		fieldElement = $(container).find("select");
            return fieldElement;
    • Mark:

      Yeah, I’ve used the comment field in places where I’ve had to, like with radio buttons and checkboxes where there’s simply *nothing* else that I can use. It’s sort of my last resort because I don’t trust it, either. On the other hand, I’ve been trusting the title attribute for over 8 years, and look where that’s gotten us.

      I’m heading toward something more like this, though this doesn’t work for non-English instances:

              if (((this.Obj = $("select[Title='" + colName + "']")).length === 1) || ((this.Obj = $("select[Title='" + colName + " Required Field']")).length === 1)) {

      At least in this case, they seem to have been consistent with the translations (as noted in my update to the post above today). In the multi-selects, the translations are all over the place, as I noted in my post From SharePoint Magazine: Variations in Multiselect Controls in Different SharePoint Language Versions.

  3. I have been scratching my head for about a month – my cascading dropdowns were no longer working and I did not have a clue why. So, the mystery is now understood. But how to deal with it…

    It turns out that both of my dropdown columns are required. No cascading occurred when I added “Required Field” to both the parent and child column Display Names. It worked as expected when both columns were changed to “not required”.

    I needed the cascade function and required values so I stiched them together using jQuery like this:

    $(document).ready(function() {
    	// Set up the cascade Main_Category to Sub_Category
    		relationshipList: "Main_Sub",
    		relationshipListParentColumn: "Main",
    		relationshipListChildColumn: "Title",
    		parentColumn: "Main_Category",
    		childColumn: "Sub_Category"
    function PreSaveAction(){ 
       var main_val = $(":input[title='Main_Category']").val();
       var sub_val = $(":input[title='Sub_Category']").val();
    //if a choice has not been made in a list, the value is zero
       if(main_val == 0){
         alert("Warning: Select value for Main_Category!");
         return false; 
       if(sub_val == 0){
         alert("Warning: Select value for Sub_Category!");
         return false; 
       return true;

    I learned that SharePoint provides the PreSaveAction function that allows me to add custom code that runs when you Save your list. The function above checks to make sure each column has a valid choice or halts the save with a warning message.

    By the way, I noticed quite a few bloggers recommend using SharePoint Designer to add the code directly to the new or edit form. It is much easier to link the code in a .js file to a Content Editor web part that is easily added in the client by editing the new or edit form web parts.

    I eagerly await a more elegant solution.

    I really appreciate the information and time that folks like you and that HillBilly guy (I used his parent-child list model) provide this community. I hope this helps others..

    By the way, I’m also a knowledge management zealot.

  4. Hi Mark. To avoid duplication in the title selectors, you could leave the space in the literal:
    [Title^=”Region “], but if they change the UI back after the next service pack, we are again screwed. I’ve fought these kinds of API issues for years. This is the first I’ve seen in SharePoint. I hope it isn’t a trend.

    • Dan:

      Unfortunately, it’s more complicated. Since we could have a column called “Region 2″, the selectors need to be more solid. I think I’ve got a reasonable fix for 2013 /Office365 using regex on the select’s id. I’m trying to get an example from a SharePoint 2010 installation where the December CU has been applied, as I’ve gotten reports of the same ” Required Field” stuff there as well.

      Oh, and there’s another added wrinkle: the ” Required Field” test is localized with other language packs.


  5. Another option for those looking for a quick hack to get their old scripts working again,
    In your document.ready place the following script at the beginning. It will find all the title attributes with ” Required Field” and remove that text from the attribute, your old script should work fine now. Is it a hack? Absolutely. Will it get your forms working quickly until you can think of something better?? Yes… As long as the name of your field isn’t SUPPOSED to have ” Required Field” in t.

    $(“[title$=’ Required Field’]”).each(function()
    $(this).attr(“title”,$(this).attr(“title”).replace(” Required Field”,””))

    • This hack makes me nervous Mark, but yep, it’ll work. I’ve already got a fix for Office365 / SharePoint 2013 that I think is bulletproof using regex on the id.

      If anyone here has seen this issue with SharePoint 2010 (with or without the December 2013 CU) and can send me the resulting markup, I’d appreciate it.


      • More nervous than what MS is already doing? :) It will at least get your scripts functioning again without having to touch any of your existing scripts.. then you can go back and factor in a better solution.

        • Mark, the main risk here is that while fixing your own script you might break something else (why did MS feel the need to change it?). Rather than modifying the existing attribute, you’re better off storing the resulting value in a different attribute.

          I’ll add that people will also need to learn not to use “document ready” anymore, as it doesn’t mean much with asynchronous SharePoint pages.

  6. Hey.. you can either be problem solvers or problem finders. :) I stand by my statement that people experiencing broken functionality can put my script in place (changing the language where necessary) and use it until they can figure the correct path going forward… sheesh.. :)

    The title attribute is not required (at this time) for postback and does not appear to impact SharePoint native functionality.


Have a thought or opinion?