Posted in Correspondence Management, Flow, Information Management, Microsoft Teams, Office 365 Groups, Products and applications, SharePoint Online, Solutions

Managing correspondence in SharePoint Online including using Teams and Flow

Many (if not most) organisations receive and respond to correspondence in the form of letters or emails. They may also respond to social media messages.

Correspondence may be managed in different ways. For example, some organisations may have a dedicated business correspondence unit while in others individuals or business areas may respond.

This post describes how SharePoint Online with MS Teams and MS Flow could be used to manage letters and emails that require a formal ‘organisational’ response. It does not look at managing responses to social media messages.

Core elements

The management of correspondence that requires a formal response generally involves the following elements:

  • Somewhere to store the incoming correspondence (including scanned paper documents) and responses.
  • A description of the correspondence (naming conventions and/or metadata).
  • Some form of workflow, including emails, used to notify people of actions they must take.
  • Various methods use to report on and track progress, and closure/completion rates.

SharePoint includes all these elements. The requirement for workflow can be met using emails, the built-in workflows, workflows built in SharePoint Designer, or MS Flow. MS Teams provides the opportunity to add additional value to the communication response process by allowing messaging, co-authoring of responses, approval processes, and more.

A model correspondence system

The model correspondence system described below is based on a correspondence management system that I developed for a large public sector organisation a few years ago, but using a different system.

The core elements of the model system are:

  • An Office 365 (O365) Group. The O365 Group has an email address and an associated SharePoint site.
  • The Office 365 Group’s SharePoint site.
  • A Team in MS Teams, connected to the O365 Group.
  • Microsoft Flow.

Office 365 Group

The O365 Group should have a name that reflects its purpose and makes it easy to recognise as it also becomes the email address name.

  • For example ‘GRP_Correspondence’ – the prefix ‘GRP’ is used as it defines it as an O365 Group, as opposed to a Security Group (SG) or Distribution List (DL) created under the same ‘Groups’ section in the O365 Admin portal.

The Members of the Group should be the group of people primarily responsible for managing responses to the correspondence. Other people can be invited to the SharePoint site directly (without having access to the Group’s Team) as Members or Visitors.

SharePoint site

The O365 Group’s SharePoint site has the same name in the URL – GRP_Correspondence.

The SPO site should have at least one document library with an obvious name, for example ‘Correspondence 2019’.

If there is concern about potentially long URL lengths, the library name could be reduced to, say ‘Corro2019’; the display name can still be ‘Correspondence 2019’.

Consideration might also be given to having a ‘drop off library’ in the Group site where anyone can save correspondence that may require a response.

The metadata required in the document library will vary between organisations. The core default metadata (for every new document library) already includes all the following:

  • Title
  • Created (date)
  • Created by
  • Modified (date)
  • Modified by
  • Version
  • Document ID (when enabled as a Site Collection feature, which is recommended)
  • Shared with
  • Shared with details
  • Check In Comment
  • Checked Out To
  • File Size
  • Folder Child Count
  • Item Child Count (shows how many documents in a folder)
  • Label setting
  • Retention label
  • Retention label Applied
  • Sensitivity

Additional metadata may include any of the following:

  • Sender (free text or potentially drop down choice)
  • Response Due date (Date)
  • Urgency (Choice – Routine, Urgent)
  • Description (free text)
  • Reply Status (Choice – Not required, Draft, Approved, Sent, Cancelled)
  • Response Type (Not required, By email, By letter)
  • Approved by (internal Active Directory name)
  • Date Completed (Date) < This date should correspond to the date on any reply.

Once the library has been created, content can be added.

  • Paper correspondence can be scanned and saved to the library. Many MFD (printers) now have the ability to save directly to SharePoint, perhaps to a drop-off library for categorisation and review before being moved to the primary library. The original paper can then be boxed and destroyed after a given period (3 – 6 months).
  • Emails can (and should) be copied from the Group’s inbox to the library (see screenshot below). To do this, sync the library to File Explorer and drag and drop.


A new folder can be created for each new correspondence, as indicated in the screenshot below:


Naming conventions

