Task List types in SharePoint Online and how to use them in SharePoint Designer workflows

If you are still working with SharePoint Designer workflows, you will be familiar with a setting that has to be made for each workflow: the associated Task list.
Strangely, you need to set this even if your workflow isn’t creating any tasks.

If you open the Task list drop-down, SharePoint Designer will propose the available task list – if any are available – and an option to create a new Task list.

tasklistdropdown

As you will probably know, there are two platform types available in SharePoint Designer 2013: you can create SharePoint 2013 workflows and you can still create SharePoint 2010 workflows. The latter option is still very relevant, because several useful functions like creating a copy of a document only exist in SP2010 workflows.

While working on a SharePoint Online site which has both SP2010 and SP2013 workflows, I noticed a difference in the Task lists that were being offered in the dropdown, which I couldn’t explain at first.

Then it dawned on me: SharePoint 2010 workflows come from the age of SharePoint 2010 (obviously). If you would create a Task list through the browser in SharePoint 2010, you get a different Task list compared to the one that you create through the browser in SharePoint 2013!
As a result, if you create a SharePoint 2010 workflow (in SharePoint Designer 2013) and a SP2010-style Task list is available, that is the one the dropdown will offer you.
A SharePoint 2013 workflow on the other hand will offer you both the SP2010 and SP2013-style Task lists.

You can use a SP2010 workflow with a SP2013-style Task list, but that has another nasty side-effect: the Task list is then automatically populated with a number of old-school content types, like “SharePoint Server Workflow Task” (yes, even in SharePoint Online), and all of the fields that come with it.

Another unpleasant side-effect: the SP2013 version of the Task list has several additional options, like displaying a timeline and a strikethrough option for completed tasks. But if you associate a SP2010 workflow with a SP2013-style Task list, some of those options will not work anymore (found this out the hard way).

So how do you handle this? If you have both SP2010 and SP2013 SharePoint Designer workflows on your site, my recommendation is that you create two Task lists:

  1. a SP2010-style Task list for the SP2010 workflow tasks
  2. a SP2013-style Task list for the SP2013 workflow tasks

That way each workflow gets the appropriate Task list capabilities.

Now here’s the trick: if you create a Task list through the browser in SharePoint 2013 or above – so also in SharePoint Online – you will always get the SP2013-style Task list.
The SP2010-style Task list is still available though, but you will need to create the list through script.
The main distinction to remember:

  • SP2010 Task list = TemplateType 107
  • SP2013 Task list = TemplateType 171

So now you can do something like this in CSOM:

#get the context (request the site, user and password parameters from the user)
$context = New-Object Microsoft.SharePoint.Client.ClientContext($site)
$credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($user, $password)
$context.Credentials = $credentials

#now we can prepare the new list object
$listCreationInformation = New-Object Microsoft.SharePoint.Client.ListCreationInformation
$listCreationInformation.Title = “My Old School SP2010 Task List”
$listCreationInformation.Description = “My Old School SP2010 Task List”
$listCreationInformation.TemplateType = 107

#then we create the list in our web site context
$list = $context.Web.Lists.Add($listCreationInformation)
$context.Load($list)
$context.executeQuery()

And voila, you have a custom-made SP2010-style list in your SharePoint Online site.
The SP2013-style list can obviously be created in the same way, or through the browser if you like.

Advertisements

Permissions required to start a SharePoint Designer workflow

I’ve read in multiple blog posts that you need Contribute permission to start a SharePoint Designer workflow on a List item. That makes sense, because the workflow also generates a workflow status field on the List. And starting the workflow on an item typically alters the value of that field, which automatically means you need permission to change that item.

