Recent Changes to Task Management Conventions on Office 365

2015-11-13_14-20-24If you’ve been using Task Lists in SharePoint as long as I have, you will notice even the tiniest changes. Task Lists have never worked exactly the way people want them to – why doesn’t marking a task %100 complete also mark it as Completed? – but by adding a few extra columns to each list to customize them for your organization, they have always gotten the job done.

I wrote about how I generally use Tasks Lists years ago in my post Simple Best Practices for Using SharePoint Task Lists. I’m no longer a huge fan of the “best practice” term – there can be many different “better practices”; rarely is a “best practice” the best for everyone – but I’ve been following that model for Task List usage since I wrote the post in 2009. That’s through SharePoint 2007, SharePoint 2010, SharePoint 2013, and SharePoint Online.

Well, sometime in the last few weeks or months, the way Task Lists work in Office 365 seems to have changed, and my model doesn’t work so well any more. These changes seem to apply only to Task Lists that have been created since the changes, as my older Task Lists still work the same way they always have.

I don’t see anything in the Office 365 roadmap to explain the changes (I admit I didn’t pore through every item, but the prose there is difficult to follow, IMO), so I figured I’d capture what I’m seeing. Here’s what’s different:

  • If you change the Task Status from Not Started to In Progress, the % Complete column is set to 50% on save
  • When you change the % Complete column to 100%, the task is marked as complete on save

These two little changes can make a big difference. I think that they are actually an improvement, but for anyone who is used to the old way, it’ll be frustrating. This will be the case especially if you have some older Tasks Lists and newer Tasks Lists in the same site!

My new suggested model will change a bit:

  • When you start working on a task assigned to you, set the Task Status to In Progress, then immediately change the % Complete from 0% to whatever is appropriate. SharePoint seems to respect the % Complete you set rather than updating it to 50% on save.
  • When you’ve completed a task, leave the Task Status in the In Progress state, as we have before. Now, however, mark the % Complete to 99%. This will prevent SharePoint from marking the task as Completed when you save it.
  • When the person who originally made the request decides you have completed the task appropriately, they can change the % Complete to 100% or just tick the Completed box, which is generally to the left of the task, at least in the default view.

One of the main goals I’ve always had in my model is to make it an exception – rather than the norm – for people to mark tasks complete which they work on. We don’t need to enforce it strictly, but by convention. These tweaks under the new Task Lists behavior still supports the goal.

Plus ça change, plus c’est la même chose


Retrieving High Priority Tasks with SharePoint’s Query REST API

fullcalendar month view javascriptThis will be a quick post. Recently, when I wanted to make a REST call to retrieve all of the high priority tasks from a set of task lists, I figured it would be no big deal. I’d just add something into the querytext and be done with it. Unfortunately, syntax is always a cruel bedfellow.

I tried all sorts of things, like:

Someone like Mikael Svenson (@mikaelsvenson) – search guru that he is – would just look at this and tell me immediately what to do, but I try not to bug him unless it’s something complicated. Oddly, I couldn’t find a single example out there of someone doing this. It would seem to be a common request: show me all of the high priority tasks in the Site Collection so that I can focus on them.

In this case, we’re showing those tasks on a fullcalendar on the home page of a parent site which has many subsites, each for a project. Fullcalendar is an excellent, full-featured JavaScript calendar widget that you can pretty easily add into a SharePoint page. You just have to feed it data in a format it can understand. So we want to retrieve all of those project tasks using the search API and massage them into the fullcalendar format.

The filtering solution turned out to be too easy:

Here’s the full code that I came up with for this part of my KnockoutJS view model:

// Only get tasks with Priority='(1) High'
var projectTasks = [];
  url: _spPageContextInfo.webAbsoluteUrl + "/_api/search/query?" +
    "querytext=%27ContentTypeId:0x01080023AEF73C31A00C4C87FD5DB6FD82F6EE* Priority:1%27" +
  type: "GET",
  headers: {
    "accept": "application/json;odata=verbose",
  success: function(data) {

    $.each(data.d.query.PrimaryQueryResult.RelevantResults.Table.Rows.results, function(index, item) {

      var searchResult = [];

      // Normalize the fields
      $.each(this.Cells.results, function(i, prop) {
        searchResult[prop.Key] = prop.Value; // { Value: prop.Value, ValueType: prop.ValueType };

        calendar: "Project Tasks",
        color: "rgb(100,150,148)",
        title: searchResult.Title,
        path: searchResult.Path,
        eventDate: $.fullCalendar.moment(searchResult.StartDateOWSDATE),
        endDate: $.fullCalendar.moment(searchResult.DueDateOWSDATE)
  error: function(error) {

If nothing else, the next time I need to do this, I’ll hit something when I search!

Finding a Task’s Status Using GetListItems and SPServices in SharePoint 2013

I get interesting questions all this time. This one came from a client who was trying to use GetListItems with SPServices in SharePoint .

Hey Marc, I’m trying to do a GetListItems operation on tasks list and I’m having trouble with the “Task Status” column. This is SP2013.

var thisTaskStatus = $.trim($(this).attr("Status"));
var thisTaskStatus = $.trim($(this).attr("ows_Status"));
var thisTaskStatus = $.trim($(this).attr("ows_Task_x0020_Status"));

None of the above work and I went into the edit column settings of the task list and clicked on the status column and it says the field name is “Status”. When I look at the XML returned using Firebug, a lot of other fields show up like Title, Due Date, Created By, etc. but I don’t see the status column showing up at all in the responseXML.

Many of the out of the box columns have rather obscure StaticNames. In a Tasks list, the column which has the “Status” DisplayName has a StaticName of “Status” as well, so that’s pretty simple. Here’s the field definition, which I grabbed by calling GetList on my own Tasks list:

<Field Type="Choice" ID="{c15b34c3-ce7d-490a-b133-3f4de8801b76}" Name="Status" DisplayName="Task Status" SourceID="" StaticName="Status" ColName="nvarchar4">
   <CHOICE>Not Started</CHOICE>
   <CHOICE>In Progress</CHOICE>
   <CHOICE>Waiting on someone else</CHOICE>
    <MAPPING Value="1">Not Started</MAPPING>
    <MAPPING Value="2">In Progress</MAPPING>
    <MAPPING Value="3">Completed</MAPPING>
    <MAPPING Value="4">Deferred</MAPPING>
    <MAPPING Value="5">Waiting on someone else</MAPPING>
  <Default>Not Started</Default>

Calling GetList to take a look at the list schema is a good way to keep yourself from going crazy.

Now that said, you don’t always get all of the columns for a list when you call GetListItems. By default, you get the columns which are shown in the default view.

In an out of the box Tasks list that I just created, when I make this call:

  operation: "GetListItems",
    listName: "Tasks"

Status isn’t returned because it’s not in the default view.

  ows_Created_x0020_Date="1;#2014-01-29 13:04:43"
  ows_Created="2014-01-29 13:04:43"
  ows_Modified="2014-01-29 13:04:43"

Instead, you can add the CAMLViewFields option to request it:

  operation: "GetListItems",
    listName: "Tasks",
    CAMLViewFields: "<ViewFields><FieldRef Name='Status'/></ViewFields>"

Then I get:

  ows_Created="2014-01-29 13:04:43" 
  ows_Modified="2014-01-29 13:11:21" 

Being explicit about the columns you want to retrieve is always a good practice. People can change the default view easily.

CAML Filter for Current Group Membership

My pal Christophe Humbert at forwarded me a question from one of his readers earlier today. I didn’t know the answer, but it intrigued me enough to track down the answer.

Something that a lot of people don’t realize is that every List View Web Part (LVWP) you use in your SharePoint pages contains the CAML required to render what it’s supposed to render. If you crack open the page with SharePoint Designer, you can find that CAML, copy it out, make it human readable (by changing the escaping to the real characters), and see what’s going on.

If you look at the CAML for the LVWP on the By My Groups view page in a Tasks list, you’ll see this Where clause:

&lt;Where&gt;&lt;Membership Type="CurrentUserGroups"&gt;&lt;FieldRef Name="AssignedTo"/&gt;&lt;/Membership&gt;&lt;/Where&gt;

or, formatted for humans:

  <Membership Type="CurrentUserGroups">
    <FieldRef Name="AssignedTo"/>

If you look at the CAML schema, you can see the details for the options for Membership.  What this CAML Where clause is doing is filtering for items where the AssignedTo value exists in the the current user’s groups.  Sweet!

Frankly, this is a new one to me, but it makes sense.

Simple Best Practices for Using SharePoint Task Lists

When I’m working on a project, we almost always use a SharePoint Task List to manage our outstanding tasks.  I’ve seen many people try to overcomplicate this process with complex workflows, roles, and permissions, but to me some simple tweaks and conventions to the basic Task List get you much further along and make life easier, to boot.

When I create the Task List (calling it something relevant, like ‘Project X Team Tasks’), I do a couple of quick tweaks:

  • From List Settings, I go to Versioning Settings and tick Yes for ‘Create a version each time you edit an item in this list?’
  • Next, I go to the Description column settings and set ‘Number of lines for editing:’ to 10 (6 just never seems like enough) and then tick Yes for the ‘Append Changes to Existing Text’ option.
  • Optionally, if it is a fairly large or involved project, I may add a new column or two to capture the primary and/or secondary areas to which the task pertains.

That’s it!

We keep the permissions open on the list: everyone on the team can create, edit, and delete tasks.  Whenever someone creates a task, it’s up to them to assign it to someone if they know who it should go to.  If they don’t there’s usually one person who just keeps an eye on the whole list and assigns things that get “orphaned”.  (It’s often me!)

We create a few views that are grouped by Status and then sorted or grouped by Assigned To.  This makes it easy for everyone to see what’s on their plate.  Using the Active Tasks view rather than the All Items view as the basis for this view is often easiest.

When someone grabs a task to do, they make sure that they are assigned to it and mark it as In Progress.  Along the way, they add to the Description whenever something happens.  If they need clarification from someone, they just assign the task to them.

When someone completes a task, they add a final comment into the Description, mark it as 100% complete, leave it In Progress, and assign it back to the person who created the task.  It’s then up to the person who asked for the task to decide if it’s time to mark it as Complete or add another comment and reassign it.

Simple conventions, low overhead, but it always works!  When you’re working on a project that’s all about collaboration, it’s important to trust the team and *work* collaboratively, too.  Sure, anyone could delete all of their tasks or assign them away, but come on, we’d all know about it.

Remember that you can set an Alert for the task list to send you an email when something changes.  There are options about how often you receive the updates, etc.  To do this, click on the title of the Task List and then in the Actions menu, choose Alert Me.

Happy tasking!