Both the correspondence and the folders where it is stored should be named according to naming conventions. Naming conventions can also be used instead of folders, to indicate the connection between the original and the reply. My preference is to use folders to group the original and the reply, and also because they are ubiquitous in the digital workplace.

Suggested naming conventions:

  • Folders: Surname-Subject-Date
  • Emails: EMAIL-Surname-Subject-Date
  • Documents: LETTER-Surname-Subject-Date
  • Replies: REPLY-Surname-Subject-Date-DRAFT or FINAL (the final version may be ‘signed’ and then saved as a PDF)

Always exclude spaces in names, as these will be replaced by ‘%20’ in the URL path.

If one or more standard templates are required for replies:

  • Create the new Site Content Type in the Site Content Types area.
  • Enable the management of content types in the ‘Advanced’ section of the document library settings.
  • Add the new Site CT to the library
  • Add or edit the Word template to be used by clicking on the Content Type in the ‘Content Types’ section, then clicking on ‘Advanced settings’ and ‘upload’. The template can continue to be modified as required directly from this area and ensures consistency in replies.

The new Content Type will appear in the ‘New’ menu in the document library but not in the MS Teams ‘New’ dialogue (see below). This means that standard replies using a template can only (currently) be created via the SharePoint library. Drafts, however, could be created with a standard document template first (same with emails, see below).

SharePoint New options

MS Team

The Team in MS Teams can be connected to the O365 Group (it’s a one to one relationship, you cannot connected multiple O365 Groups with a single MS Team).

The Team can have multiple channels, and the SPO document library can be presented in a channel. For example, the channel named ‘Correspondence 2019’ includes the ‘Correspondence 2019’ document library as a tab, as shown below.


The use of Teams means allows drafts to be co-authored and chats to take place about the correspondence and other matters.

If the SharePoint site includes an ‘incoming correspondence’ drop off library, the Team could have a channel with that library as a tab. The channel could then be used to review and decide on what to do with the correspondence.

Routing incoming correspondence for a reply

Once the correspondence is saved in a SharePoint document library, a decision must be taken by someone whether a reply is required.

  • If no reply is required, this can be reflected in the metadata (‘No reply required’).
  • If a reply is required, the correspondence must be ‘sent’ or otherwise made available (see below) to someone to draft a reply. This can be a simple or complex process.
    • In some cases, a standard reply may be possible. The SharePoint site should contain at least one library that contains examples of standard replies to certain types of, or common, questions.

Simple routing

The easiest way to ‘send’ someone the correspondence for action is to use the ‘Share’ option on the folder where the incoming correspondence is stored. As the same ‘Share’ option appears in File Explorer when the library is synced, the sharing process can also be managed from File Explorer.

This means that the recipient only has to click on the folder link in the email they receive to see the content of the folder. As they have access to the folder, they can then use the ‘New’ option to create a draft reply, including to an email.


Once the draft has been finalised, it can also be sent via the ‘Share’ option. Alternatively, an alert on the library will notify anyone who needs to be notified that a change has been made to the library.

Routing using MS Flow

A more complex routing process may be required if the draft requires several steps, for example:

  • Send to someone to create the draft reply.
  • Draft reply gets sent to someone else for approval.
    • If not approved, goes back to the person who created it. (This can loop several times)
    • If approved, a message is sent to the person who needs to finalise it
  • Reply is finalised, metadata is updated, and reply sent.

All SharePoint Online libraries include an in-built Flow workflow ‘Request Sign Off’. When a document is selected and the ‘Request Sign Off’ option is selected the first time, the person must select the option to ‘Create Flow’. The ‘Run Flow’ dialogue then appears, requiring someone to be identified as the Approver and a Message to be included. The approver can be anyone in the organisation, for example the person’s manager.



The Approver receives an email, allowing them to approve or reject, and add a comment. If rejected, the ‘Sign Off Status’ column in the SharePoint library is updated to ‘Rejected’, and the sender receives a message to advice them that approval was rejected.


If approved, the sender receives an email to notify them, and the ‘Sign off status’ column changes to ‘Approved’.

Once the reply has been approved, it can be finalised and sent to the person who wrote the correspondence. All versions of the draft reply are kept in the same folder, along with the final.

Email replies

Once approved, any email reply could be sent directly to the correspondent from the O365 Group’s mailbox.