What I’ve found is that Contribute permission on the List itself is not enough. There are two other permissions required:

  • Contribute permission on the hidden Workflow History list
    The actions taken by a workflow are recorded in a workflow history list. By default this is the hidden List ‘Workflow History’ (URL: {site}/Lists/Workflow%20History) which is always present.
    If the user account that started the workflow cannot write anything to this history list, then the workflow will fail rightaway.
    By default the Workflow History list inherits its permissions from the site root. What typically happens is: someone needs to start a workflow from a Document Library but has only Read permission on the site root. The Workflow History list inherits that Read permission, which is not enough for a workflow to start/run properly.
    If your users who start workflows are already regular Members of the site and therefore have Contribute permission from the root, then you will not notice this problem since you automatically have the correct permission on the Workflow History list.
  • Contribute permission on the Tasks list
    Almost the exact same logic applies to the Tasks list. If (and only if) you have a workflow that creates Tasks, then obviously the user needs Contribute permission on the Tasks list configured for that workflow as well.
  • Read permission on the site root
    Please note: I am less certain about this one, but I found that the permissions on the site root also play a role. My theory is this: you need Read permission on the site root so the user can ‘see’ the available workflows and the lists (Tasks and History) attached to those workflows. Somehow that information is stored at site level, which is why you need Read permission there.

Note that the above permission requirements also apply to workflows at site level, not just for List workflows.
Get these permissions in place, and your users should have no trouble starting SharePoint Designer workflows (either manually, or automatically OnCreate/OnChange).

Limitations for external users in SharePoint Online

You can share a SharePoint Online site (or a list or document, etc.) with external users, if your global setting for the site collection allows this. Although you need to select a specific permission group for these external users (from the list of available permission groups in that site), those external user do not have the same capabilities as a ‘normal’ user of the site.

The reason for this is that external users do not have an Office 365 license linked to them, at least not unless you choose to assign that to them.
As a result there are a number of things you cannot do as an external user. Microsoft has some documentation on those limitations:

Manage external sharing for your SharePoint Online environment

I recently found that there is at least one other thing that external users cannot do, which is not documented: An external user cannot share something with another external user by inviting them.

On the one hand that makes sense, because that could potentially allow an endless string of external users in the site. On the other hand it is strange: if I am allowed into the site as an important user with broad permissions, then why can’t I share anything with another (new) external user?

What I haven’t tried yet is to see if an external user can share with new external users once an Office 365 / SharePoint Online license is assigned to his account. Will update this post if I find out.

 

Versioning in SharePoint when editing in Word compared to Word Online

While I was developing a workflow to be triggered on a changed Document Library item in SharePoint Online (this was a Word document), I noticed something interesting about the versioning.
In the workflow I was checking if the version number had already increased, thinking that in this way I could determine if the user was done editing.

As it turns out, it depends if you are using Word or Word Online. What happens is this:
If you are using your local MS Word installation, then you are basically working offline. You only connect to SharePoint Online when you take an explicit action like saving or checking-in a document. SharePoint will not create a new version in the version history until you click Save in Word. So even if you type lots of new text and update some properties, but close the document without saving, nothing is changed in the version history.

This is very different in Word Online. As you probably know, there is no Save button in Word Online, because any change is automatically saved for you. So that made me wonder: if I edit a document in Word Online for half an hour, making many changes, then that document is going to be saved automatically dozens of times. So does that create dozens of new versions in the history? Well, that would be awkward and luckily the answer is no.

What happens is that Word Online creates a new version in the version history (in SharePoint Online) when the first change is being saved in Word Online. So as long as you don’t touch anything in Word Online and just read the document, you get no new version. Then, on every next change in the document that is saved in Word Online, that same new version is *updated*. You can see the Modified time change in the version history.
That is actually the same behavior that we are used to in (local) Word: as long as you do not close the document, subsequent saves will be considered as an update to the same version. This is true if you use both minor and major versions, but also if you only use major versions.

So coming back to my workflow, the downside here is that a new version in the history does not always mean that the user explicitly saved his work. That depends if Word Online or (local) Word was used. Your new version will in any case appear in your version history more quickly when using Word Online.

 

Accessing your Audit Reports in SharePoint Online

I was used to my SharePoint audit reports index being available as a link in Site Settings > Site Collection settings.
In SharePoint Online however, that link appears to be gone. I can still edit the Audit Settings, but there is no link to open the actual reports.

I’ve seen different reasons mentioned for this. This might be done on purpose, because the Office 365 Protection portal has become the access point for audit/compliance reports.
This doesn’t help me, because in this particular case I did not have access to the Protection portal of the customer. But if I need to check something for SharePoint Online, then obviously I would like to have access to at least the reports for SharePoint Online. That seems reasonable if you are a Site Collection administrator, doesn’t it?

