Posted in Classification, Governance, Information Management, Microsoft 365, Records management, Retention and disposal

Classifying records in Microsoft 365

There are three main options in Microsoft 365 to apply recordkeeping classification terms to (some) records:

  • Metadata columns added to SharePoint sites, including those added to Content Types and/or added directly to document libraries.
  • Taxonomy terms stored in the central Term Store, including those added as site columns and added to site content types and/or added directly to document libraries. The only difference with the first option is that with the Term Store the classification terms are stored and managed centrally and are therefore available to every SharePoint site.
  • Retention labels that: (a) ‘map’ to classification terms; (b) are linked with a File Plan that includes the classification terms; (c) are either the same as (a) or (b) and are used in with a Document Understanding Model in SharePoint Syntex; or (d) the same as (a) or (b) and used with conjunction with Trainable Classifiers.

The first two options can only be applied to content stored in SharePoint. Retention labels may be applied to emails and OneDrive content. None of the three options can be applied to Teams chats. Also note that there is no connection between the SharePoint Term Store and the File Plan, both of which can be used to store classification terms.

This post:

  • Defines the meaning of classification from a recordkeeping point of view.
  • Describes each of the above options and their limits.
  • Discusses the requirement to classify records and other options in Microsoft 365.

What is classification?

Humans are natural-born classifiers. We see it in the way we store cutlery or linen, or other household items or personal records.

Business records also need some form of classification. But what does that mean? The 2002 version of the records management standard ISO 15489, defines classification as:

‘the systematic identification and arrangement of business activities and/or records into categories according to logically structured conventions, methods and procedural rules represented in a classification system’. (ISO 15489.1 2017 clause 3.5).

The standard also states (4.2.1) that a classification scheme based on business activities, along with a records disposition authority and a security and access classification scheme, were the principal instruments used in records management operations.

The classification of records in business is important to establish their context and help finding them.

Microsoft 365 includes various options to apply classification terms to records.

Metadata columns in SharePoint

The simplest way to classify records stored in SharePoint document libraries is to either create site columns containing the classification terms and add those columns to document libraries, or create them directly in those libraries.

Benefits

Adding site or library columns is relatively simple. As classification terms are usually in the form of a (hierarchical) list, it is simple to add one choice or lookup column for function and another for activities.

A lookup column can bring across a value from another column when an item is selected; for example, if the look up list places ‘Accounting’ (Activity) in the same list row as ‘Financial Management’, selection of ‘Accounting’ will bring across ‘Financial Management’ as a separate (linked) column.

Default values (or even one value) can be set meaning that records added to a library (that only contains records with those classification terms) can be assigned the same classification terms each time without user intervention.

Negatives

SharePoint choice or lookup columns do not allow for hierarchical views or values to be displayed from the list view so the context for the classification terms may not be obvious unless both function and activity are listed.

The Term Store

The Term Store, also known as the Managed Metadata Service (MMS) has existed in SharePoint as a option to create and centrally manage classification and taxonomy terms in SharePoint only for at least a decade.