Metadata from the document library can be exported to Excel, or to business intelligence systems (or PowerBI) for analysis and reporting purposes.

Summing up

Correspondence can be managed in SharePoint, with MS Teams used to provide additional co-authoring and ‘chat’ options for the team, and MS Flow used for more complex approval requirements.



Posted in Classification, Electronic records, Governance, Information Management, Records management, Retention and disposal

Mapping complex records retention and disposal classes to Office 365 retention labels – examples

In my previous post on this subject I noted that:

Organisations that have complex records retention schedules/disposal authorities should consider grouping retention classes that have the same retention period into a single generic policy

This post provides examples how this outcome can be achieved based on real life examples from the private and public sectors.

Note – I have spent over 20 years creating and managing records retention schedules and disposal authorities, as well as the application of those schedules, for a range of private and public sector organisations.

What are complex records retention schedules / disposal authorities?

There are two main types of complex records retention schedules or disposal authorities. For ease of reference, I will refer to both as ‘retention schedules’.

Complex retention schedules usually contain a (very) large number of ‘classes’ that (a) describe various types of records across the organisation, and (b) define how long those records must be retained before they can be destroyed.

They have two common features:

  • Multiple classes for different types of records, with the same retention period. 
  • Repetition of the same class (type of records) found across multiple business areas. For example ‘Policy’, or ‘Procedures’, or ‘Reporting’.

What are Office 365 records retention labels/policies?

Office 365 records retention labels are created in the Office 365 Security and Compliance admin portal under the ‘Classifications – Retention’ section. Retention labels describe types of records and define how long they should be kept before disposal.

Labels become active when they are published as retention policies. The publishing process includes a decision on where the labels will be used, for example ‘All locations’ or specific locations such as SharePoint only (or a SharePoint site).

When Office 365 retention labels/policies are applied to a document library in SharePoint, any policy that has been assigned to all of SharePoint and to that specific site, will appear in a drop down list.

In organisations with complex retention schedules, a very long drop down list of retention policies will be visible, but only one can be selected per library.

A private sector example

The retention schedule used in this example has around 150 classes grouped by recognizable business ‘subjects’ or ‘functions’ (e.g., Executive, IT, Property, HR, Finance, etc).

Many of the classes in this schedule require records to be kept for a minimum of 7 years. For example:

  • Records of company meetings and committees. (Executive)
  • Final versions of the official minutes of all other organisational meetings and committees. (Executive)
  • Official correspondence between the organisation and other organisations, including government agencies, not covered by any other class. (Executive)
  • Any document that is used to prepare financials. (Finance)
  • Staff rosters. (HR)
  • Records relating to the preparation or delivery of training to employees. Includes training needs analysis, competency and training profile, training and session plans. (HR)
  • Records relating to WHS management system and system maintenance. Includes: document issue and review forms, document control register, and schedules. (HR)
  • Records relating to the registration of the organisation’s vehicles. (Fleet)
  • IT System related documents, including documents detailing system parameters, usage patterns, system specifications. (IT)
  • All tender records relating to the design, construction, or fit-out of a property. (Property)
  • Register of visitors. (Property)
  • Records relating to the notification of notifiable diseases in any facility operated by the organisation. (Core business)
  • Plus many others.

Office 365 retention labels for private sector organisations

All the classes with the same common retention period could be grouped into a single Office 365 retention label named ‘Company records – 7 years‘. Other labels with the same retention period may also be created if it is necessary to specify certain types of content. The screenshot below (example only) shows how this might appear in the drop down list when the label is applied to a library:


End-users would not normally be responsible for assigning a retention policy to a document library; that job would probably fall to the Site Owners or the Site Collection Administrators (SCAs).

If the site or library contains a specific type of records that are defined by a distinct label, that label would be selected. Otherwise, the ‘generic’ 7 year retention policy label can be applied. If the Owners or Administrators are unsure which label to apply, they can check the full retention schedule to confirm the required retention period.

Note – as soon as a retention label is applied, no record in the library can be deleted. It may therefore be better to apply a label only to inactive libraries.

A public sector example