Luckily there is a workaround: the URL for the audit reports is accessible, you just need to know it.
After the URL to the root of your site, append the following:

/_layouts/15/Reporting.aspx?Category=Auditing

and voilà, you’re there!

auditreports

You cannot delete a DropOffLibrary in SharePoint Online

If you enable the Content Organizer feature in SharePoint, a library with the name DropOffLibrary is automatically created for you. This is the place where you drop off your documents, after which the content organizer rules kick in and move your documents to the appropriate target location.

I was doing some testing with this feature in a test site in SharePoint Online and wanted to clean up afterwards. So what I did was disable the Content Organizer feature. Result: no more content organizer rules, but the DropOffLibrary was still there. So of course I went into the library settings, expecting to delete it from there. Surprise: the link to delete the library is missing for the DropOffLibrary.

As it turns out, there is a property called AllowDeletion which is set to False for this library, probably because it is so tightly linked to the Content Organizer feature. What you would hope for is that feature deactivation causes this property to be set to True, but that’s not the case.
I tried a few other options, like deleting it through SharePoint Designer but you can’t delete it from there either.

Several blogs mention that you need to set the property AllowDeletion to True using PowerShell:

$list.AllowDeletion = $true
$list.Update()

But unfortunately, that only works in SharePoint (2010, 2013) On-Premises. The property is a member of the Microsoft.SharePoint.SPList class, but not available as a member of the Microsoft.SharePoint.Client.List class, so not part of the CSOM (yet) and therefore deletion of this list cannot be set to allowed.

In other words, once you activate the Content Organizer in SharePoint Online, there is no way to get rid of the DropOffLibrary. What you can do of course is hide it as much as possible, but that’s not really cleaning up. So if you are considering the Content Organizer for a SharePoint Online site, make sure you want this because there is no complete way back.

 

Indexing columns in SharePoint

If you run into performance issues with your library views, or worse still, into the 5000-item limit on library views, Microsoft’s recommendations quickly point you in the direction of column indexes. SharePoint Online at the moment has even started automatically creating such indexes for you if it feels that will help your library views (just switch on Automatic Index Management in the advanced list settings).

That’s not bad of course, but there are some serious limitations when it comes to indexing columns. You can have a maximum of 20 indexes, but that seems plenty to me. The major issue is that several column types cannot be indexed. The one that I find most annoying is the lack of indexing for multi-value columns (no matter if it’s a Choice or Lookup column).
Here’s a quick overview:

Supported Column Types

  • Single line of text
  • Number
  • Currency
  • DateTime
  • Choice field – as long as it’s single value
  • Lookup – as long as it’s single value
  • Person or Group – as long as it’s single value, because this is essentially a lookup column
  • Managed Metadata

Unsupported Column Types

  • Title – only supported for indexing in Lists
  • Multiple lines of text
  • Hyperlink or Picture – because for SharePoint this is a lookup
  • Any custom field types
  • Calculated Field
  • Multi-value choice
  • Multi-value lookup
  • External data

The fact that the above types cannot be indexed can have serious implications, especially if you have reached your 5000-item limit. Because above that limit, SharePoint will only allow filtering of data on indexed columns. So if you happen to have a few columns that are important to you for filtering, but they belong to one of the above column types, you’re in trouble. And there’s really no realistic escape route. Metadata navigation only gets you so far. It has a fallback query built in that should limit the result set automatically, but I’ve seen cases where even the fallback query just ran endlessly, showing zero results.
As a side note: The multi-value choice or lookup columns seem to be a more general problem in Office 365 related products. I recently read they also are an issue in PowerBI (http://sympmarc.com/tag/multiselect-columns/).

Here’s the official Microsoft documentation on indexing:
https://support.office.com/en-us/article/Manage-lists-and-libraries-with-many-items-11ecc804-2284-4978-8273-4842471fafb7#__creating_sharepoint_indexed

And this is another source I found very useful:

SharePoint 2010–Indexing columns in a SharePoint List