Auto-populated Choice Columns in SharePoint!

 

This was tested in SharePoint 2013 and 2016.

Had a list with 100,000 items with a State column. I found that some of my users did not know their state abbreviations. (KE is Kentucky?) After cleaning up the "nonstandard" states, I decided to convert the column from Single Line of Text to Choice.

Magic!

After editing the column and clicking "Choice" I scrolled down and found that the list of choices was already populated!

For this to work for lists with more than the List View Threshold number of items (5,000 by default) you will need to be:

• a server administrator, or
• an auditor (Configured in Web Application settings, and only for under 20,000 items.), or
• working with the list during Happy Hour!  (Offically “Daily Time Window for Large Queries”.)

 

Bonus!

The State column was now available in my Metadata Navigation Settings options.

 

Too Easy!

In the future when importing large amounts of list data I’ll just make the columns that should be Choice as Single Line of Text and then after the import change them to Choice.

.

SharePoint 2016: List View Threshold Limit to Delete a List is 99,993 Items???

 

SharePoint 2013 had a default List View Threshold that used the number 5,000 for a lot of limits. SharePoint 2016 has made a few changes to the List View Threshold to give us a little more flexibility. If you take a look at the TechNet article “Software boundaries and limits for SharePoint Server 2016” you will find that the old 5,000 limit is still there for normal list activity, but they have made a few changes for Site Owner maintenance activities.

These include:

• When adding or removing a column index, the threshold is 20,000 by default.
• When deleting a list or folder, the threshold is 100,000 by default.
• When renaming a folder within the same library, the threshold is 100,000 by default.

Note that these limits are for Team Members, Site Owners and Site Collection Administrators. Server administrators can exceed these limits and everyone can during “happy hour!” (Officially, the “Daily Time Window for Large Queries” limit set by the SharePoint Server administrators.)

As I am working on a new course, “Microsoft SharePoint Server Content Management for SharePoint 2013 and 2016”, I have to both test these limits and create screen captures for classroom demos. I ran into two interesting discoveries:

• I could rename folders when there were more than 100,000 items. So this one must be for when there are up to 100,000 folders at the same level.
• I could NOT delete a list with 100,000 items. Or, 99,999 items.

The delete issue was a bit more interesting… I started deleting items, even emptied the Recycle Bin after each delete, but still could not delete the list… until I hit 99,993 items. Weird huh? That number is not even a magic number (a power of 2). I guess there must seven hidden, for SharePoint’s use only, items in that large list. Who knows…

I could not delete the following list until the item count was below 99,994.

99,993… now I can delete it.

 

Now… should I go an tie up the bandwidth to create a 100,000 item list in SharePoint Online to test there?

Of course!

 

.

Get the Version Number of a PowerShell Module

 

When a PowerShell script works for one person, but not for another, sometimes it's because the PowerShell module is a different version.

To find the version number:

Get-Module -ListAvailable "Microsoft.Online.SharePoint.PowerShell" | 
select name, version

 

If you need to deal with multiple versions in your scripts:

if ( (Get-Module -ListAvailable "Microsoft.Online.SharePoint.PowerShell").
  Version.ToString() -eq "16.0.4915.0") 
  { … do this } 
else 
  { … do this }

or maybe

if ( (Get-Module -ListAvailable "Microsoft.Online.SharePoint.PowerShell").
   Version.ToString() –lt "16.0.4915.0") 
   { "Must have 16.0.4915.0 or later"; Return; }

.

Using Relative URLs in SharePoint 2013 Workflow Calls

 

(For SharePoint 2013, 2016 and SharePoint Online.)

It's generally a good idea to use relative URLs when creating something that you will want to use in more than one place. While not real obvious, you can easily do this in SharePoint 2013 workflow web service calls.

Absolute URL:
   http://yourServerName/sites/yourSiteName/_api/web

Relative URL:
   /sites/yourSiteName/_api/web

What we would like to have in a workflow web service call:
   _api/web

Steps:

1. After adding your Call HTTP Web Service action, click “this”
   .
2. Click the "…" button to open the String Builder dialog.
    
   1. Click the Add or Change Lookup button.
   2. For Data source select Workflow Context.
   3. For Field from source select Current Site URL.
   4. Immediately after the lookup place holder (i.e. no spaces) type the rest of the URL for the web service call:
         _api/web
      
      
   5. Click OK.
3. Continue with web service call action configuration…

 

As you can probably guess… I’m working on a new class that includes workflows!

.