Many records retention and disposal authorities used by government agencies in Australia are based on the ‘function’ and ‘activity’ model that was introduced in the late 1990s.

  • Each agency has ‘core’ business functions that are often defined in enabling legislation. (Local government agencies are the exception; their functions are similar).
  • Each agency also has a range of general, or ‘common administrative’, functions that are common to most agencies, for example Financial Management, Information Management, Personnel, Property.
  • A range of activities are undertaken within each function. These activities are (usually) what produce records. Some of these activities are common to multiple functions; for example, ‘Agreements’, ‘Planning’, ‘Policy’, ‘Procedures’, ‘Reporting’ and ‘Reviewing’ are found in many business functions.
  • Each activity includes one or more classes (descriptions) of records, each with their own retention period; some of these may be the same.
  • Activities that are common to multiple functions (e.g., ‘Policy’ or ‘Procedures’)  often have the same retention period defined.

Consequently, a single function may have hundreds of retention classes, many with the same retention requirement.

For example, the disposal authority for the ten core functions of the NSW Department of Corrective Services, listed on the NSW State Records website, has around 225 separate classes. The department also makes use of the General Disposal Authority for administrative type records that are common to all agencies, a further 200 or so classes.

The only way to reduce this number of classes, to make it more usable in Office 365/SharePoint, is to use the model developed by the National Archives of Australia.

Office 365 retention labels for public sector agencies

Records Authorities (RAs) produced by the National Archives of Australia (NAA) are based on the same underlying structure (function/activity) but with a much simpler structure.

For each business function, all activities with the same retention period are grouped. In some cases, this may mean increasing (or decreasing) the retention period for some records in order to simplify the model. For example, if records are to be kept for 5 or 6 years, increasing this to 7 years.

This results in a more streamlined retention model for each function. Typically, each function will have 4 – 5 retention classes, for example:

  • Retain as Archives (e.g. transfer to the Archives agency)
  • Keep for 30 years (in the agency)
  • Keep for 7 years
  • Keep for 3 years

However, even with this model, agencies with multiple functions could still potentially end up with a lot of retention labels/policies. To get around this and reduce the number of retention classes, classes with the same retention requirement in different functions could still be grouped. For example ‘Retain as Archives’ is completely understandable, as is ‘Keep (for a long time)’ in the agency – often defined as ‘Retain permanently’.


Posted in Classification, Electronic records, Governance, Information Management, Office 365, Records management, Retention and disposal, SharePoint Online

Mapping complex records retention and disposal classes to Office 365 retention labels

UPDATE (9 October 2019) – based on multiple requests, I will post examples describing ways to map complex retention schedules to Office 365 retention labels in the next post.

Records retention schedules, also known as disposal schedules or authorities, usually consist of multiple ‘classes’ of records that describe or define (a) a logical grouping of records (e.g., ‘financial records’) and (b) a period the defines how long those records must be kept after a ‘trigger event’ (e.g., ‘date created’ or ‘date last modified’) before they can be destroyed.

Records retention schedules/disposal authorities may can take multiple forms. They may:

  • Be subject-based and describe specific types of records. For example, ‘financial records’, ‘client records’, ‘property records’.
  • Map to the business functions and activities or file plan of the organisation, especially where records are grouped in this way. For example, ‘FINANCIAL MANAGEMENT – Accounting’ or ‘CLIENT MANAGEMENT – Cases’.
  • Be ‘rolled up’ by disposal period.  For example, all records with a 7 year retention period, regardless of the subject, business function/activity, or file plan. As we will see below, this method may be most suited for organisations with complex retention schedules that are deploying Office 365 retention policies.

This post describes how individual classes in these different forms of records retention schedules/disposal authorities can and, for the first two options above, will probably need to be mapped to Office 365 retention labels and policies.

Note – this post does not discuss the use of SharePoint site policies, which are used to apply a retention policy to an entire SharePoint site. This subject will be addressed in a separate post.

Office 365 Retention Labels and Policies

Somewhat confusingly, retention classes in Office 365 are created as ‘retention labels’ in the Classification section of the Office 365 Security and Compliance admin portal but are not active until they are published as retention policies.

Retention labels define types of records that can be covered by a single retention period. They can include any Business Classification or File Plan descriptors. The period of time that records are retained is based on one of: (a) date created, (b) date modified, or (c) date the label was applied. Disposal may result a ‘disposition review’ or the records may be destroyed automatically.