In 2020, access to the Term Store was re-located from its previous location (https://tenantname-admin.sharepoint.com/_layouts/15/TermStoreManager.aspx) to the SharePoint Online admin portal under the ‘Content Services’ section:

The location of the Term Store in the SharePoint admin center

Organisations can create multiple sets of taxonomies or ‘term groups’ (e.g, ‘BCS’ or ‘People’) within the Term Store. Each Term Group consists of the following:

  • Term Sets. These generally could map to a business function. Each Term Set has a name and description, and four tabs with the following information: (a) General: Owner, Stakeholders, Contact, Unique ID (GUID); (b) Usage settings: Submission policy, Available for tagging, Sort order; (c) Navigation: Use term set for site navigation or faceted navigation – both disabled by default; (d) Advanced: Translation options, custom properties.
  • Terms. These generally could map to an activity. Each Term has a name and three tabs: (a) General: Language, translation, synonyms and description; (b) Usage settings: Available for tagging, Member of (Term Set), Unique ID (GUID); (c) Advanced: Shared custom properties, Local custom properties.

In the example below, the Term Set (function) of ‘Community Relations’ has three Terms (activities).

Once they have been created in the Term Store, term set or terms can be added to a SharePoint site, either as a new site or local library/list column, as shown in the two screenshots below:

First, create a new column and select Managed Metadata

Then scroll down to Term Set Settings and choose the term set to be used.

Once added as a site column, the new column may be added to a Content Type that is added to a library, or directly on the library or list.

A Term Store-based column added to a library via a Content Type.

Benefits

The primary benefit using the central Term Store terms via a Managed Metadata column is that the Term Store is the ‘master’ classification scheme providing consistency in classification terms for all SharePoint sites.

As we will see below, Term Store terms may be used to help with the application of retention labels (which themselves may ‘map’ to classification terms in a function/activity-based retention schedule).

Negatives

Using metadata terms from the Term Store is almost identical with using a choice or lookup column. The only real difference is that the Term Store provides a ‘master’ and consistent list of classification (and other) terms.

Term store classification terms, including in Content Types, may only be used on a minority of SharePoint sites.

Additionally:

  • It is not possible to select a Term Set (e.g., the function level), only a Term within a Term Set.
  • Only the selected classification Term appears in the library metadata, without the parent Term Set or visual hierarchy reference to that Term Set – see screenshot below. Technically only that Term is searchable. It is not possible to view a global listing of all records classified according to function and activity.
  • If multiple choices are allowed, a record may be classified according to more than one Term. This may cause issues with grouping, sorting or filtering the content of a library in views.
How the Term appears in the library column.

As we will see below, there is no connection between the classification Terms in Term Sets and the categorisation options available when creating new retention labels via a File Plan. ‘Business Function’ or ‘Category’ choices in the File Plan do not connect with the Term Store.

Term Store terms and Content Types can only be used to classify content stored in SharePoint.

Retention labels

Retention labels in Microsoft 365 can be used in an indirect way to classify records in SharePoint, email and OneDrive because they can be ‘mapped’ to classification elements.

For example, a label may be based on the following elements:

  • Function: Financial Management
  • Activity: Accounting
  • Description: Accounting records
  • Retention: 7 years

Every retention label contains the following options:

  • Name. The name can provide simple details of the classification, for example: ‘Financial Management Accounting – 7 years’.
  • Description for users. This can be the full wording of the retention class.
  • Description for admins. This can contain details of how to apply or interpret the class, if required.
  • Retention settings (e.g., 7 years after date created/modified or label applied).

Benefits

Where the classification terms map to a retention class, the process of applying a retention label to an individual record, email or OneDrive content could potentially be seen as classifying those records against the classification scheme.

The Data Classification section in the Microsoft 365 Compliance portal provides an overview of the volume of records in SharePoint, OneDrive or Exchange that have a specific retention class:

Negatives

Not every record in every SharePoint document library may be subject to a retention label. Many records (for example in Teams-based SharePoint sites) may be subject to a ‘back end’ retention policy applied to the entire site (which creates a Preservation Hold library).

A retention label applied to a record doesn’t actually add any classification terms to the record.

Retention labels don’t map in any way to Term Store classification terms, except in SharePoint Syntex – see below (but this only applies to SharePoint content).

Retention labels/File Plan combination

The File Plan option (Records Management > File Plan, requires E5 licences) can also be used to add classification terms to a retention label as shown in the screenshot below. Note that there is no link with the Term Store.

Benefits

Records (including emails) that have been assigned a retention label could, in theory, be regarded as having been classified in this way because the label contains (or references) the classification terms.

Negatives

When applied to content in SharePoint, OneDrive or Exchange, retention labels linked with the File Plan do not show the File Plan classification terms. It may be possible to write a script that displays all records with the terms from the File Plan, but it may be easier to do this using the Data Classification option described above.

Retention labels/SharePoint Syntex combination

SharePoint Syntex provides a way to apply retention labels to records, stored in SharePoint, that have been identified through the Document Understanding Model process.

Benefits

As can be seen in the screenshot above, each new DU model allows similar types of records (in the example above, ‘Statements of Work’) to be associated with a new or existing Content Type that can include a Term Store Term – for SharePoint records only – and a retention label. This provides three types of ‘classification’:

  • Grouping by record type (e.g., Statement of Work, Invoice)
  • Linking (of sorts) between the records ‘classified’ in this way and a Term Store term added as a metadata column to the Content Type.
  • Assigning of a retention label. This provides the same form of retention label-based classification described above.

Furthermore, if the Extraction option is also used, data extracted to SharePoint columns can be based on choices listed in the Term Store metadata.

Negatives

SharePoint Syntex only works for records – and only those records that have some form of consistency – stored in SharePoint.

Retention labels/trainable classifiers combination

Trainable classifiers are another way that could be used to identify related records and apply a retention label to those records. Microsoft 365 includes six ‘out of the box’ trainable classifiers that will not be of much value to records managers for the classification of records:

  • Source code
  • Harassment
  • Profanity
  • Threat
  • Resume
  • Offensive language (to be deprecated)

The creation of new trainable classifiers requires an E5 licence; they are created through the Data Classification area of the Microsoft 365 Compliance admin portal. Machine Learning is used to identify related records to create the trainable classifiers.

Once created, a retention label may be auto-applied to content stored in SharePoint or Exchange mailboxes using the classifier.

The option to auto-apply a label based on a trainable classifier.

Benefits

The primary outcome (from a recordkeeping classification point of view) of using trainable classifiers is the application of a retention label to content stored in SharePoint and Exchange mailboxes. It can also be used to apply a sensitivity label to that content.

Negatives

It is unlikely that every record will be classified according to every classification option.

Trainable classifiers only work with SharePoint and Exchange mailboxes.

Classifying records per workload

The options are summarised below for each main workload:

  • SharePoint: Use local site or library columns, Term Store terms or retention labels (mapped to a File Plan as necessary), applied manually or automatically, including via SharePoint Syntex or trainable classifiers.
  • Exchange mailboxes: The only feasible option to classify these records is to manually or auto-apply retention labels that are mapped to a classification, including a trainable classifer.
  • OneDrive: Manually or auto-apply retention labels mapped to a classification.
  • Teams. It is not possible to classify Teams chats with the options available.

Is classification necessary?

The classification model described in ISO 15489 and other standards was based on the idea that records would be stored in a central recordkeeping system where they would be subject to and tagged by the terms contained a classification scheme, often applied at the aggregation level (e.g., a file).

Microsoft 365 is not a recordkeeping system but a collection of multiple applications that may create or capture records, primarily in Exchange mailboxes, SharePoint, OneDrive and MS Teams (and also Yammer).

There is no central option to classify records in the recordkeeping sense. The closest options are:

  • The grouping of records in SharePoint sites (and Teams, each of which has a SharePoint site) and libraries that map to business functions and activities.
  • The use of metadata, either terms set in the central Term Store or created in local sites/libraries, to ‘classify’ individual records (including emails) stored in SharePoint document libraries. Each item in the library might have a default classification, or could be classified differently.
  • The use of retention labels that ‘map’ to function/activity pairs in a records disposal authority/schedule. These may be applied, manually or automatically, to content stored in SharePoint, OneDrive and Exchange mailboxes.

Neither of the above may apply, or be applied consistently, to all SharePoint sites, Exchange mailboxes, OneDrive accounts. And neither can be applied to Teams chats.

A different approach to this problem is required, one that likely will likely involve greater use of Artificial Intelligence (AI) and Machine Learning (ML) methods to identify and enable the grouping of records, and provide visualisations of the records so-classified.

Image: Werribee Mansion, Victoria, Australia stairwell (Andrew Warland photo)

Posted in Information Management, Planner, Microsoft 365, Tasks

The complicated world of Tasks and To Do

We all have different ways to remind ourselves (and others) of things we (and they) need to do. In Outlook, we could create a task, something we needed to do.

In the Microsoft 365 world, personal tasks are now things we need to assign in the To Do app. In Groups or Teams, tasks are Tasks.

This post describes the difference between To Do and Tasks, and how and why Tasks has become a bit confusing.

Outlook tasks become (things) To Do

For a long time, it was possible to create and assign tasks in the calendar part of email. You could assign tasks to others.

Image source: Turn Emails into Tasks in Outlook- Instructions – TeachUcomp, Inc

In mid 2015, Microsoft acquired 6Wunderkinder. That company’s primary offering was the ‘to do’ app called Wunderlist.

In early 2020, Microsoft released the ‘To Do’ app, built on Wunderlist. This CNET article that describes alternatives to Wunderlist includes information about the new Microsoft ‘To Do’ app.

Unlike Tasks, To Do items are essentially a personal list of things to do that is accessed from the separate To Do section of Outlook. They are not included in the calendar.

The ‘To Do’ option is on the far right of the Outlook options

There are two ways to create a new item in the To Do list. The first is to click on the ‘My Day’ option in Outlook and then add a task in the To Do section.

The second is to click on the ‘To Do’ option at the bottom left of the Outlook app, which will open the ‘My Day’ section and allow a new (To Do) task to be created.

A bit confusingly, the Planned section of ‘To Do’ displays tasks that are:

  • Personal tasks, created as an Outlook calendar tasks but which don’t appear in the individual’s Outlook calendar, only in the To Do calendar.
  • Assigned to the individual from a Microsoft 365 Group or Team (including ‘Tasks by Planner’).

The difference between the two can be seen below; the first two are personal tasks from To Do, the second two are Group/Team-based tasks. The ‘Assigned to you’ items are the second two under ‘Later’. Note that the Planned section does not include any simple, non-calendar-based, ‘To Do’ items.

Planner

Microsoft announced the Office 365 service called Planner in September 2015.

The Microsoft 365 Planner app on 1 April 2021

Planner is a task-based service originally linked directly with Office 365 Groups (announced in 2014 ‘Delivering the first chapter of Office 365 Groups‘). It was described as ‘a simple and highly visual way to organize teamwork’ within a team – which meant initially an Office 365 Group. It seemed that Microsoft’s vision was to move the creation of Tasks away from Outlook to Planner.

Initially, when a new Office 365 Group was created (including when a new Team was created in MS Teams), it created a Plan. This connection was later removed and so a new Group or Team no longer creates a new Plan.

The following is an example of an empty plan for an Office 365 Group called ‘SharePoint Admin Group’. All the members of the Group (or Team if one exists) would have access to the plan. Plans contain ‘buckets’ or groupings of tasks. The default bucket is ‘To do’ which, in the example below contains a single task ‘Create two new tasks’ (which is outstanding) A separate bucket was created named ‘New Sites’, and it has one completed task.

Example plan in Planner

Changes to Planner

Several changes happened with Planner since 2018:

  • New Office 365 Groups and Teams did not automatically create a Plan.
  • Multiple plans could be created for every Office 365 Group or Team.
  • Tasks by Planner was introduced to Teams (see below) so that every channel can use either the ‘parent’ Office 365 Group Plan or create a new one.

These changes have created some confusing content in the Planner app.

Tasks by Planner in Teams

Microsoft announced in April 2020 that Planner would be renamed Tasks (it is still named Planner a year later).

As noted in the link (by onmsft.com), ‘… the change means that Teams users will soon be able to see their individual tasks and team tasks in a single app from across Teams channels, Planner and Outlook. For mobile users, the change also means that both a list view and a new mobile tasks experience will soon be available in within the Teams app.’

The new Tasks by Planner and To Do was visible from Teams in early 2021 but the relationship between Outlook To Do tasks and Planner Tasks via Teams remained a bit confusing.

Tasks by Planner and To Do in Teams

When a Team channel is opened, the ‘Tasks by Planner and To Do’ can be added as a tab.

Tasks by Planner and To Do can be added as a tab in any ‘public’ channel (not private channels)

When ‘Tasks by Planner and To Do’ is selected, two options are visible and this is where some of the confusion starts.

Most people are likely to simply click ‘Save’, which creates a ‘Tasks’ tab in the channel and a new Plan. Ideally, they should use an existing plan, if it exists (which it probably won’t – as a result, multiple Plans may be created for each Team and channel.

This is how the new Tasks tab looks like in the Team:

Perhaps it doesn’t matter (for some organisations) how many Plans or Tasks that are set up.

We can now see there are three Plans for the SharePoint Admin Group Team, two in the same (General) channel. The end user can also see tasks that were assigned to him/her. If they click on the ‘Tasks’ option they will see the list of personal calendar- and To Do-based tasks as we saw above in Outlook:

Behind the scenes, in Planner, we can see four plans for the SharePoint Admin Group. Three of these map to the three above, but not the one titled ‘Tasks – SharePoint Admin Group’ which has two completed tasks. But where is it?

Here are the two completed tasks in SharePoint Admin Group ‘Tasks’ plan that don’t exist in the main SharePoint Admin Group Plan, or the other two.

Where are these two completed tasks?

Or, more specifically, why do they not appear in many of the Teams Tasks tabs? There are no private channels in this Team, so I know it’s not hidden in one – and, in any case, you cannot create a new Task list in a private channel.

Just to try to work this out, I created a new Task in that list of Tasks, assigned it to myself. The only place I could find it was in both Teams and Outlook in the ‘Assigned to you’ area.

Assigned to me in Teams
Assigned to me in Outlook

Summing up

Tasks, either to remind yourself of things you need to do, or what others need to do, are probably good for specific purposes or Teams. But the ability to create multiple Task lists in Teams channels is just going to create more and more confusion.

But it’s confusing and will likely result in multiple random Tasks/Plans in Planner, even for the same channel.

Posted in EDRMS, In Place Records, Products and applications, Records management, SharePoint Online, Solutions

SharePoint is not an EDRMS

In my February 2021 post A brief history of electronic document and records management systems and related standards, I quoted from a presentation by Philip Bantin in 2001 that summarised the difference between the two systems.

  • An electronic document management system (EDMS) supported day-to-day use of documents for ongoing business. Among other things, this meant that the records stored in the system could continue to be modified and exist in several versions. Records could also be deleted.
  • An electronic records management system (ERMS) was designed to provide a secure repository for authentic and reliable business records. Although it contained the same or similar document management functionality as an EDMS, a key difference was that records stored in an ERMS could not be modified or deleted.

It could be argued that SharePoint began its life in 2001 as an EDMS and began to include ERMS functionality when SharePoint 2010 was released. So, how is it not an EDRMS?

In simple terms, unlike a traditional EDRMS model that was intended to be the repository for all business records, SharePoint is only one of several repositories that are used to store and manage business records. Instead of centralising the storage and management of records, systems such as Microsoft 365 provide centralised management of records wherever they are stored.

The EDRMS model

Almost all EDRM systems since the mid-1990s have had the following characteristics:

  • Compliance with a standard. For example, DOD 5015.2 (1997), AS 4390 (1996)/ISO 15489 (2001), ISO 16175 (2010), VERS (1999), MoReq (2001)/MoReq2, etc.
  • A relational database (for the various functions, metadata and controls (see diagram below) and a separate file share (for the actual content/records), accessed via a user interface.
  • An expectation that most or all (digital) records would be copied from other systems used to create or capture them to the EDRMS for ongoing storage and protection. This outcome might be achieved through integration with other systems, for example to copy emails to the EDRMS.

The integrated EDM/ERM system model was described in the following diagram in 2008 by the International Standards Organisation committee, ISO/TC171/SC2, in its document ‘Document management applications’:

There are two key problems with the EDRMS model:

  • They do not (and cannot) realistically capture, store or classify all business records. Emails have remained a problem in this regard for at least two decades. Additionally, there is now a much wider range of born-digital records that remain uncaptured.
  • Many of the born-digital records that were copied to the EDRMS continue to exist where they were first created or captured.

Any organisation that has been subject to a legal subpoena or Freedom of Information (FOI) request for records will know the limited extent to which EDRM systems provide evidence of all business activities or decision making.

And yet, almost every organisation has a requirement to manage records. There is clearly a disconnect between the various requirements and standards to keep records and the ability to keep them.

But SharePoint (on its own) is not the answer.

Why isn’t SharePoint an EDRMS?

SharePoint was never promoted or marketed as an EDRM system. It is not even a relational database (see this 2019 post by Sergey Golubenko ‘Why SharePoint is no good as a database‘ for details).

To paraphrase from Tony Redmond’s recent (21 March 2021) post ‘SharePoint Hits 20: Memories and Reflections‘, SharePoint was originally designed to allow content (including page-based content in the form of intranets) to be accessed via the web, thereby replacing network file shares.

In practice, most organisations retained their network file shares, built their intranet using SharePoint, and otherwise used SharePoint to manage only some digital content.

It could be argued SharePoint started out as an EDM system and became more like an ERMS when more recordkeeping capability was introduced in SharePoint 2011. But that doesn’t make it an EDRMS in the traditional sense of being a central repository of business records.

The reality is that records are, have been, and will continue to be created or captured in many places:

  • Email systems. In Microsoft 365, Exchange Online mailboxes are also used to store the ‘compliance copy’ of Teams chats messages.
  • Network file shares.
  • SharePoint, including OneDrive.
  • Other online document management systems, including Google Drive.
  • Text, chat and instant messages often created in third-party systems, often completely inaccessible or encrypted.

The type and format of a record can vary considerably. For example:

  • An emoji.
  • A calendar entry.
  • A photograph or video recording (including CCTV recording).
  • The recording of a meeting, in video or transcript form, or both.
  • Virtual reality simulations.
  • Social media posts.
  • 3D and digital drawings (e.g., via digital whiteboards).

And, of course, all the data in line of business systems.

Instead of trying to save records into a single EDRM system, Microsoft 365 provides the ability to apply controls over the management of most records where they were created or captured – in email (including archived social media and other records), Teams chat, SharePoint, or OneDrive, and Yammer.

Is there a need for an EDRMS?

There is nothing stopping organisations acquiring and implementing traditional EDRM systems, or even setting up some SharePoint sites, to manage certain high value or permanent records, including some records that can be copied from other create/capture systems (such as email).

But there is also a need to address the management of all other records that remain in the systems where they were created or captured.

In most modern organisations, this requires broader controls such as applying minimum retention periods at the backend, monitoring usage and activity, and the proactive management of disposals. Not trying to copy them all to SharePoint.

Featured image: Lorenz Stoer, late 1500s.