Retention labels must be published to become active. The publishing process includes a decision about the Office 365 locations where the retention label will be applied; the options are :

  • All of Exchange email, SharePoint, OneDrive and Office 365 Groups.
  • Any of the above, including specific mailboxes, SharePoint sites, OneDrive accounts, or Office 365 Groups.


It is essential to understand the way retention labels/policies will work in your environment as there is potential to conflict with other forms of retention. For example:

  • End-user Exchange mailboxes are essentially a ‘personal’ storage location for emails (and attachments to emails) on a range of subjects. Many organisations retain Exchange mailboxes ‘as is’ for a period of time after the owner leaves the organisation. Until that time, there is no way to (a) consistently apply retention policies automatically or (b) enforce the folder structure of the inbox. Accordingly, it may not be practical to apply a retention policy to Exchange mailboxes. A long-held records management ‘requirement’ is to move business related emails to a document management system (EDMS), but unless this is automated it relies on the end-user.
  • End-user OneDrive for Business (ODfB) accounts are similar to Exchange mailboxes in that they are the ‘personal’ storage location for documents on a range of subjects. The contents of these ODfB accounts are invisible to the organisation until the person leaves the organisation (although a Global Admin can access, if required). Consequently, organisations: (a) may try to encourage end-users to not keep the final version of work records in their ODfB accounts, (b) apply a standard retention policy to all ODfB accounts after the end-users leave. When this period expires, a delegated person (manager or IT) can access and review the contents.
  • Office 365 Groups include Outlook conversations and MS Teams teams chat. This makes them somewhat similar to Exchange mailboxes. However, a key difference is that Office 365 Groups are emailed enabled; with careful thought, this means that instead of asking people to email an individual on a given subject, they could email the Office 365 Group, which would be a more efficient way to keep the records.

This effectively leaves SharePoint which is the primary storage location for records (including emails if they are copied) as the main location where retention labels/policies will be applied.

How retention labels/policies are applied in SharePoint

Once they have been published to SharePoint, and unless they are published to a  specific site only, retention labels/policies become visible and available for use in every library and list across all SharePoint sites, via the Library or List Settings – ‘Apply a label to items in this library’.



As can be seen above, there is a single drop down list to choose from. A few observations are worth noting:

  • Someone will need to apply the policy to the library. This will probably be either the Site Collection Administrators (usually IT but could include RM) or the Site Owner/s (usually the business unit). You cannot reasonably expect end-users to do this, or to do it consistently and accurately. Note that the auto-application of retention policies may be possible in some limited circumstances and with certain types of licences, but care needs to be taken when deploying these options.
  • Once a retention policy is applied, nothing can be deleted from the library or list. This means that it may be better to apply a retention policy only when a library is inactive (because end users like to delete content in active libraries).
  • The list of policies to choose from should not be too long, perhaps no more than 30.
  • The text of each choice should be self explanatory and not ambiguous. Fortunately, any description added to the policy will appear when the cursor is hovered over the choice.

The third point above highlights a potential issue if there are complex or many records retention/disposal classes. There is probably no point in listing every single class that has the same 7 year retention period. Instead, it may be useful to create a ‘generic’ retention policy for records that all need to be kept for the same period of time (Company records – Retain for 7 years) and, if required, another for specific types of records that need to be identified separately but may have the same retention policy (Financial records – Retain for 7 years).

If your SharePoint site architecture maps generally to business functions (site names) and activities (library names), this can provide the context required to allow ‘mapping’ of records back to the original records retention schedule or disposal authority.

  • For example, if your site name is ‘FinanceAP’ (display name ‘Finance – Accounts Payable’), and you have a library named ‘Invoices2019’ (display name ‘Invoices 2019’) it should be possible to apply a generic 7 year retention policy, mapping it back to the more specific class. If the records are to be subject to a disposition review at the end of the retention period, their context should be obvious.

As noted in a previous post, one of the weaknesses in the current Office 365 disposition review process is that records appear for disposal review as individual records. It is of course possible to group the records using filters in the disposition review window but, ideally, the records management team should use the disposition review alerts to then:

  • access and review the complete original document library and, if the contents are ready for disposal;
  • export the full set of metadata;
  • delete the entire library (not just the individual records in it); then
  • record this disposal action.


Organisations that have complex records retention schedules/disposal authorities should consider grouping retention classes that have the same retention period into a single generic policy, to avoid a very long ‘drop down’ selection option.

The site and library names (e.g., ‘ should provide the necessary context to retention schedules/disposal authorities that are based on a Business Classification Scheme or File Plan. Note that, while business functions could be used for the site name, there may be a need for many more sites than functions. It may be useful to consider ‘sub functions’ that can be grouped under the primary function.  

Office 365 records retention labels/policies should not be published to Exchange mailboxes or OneDrive for Business accounts because it is not practical to expect end-users to apply retention policies correctly or appropriately. Instead, these accounts should be subject to a single retention policy after the end-user leaves the organisation.

Posted in Disasters, Electronic records, Information Management, Information Security, Legal, Office 365, Records management, Retention and disposal, SharePoint Online, Training and education

Why is it so hard to ‘go digital’?

I visited a local fast-food outlet recently and could not help but notice the ‘Lever Arch’ binders in the small office behind the counter. A small two-drawer filing cabinet was also located below the desk.


It made me wonder – in this day and age when pretty much everyone has access to the internet including via their smart phone, why are there any paper records?

And, why is it so hard to ‘go digital’, when so many better and safer digital options are available?

Reasons for not going digital

People probably want to keep paper records in this digital age for a few fairly common reasons, all of which I’ve encountered over the years.

  • Ease of access. It is much ‘easier’ to access a record if it’s in the folder with an obvious name, like ‘Rosters’.
  • Speed of access. You can access a paper record in a couple of seconds. Accessing the same record on a computer means logging on then searching or navigating to where it is stored (potentially including on personal removable storage devices).
  • Easier to archive. At the end of a given period the records can ‘simply’ be placed in an archive box and sent off for archiving.
  • Keeping digital records is too ‘hard’.
  • The company doesn’t offer any other option.
  • ‘Computers are hard’.
  • No obvious or pressing business reason to go digital.
  • A preference for paper, or belief that paper records must be kept.

Which of the above have you encountered? Let me know via this anonymous Form:

Or click this link:

Keeping paper records can be risky

Keeping paper records can be all well and good, unless this sort of thing happens:


If you keep paper records when better digital options exist, you are taking a calculated risk that doing so is ‘OK’.

Of course, not all businesses (a) store the only copy of their physical records locally or (b) burn down (including by being constructed in fire-prone areas). However, these are not the only risks. Other risks include:

  • Flooding, from burst pipes, storms, or floodwaters. Water-damaged records are not easy to recover.
  • Damage from falling objects, including trees or other objects falling from the sky.
  • Theft or vandalism.
  • Business closure and leaving records behind in the abandoned building.
  • Any combination of the above.

What’s the back up for physical records?

What’s the back up for these paper records when disaster strikes?

Generally, unless the physical records have been transferred off-site, or they are the printed version of a digital original that can still be accessed, there isn’t one.

Is there a better, digital way?


Printed records are likely to fall into several broad categories, each of which can be managed in their own way. For example, in the business above:

  • Policies and procedures, including ‘operating manuals’ and similar types of instructions are likely to be the printed version of digital originals. They can be made available on the company intranet or, if one doesn’t exist, sent via email.
  • Financial records (e.g., invoices). Again, these are likely to be the printed version of a digital original. If they were in printed form when received (e.g., by mail, with a delivery), the company should (a) ask for digital copies to be sent by email, or (b) scan them and store them digitally.
  • Rosters and general documents relating to groups of employees (as opposed to individual staff ‘files’). Rosters could still be printed for display purposes, but the original should be kept in digital form.
  • Staff files. The format of these may depend on the organisation, but there should be no reason for ‘local’ staff files to be kept in an organisation that has a centralised HR system.
  • Other types of business documents. If necessary, these could be scanned and kept in digital form.

And, of course, all of these could be kept in Office 365, including SharePoint for document storage and MS Teams for teams chat, including for front line workers.

Additional training and support may be required to help these areas ‘go digital’.