Posted in Governance, Information Management, Microsoft Teams, Office 365, Office 365 Groups, Records management

Creating a Team in MS Teams creates a SharePoint site – and more

In recent weeks a number of organisations with ‘default’ Office 365 configuration settings have told me they are not using SharePoint but they are using MS Teams, and have even created new Teams.

Every new Team in MS Teams creates a linked SharePoint site via the Office 365 Group that is created when the Team is created. If the ability to create Office 365 Groups is not restricted the following is likely to happen:

  • Naming conventions go out the window. New Teams and SharePoint sites will probably be created with random names (eg ‘Andrews Team’, ‘Footy tipping’).
  • The SharePoint environment will ‘go feral’; new sites will not be provisioned according to business requirements.

This post describes what happens when a Team is created and recommends the creation of new Teams by creating an Office 365 Group.

What happens when a Team is created

At the bottom left of the MS Teams client is the option to ‘Join or create a team’. This option will be visible even if the ability to create Teams is not enabled for end users (because the control is on the creation of Office 365 Groups).


The dialogue box that opens gives the option to ‘Create Team’.


The user now has the choice to build a new team from scratch or create it from an existing Office 365 group or team. For the purposes of this post, we will assume the user chooses the first option.


The user is then asked if the team should be private, public or organisation wide. The options will affect the visibility of the Team to others. For the purpose of this post, the new Team is ‘Private’.

The next option is to name the site (‘Footy Tipping’) and give it a description.


The user is then prompted to add members (people who have edit rights) to the new Team. They may add individuals by name, a distribution list, or a security group. If external access is allowed, they may also add people outside the organization as guests. People or groups that are added are made ‘Members’ by default but this may be changed to ‘Owners’.

A key point here is who will have access to the Team if there is a single Owner. What if that person leaves the organisation?

The new Team has been created with a ‘General’ channel. The three dots to the right of the name allow the Owner to modify the members of the Team, add channels, get a link to the Team (to send to others and delete the Team.


Along the top of the new Team are three default tab: Posts, Files, Wiki.

The ‘Files’ tab appears (for those who are new to this) to allow documents to be uploaded to the Team, Synced to their File Explorer and so on. This is actually the default Documents library of the SharePoint site that is created when the Office 365 Group is created when the Team is created.


What happens in Office 365 Groups

The end user is not likely to care much about what happens anywhere else, they have a new Team and can start chatting.

Meanwhile, in the Groups area of the Office 365 Admin portal, a new Office 365 Group appears. The Global Administrator should be keeping an eye on the creation of new Groups, if they are not controlled, especially if there is a requirement to adhere to naming conventions for all AD Groups (Distribution Lists, Security Groups, and Office 365 Groups).

The Group name has had the space removed in the Group’s email address (and, as we will see, in the SharePoint site). The Global Admin can review and change the Members.


The Global Admin may also changed the settings to allow external senders to email the Group and to send copies of Group conversations (in Outlook, see below) and events to Group members. (The Microsoft Teams settings takes the Global Admin to the MS Teams Admin portal).


So, an end user has ‘simply’ created a Team, but now there is a new Office 365 Group with a mailbox (not visible but can receive emails) and a SharePoint site.

What happens in Outlook

Every new Office 365 Group has an Exchange mailbox, similar to a shared mailbox, but when a new Team is created from MS Teams, the mailbox is not visible in Outlook. If the Global admin enables the ability to ‘send copies of group conversations and events to group members’, the group members may use that Group’s mailbox address.

The mailbox is visible when a Group is created first, which is a good reason to create a new Team by creating the Office 365 Group first.

Channel chat message are stored in a hidden folder in the Group’s mailbox, where they are subject to any retention policy applied to the chat messages, separate from any retention policy applied to the mailbox.

What happens in SharePoint

As noted already, every new Team gets a SharePoint site because the Team has created an Office 365 Group.

The SharePoint Admin will see the new site in the SharePoint admin portal:


The SharePoint Admin may, via the ‘Permissions’ section, view and update the Group Owner/s and also may add additional ‘Admins’. They may make the site a Hub site and decide whether the site can be shared externally or not (the default is not shared externally).


The SharePoint admin may also delete the site – but consider that it is not now just a site but a Team and also an Office 365 Group. Some care needs to be taken here – which should be deleted first, and what happens if a retention policy has been applied to the Teams channel or the Office 365 Group?

If the SharePoint admin opens the site they will see a standard ‘modern’ team site with a single default document library. This is the ‘Files’ library that appears as a tab in the Teams General channel.

In the Permissions section of the site, the Site Owners show as the Team owners group, and the Site members (add/edit rights) show as the Team members group. There are no site visitors.


If the SharePoint admin goes to Advanced permissions settings and clicks on Site Collection Administrators they will see that only the Footy Tipping Owners are in this section. Organisations should consider adding a Security Group, that includes any records or information managers, in this section. Otherwise, any records will be more difficult to manage and the records managers will need to request access from the SharePoint admin.


Two important points that are sometimes missed:

  • Aside from the Global and SharePoint admin, only the Team Owners and Members can access the SharePoint site.
  • The SharePoint site may be shared with another person (or Group) and given Member or Visitor access but this does NOT give them access to the Team channel. They need to be added to the Team Owners or Members to have access to the Team channel.


Allowing end users to create a Team in MS Teams has a flow-on effect:

  • It creates an Office 365 Group with an associated SharePoint site
  • It creates an Exchange mailbox
  • It will (initially, unless this is changed) make the SharePoint site inaccessible to records managers.
  • It gets complicated if it is decided to delete the Team, SharePoint site, or Office 365 Group.

It is recommended, in organisations rolling out MS Teams to end users, that the ability to create Office 365 Groups is disabled except for Global Admins, and any new Team is created from a new Office 365 Group that includes the option to ‘Add Microsoft Teams to your group’, as shown below:


This will result in the following outcomes:

  • Controlled creation of Office 365 Groups, SharePoint sites and Teams, with appropriate naming conventions.
  • A new and visible mailbox for both the Group and the Team.
  • Stop SharePoint from ‘going feral’ and becoming uncontrolled.
  • Establish better governance controls for recordkeeping.



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

Shifting the paradigm for managing records – from EDRMS to Office 365

Computer systems used to to manage electronic documents and records, commonly known as ‘EDRMS’, have been around for at least 20 years.

Many (but not all) of these systems developed from electronic databases originally used to register and manage only paper records, replacing the old paper registers (hence ‘Registries’).

How does an EDRMS work

A common theme with most EDRM systems is that they describe (via metadata) and provide some kind of visual ‘file’ or ‘folder’ structure for digital objects, almost always stored in a linked network file store.

To store records in this way, EDRM systems required end-users to upload a copy of a digital object (document, email, photograph) to a pre-defined digital container, corresponding to a ‘file’ or ‘folder’. The digital file might have be assigned a range of metadata including the classification (business function and activity) or file plan details, title, business owner or area, and retention information.

Once an object was uploaded, end users were required to add metadata about the object, including the object ‘title’ (if it didn’t copy the original title). Additional metadata fields, for example ‘Document Type’, might also be required.

The system recorded the date and time the object was uploaded and who uploaded it. As noted, the system might copy some of the uploaded object’s metadata, for example the default title, date created and author.

The uploaded document then ‘became’ a record, visible ‘within’ a digital container (‘file’) along with other records.


EDRM systems had (at least) three weaknesses:

  • End-users were required to upload the records to the EDRMS, and to one correct container (file/folder)
  • The EDRMS contained a copy of a digital object that almost always remained in the original storage location (email, network file share)
  • The EDRMS tended to be based on records as documents (including emails, and sometimes photos). Newly evolving forms of record such as text messages, social media posts and new digital forms were difficult to upload without costly add-ons that didn’t necessarily capture everything

These weaknesses meant that:

  • End users avoided uploading records because it was extra work (uploading and then adding metadata)
  • The EDRMS contained only a percentage of all potential records stored in any location
  • The original copies of records, remained in email and network file shares

There were exceptions to this situation, but most (and very much in the minority in terms of total volume) involved the requirement to meet compliance obligations to capture certain types of records.

The Office 365 model

Microsoft took a different approach with the approach to records management in Office 365.

Instead of centralising the storage of records in one system or location (with the weaknesses described above), records in the Office 365 environment generally remain in their original location (Exchange Online, SharePoint Online, OneDrive for Business, MS Teams), where they are covered by an overarching records management framework.

The Office 365 model for records management

What this means is that records can be stored in any of the above locations and managed in those locations through (among other things):

  • User types, licences and roles set in the Office 365 admin portal
  • Retention and other controls set in the Office 365 Security and Compliance admin portal/s (the two were split in early January 2020).

How the paradigm shifted

The paradigm has shifted from (a) an attempt to manage records in a single system where not everything is captured and originals remain in place in email and network file shares, to (b) the distributed management of records where originals remain in place (assuming SharePoint and OneDrive are used instead of network file shares and personal drives, and email remain in Exchange) and records are managed through ‘global’ settings.

The new paradigm does not exclude the ability to store (or aim to store) digital records in a single location – SharePoint Online (including for specific compliance reasons), but it provides the opportunity manage records wherever they are and use a range of additional tools to manage content from creation through to disposal.

Why the new paradigm matters

The new paradigm is likely to be counter-intuitive to many records (and other information) managers. Records management training for many years has been focused on the idea of storing and managing records in a central location with specific controls (classification, metadata and retention).

But the reality is that there are now too many digital records, and too many types of digital records, to ever expect these to be all stored in an EDRMS. And, even if only some are, what about all the others? Has a legal subpoena ever been focused only on records stored in the EDRMS?

Plan to manage records

Many organisations have acquired and are implementing Office 365, sometimes at the expense of the traditional EDRMS. It doesn’t take long for end-users to adopt the new technology because it is so easy to use.

Any suggestion that specific records now need to be copied to the EDRMS seems to be counter-intuitive. And yet, that is how some records managers continue to see Office 365 – as yet another source of records to be uploaded to the EDRMS. It is not a viable plan.

Records managers need to be at the forefront of planning for Office 365, in particular managing content across the four primary workloads. Records managers should be able to provide advice on:

  • The architecture of SharePoint Online
  • Controls around the creation of sites, including naming conventions and the ongoing management of sites
  • The structure of SharePoint Online sites, document libraries and metadata in particular
  • The retention model for Exchange Online, SharePoint Online, OneDrive for Business, MS Teams. This includes understanding existing disaster recovery arrangements and potentially replacing them with retention policies.
  • Disposal actions
  • Other compliance obligations

Plan for change

Moving away from the centralised management of records in an EDRMS to a less visible (for end-users) decentralised model, or even implementing Office 365 without any other previous document and records management system, requires careful change management.

End users (and records managers) used to the idea of uploading records to a central EDRMS may find the new ‘invisible’ and decentralised model of recordkeeping unusually simple (to the point of disbelief).

Consequently, additional re-assurance, training and awareness sessions, may be required to demonstrate and confirm how the records are managed in the new environment. There is potential for some ‘push back’ as, although it requires very little end-user effort, it manages more records than ever before, including in ‘personal’ spaces such as mailboxes and personal drives.

IT will also need to be involved as disaster recovery processes, such as backing up email and network file shares, may no longer be required.

For end users who have never had to use an EDRMS, change management activities might focus more on improving awareness and knowledge about how records will be managed in the future, including in ‘personal’ spaces.


Posted in Classification, Compliance, Electronic records, Governance, Information Management, Legal, Office 365, Office 365 Groups, Products and applications, Records management, SharePoint Online, Training and education

AI curated chaos or control – the equally valid but opposite ends of the SharePoint spectrum

There are, broadly speaking, two ‘bookend’ options when it comes to creating new SharePoint Online sites and the document libraries in those sites:

  • ‘Controlled’ model: The creation of new sites is restricted to a small group of individuals with admin rights, who also oversee the creation of document libraries and application of metadata. A combination of controlled and manually applied classification and metadata and retention policies are used to access and manage content over time. Artificial intelligence (AI) tools can also be used to manage content.
  • ‘Chaos/uncontrolled’ model: The creation of new sites, including the creation of document libraries is not restricted. AI tools (including auto-classification) and auto-applied retention policies are used to classify, access and manage content over time. This model assumes that any form of random categorisation applied by end users (e.g., library names, metadata) is mostly ignored by AI tools.

From a traditional information governance and records management (ISO 15498/ISO 16175) point of view, the second ‘chaos’ or uncontrolled model option seems to run counter to conventional wisdom and agreed standards.

From a practical point of view, the first ‘control’ model option seems to run counter to common sense given the volume and range of digital information and the difficulty of classifying or categorising information and records correctly.

Which option is better?

Confusingly, perhaps, the answer may be a combination of both.

  • Certain types of more formal records, such as those required for corporate compliance, formal policies, staff files, accounting information not stored in a finance system, property information, and/or product information, is almost certainly going to be better off in a controlled SharePoint sites with pre-defined libraries and metadata. These types of documents are more likely to be subject to records retention requirements and almost certainly may be subject to eDiscovery and legal holds.
  • Other types of less formal records, including ‘working’ documents, chats and conversations may be better off stored in uncontrolled SharePoint sites, including SharePoint sites linked with Office 365 Groups and Teams, and in MS Teams/Outlook. These types of records are less likely to be subject to records retention requirements but may be subject to eDiscovery and legal holds.

Ultimately, the way the organisation needs to implement Office 365, including SharePoint Online and apply retention policies and other options will depend on its need to comply with oversight and legal requirements (including minimum retention periods), and/or its tolerance for risk.

How does this work in Office 365/SharePoint Online?

If both options Organisations need to make a conscious decision to allow both options, and be prepared to manage both.

The key features of Office 365 and SharePoint to allow both options are listed below:

  • Office 365 retention policies apply to all of Exchange Online, all OneDrive for Business accounts, entire sites (invisible to users) or parts of sites (visible to users).
  • Some retention policies may be applied based on the auto-classification of records, subject to review.
  • The creation of SharePoint sites is either controlled (requested and provisioned) or uncontrolled (created by end users) via either (a) ‘Create sites’ in the end-user SharePoint portal or (b) when a new Team is created in MS Teams.
  • All sites, including Office 365 Group/Team sites are reviewed regularly for activity and inactive sites with no content of value deleted.
  • All controlled sites are assigned either an invisible retention policy or individual visible retention policies (with disposal review), depending on their content.
  • All uncontrolled sites are assigned an invisible retention policy. Uncontrolled and inactive sites with content are also made read only.

Features of controlled and uncontrolled SharePoint sites

SharePoint Online is quite different from older versions of the application and those who dismiss it based on previous experience should consider having another look as a lot has changed in the past couple of years.

SharePoint Online allows the creation of sites that contain important content that needs to be controlled of managed as records, as well as sites created and managed entirely by end-users. And, as an added bonus, all the content is stored in the one place, not in multiple locations (network drives, email servers, EDRM system, etc).

The elements that make up both types of sites, as well as ‘informational’ sites, are described below:

  • Controlled sites
    • Where the organisation’s official records are stored and managed.
    • Created by SharePoint Administrators.
    • More formal in nature, containing the official records.
    • Structure decided by business areas – for example, document libraries using agreed naming conventions.
    • Use of Content Types and site column or local library metadata to define the content.
    • Application of Office 365 retention policies to entire sites or individual document libraries, with disposal reviews. Auto-classification is less likely to be required as the content has already been structured as required.
  • Uncontrolled sites
    • Usually based on end-user created Office 365 Groups or MS Teams.
    • Where ‘working documents’ are created and managed, with the emphasis on allowing end-users collaborate and communicate easily and effectively – and move content to formal sites when required.
    • Created by end-users but naming monitored by SharePoint administrators (or using rules).
    • Informal in nature, used for working documents (effectively replacing personal and network file shares, and other unapproved systems).
    • A fluid structure for document libraries, driven by end-user requirements (not imposed by others).
    • Little if any use of Content Types or metadata.
    • Retention based on Group activity (E5 licences), otherwise based on Office 365 site retention policies and/or auto-classification options.
    • No disposal reviews – content is deleted after a given period of time.
  • Informative
    • Communication sites (e.g., ‘intranet’)
    • Used to publish information to the organisation

Things to watch out for

It is largely true that if you give people an option, someone is bound to try it, sooner or later, especially if it says ‘Create site’, ‘Create team’, or ‘Create group’. Early adopters learn quickly and can just as quickly abandon something that provides no benefit. 

In a ‘free for all’ SharePoint environment, where end-users can create new sites, teams or groups (both of the latter have a SharePoint site), the most likely issues will include:

  • Sites with names that are very similar to ones that already exist, created because the end-user didn’t know another existed (it may not be obvious) or didn’t like the name.
  • Sites with names that make no sense (including common acronyms) or are just ‘wrong’ or contrary to preferred naming conventions.
  • Sites used to create and store content that really should be stored in a more formal site or, conversely, doesn’t belong in the organisation’s official information systems (e.g., photos of someone’s wedding).

All of these issues require some general rules about the creation of new sites (or Office 365 Groups or Teams or Yammer Groups), including suggested naming.

Global and SharePoint admins can monitor the environment and fix issues when they arise rather than wielding a big stick.

What’s great about it

You can have the best of both worlds with SharePoint Online.

  • Keep formal official records in ‘formal’ sites with controlled structures and metadata.
  • Allow end-users to get on with creating, collaborating, sharing (one copy, not attachments), chatting, on any device.

If your communications and change management are good, end-users will soon learn how much fun it can be to use Teams, or access their content from File Explorer (or both!), without having to having to be trained how to save records. All they need to know is how to use the ‘Move’ option to move the final version of records to a formal site.

The foundation of any compliance program is knowing where all of your data lives and then classifying, labeling, and governing it appropriately.

Posted in Governance, Information Management, Office 365, Products and applications, Records management

How many Office 365 Admins do you really need?

Organisations implementing Office 365 probably already have some form of IT support. This support may range from single individuals through to complex IT ‘shops’, or it may be outsourced.

This post:

  • Describes the change from traditional on-premise IT admin to the new world of Office 365 administration, and the admins that are needed.
  • Highlights that Office 365 includes new applications or features that were never part of the on-premise environment and so new skills may be required.
  • Describes the various Office 365 admin roles, and why these should having distinct naming conventions and be cloud-only.
  • Recommends that admin roles are defined in Office 365 governance documentation.

Transitioning from on-premise IT to Office 365

Traditional on-premise IT tended to be focussed on network infrastructure (servers and networks) and Exchange. Depending on the size of the organisation, it might have a single IT specialist or a more complex IT structure with a range of administrators managing different aspects of the network.

When Office 365 is implemented some on-premise infrastructure will likely remain and need to be supported, while some of the previous on-premise administration skills will ‘move’ to the respective online version, for example Exchange to Exchange Online.

Office 365 includes a range of applications some of which are likely to be new to previous on-premise IT administrators. For example:

  • Home or personal drives will be migrated to OneDrive for Business
  • All or some parts of the network file shares will be migrated to SharePoint Online
  • MS Teams is likely to replace any existing messaging apps such as Skype
  • Retention policies can be applied across the core Office 365 workloads
  • Security policies can be implemented
  • Yammer may be used as the enterprise social networking platform
  • Audit logs and eDiscovery are now available

Each of these (and other options) require new skills that may not exist in the existing IT support structures.

Additionally, some traditional IT activities such as backup don’t exist in Office 365. There is likely to be a tendency to try to re-create those on-premise solutions when other options (such as retention management) may be just as effective.

Office 365 Admin roles – Cloud only

Office 365 is entirely based in the Microsoft cloud environment. Office 365 admin roles have no access to any on-premise environment.

Accordingly, key Office 365 admin roles (Exchange, SharePoint/OneDrive, MS Teams, Security and Compliance) should exist only in the cloud and be named accordingly.

Examples of cloud-only admin account names:

  • (Global Admin)
  • (Exchange Admin)
  • (SharePoint Admin)
  • (Security Admin)

A person with global records management responsibility might also need elevated privileges. The account could be:

  • (Records Admin)

There are a couple of exceptions to this model:

  • Reader admin. Office 365 includes various ‘reader’ admin accounts that give an account read-only access to things like the Office 365 Message Centre only. It may be acceptable to assign reader admin to a standard user account.
  • Yammer Admin. Yammer admin has limited funcionality. A Yammer admin sees additional options via the cog/gear icon but otherwise has no elevated privileges. Therefore, a Yammer admin could be assigned to a standard user account.

In every case, every Admin role must have the user name included; there should be no generic admin accounts, ever.

Primary Admin role – Global Administrators

The highest level admin role in Office 365 is the Global Administrator (GA). GAs have access to everything across Office 365 in the same way that an on-premise administrator had access to everything.

A common mistake in organisations that are new to Office 365 is to assign a GA role to a standard user account, often the person or individuals with similar privileges in the on-premise environment.

Microsoft recommend the following:

  • There should only be two or three GAs, no more than five (maximum) with very strong passwords. GA admin activity should be minimal. 
  • Use multi-factor authentication for GA accounts.
  • Only sign in with the dedicated global administrator accounts when carrying out tasks that require global administrator privileges.
  • Carry out other Office 365 administration (Exchange, SharePoint etc) with other administration roles (see below).

Other Office 365 admin roles

A range of other admin roles can be assigned in Office 365. The primary admin roles are for Exchange, SharePoint and MS Teams. Secondary admin roles (that may be performed by the GA in smaller IT shops) are the global reader, help desk and service support admins, and user admin.


In addition to the primary roles above, there are also a range of other admin roles that can be assigned, including the following (plus at least the same amount again).

  • Dynamics 365 admin
  • Groups admin
  • Kaizala admin
  • Office apps admin
  • PowerBI admin
  • Power Platform admin
  • Search admin
  • Cloud device admin
  • Intune admin
  • Licence admin
  • Password admin
  • Billing admin
  • Compliance admin
  • Security admin

The need for each of these admins will depend on the size and structure of the organisation.

So, who does what?

Despite the multiplicity of admin roles, the reality is that most organisations will only have the following and create and assign other admin roles (e.g., Licence Admin, Help Desk admin, Billing Admin) or access (e.g., Global Reader), as required.

  • Global Admins (2 – 5)
  • Exchange Admin
  • SharePoint Admin
  • MS Teams Admin
  • Security/Compliance Admin

There is likely to be some overlap between these roles, especially in relation to the creation and management of Office 365 Groups (if their creation, and therefore also the creation of new Teams in MS Teams, is controlled) and the creation and implementation of retention policies from the Security and Compliance admin centre, as shown in the diagram below.


Governance documentation

However the admin roles are configured, these should be defined in the organisation’s Office 365 governance documentation which should define, for each role:

  • Naming convention
  • Responsibilities
  • Name of actual person with that role
Posted in Compliance, Electronic records, Governance, Information Management, Office 365, Products and applications, Records management, Retention and disposal, SharePoint Online

Planning for records retention in Office 365

Almost ten years ago, in January 2010, I published a post here about the origins of the statute of limitations. The post had the following introduction:

The retention – and eventual disposal – of records is a common business practice, despite occasional concerns about what gets destroyed. Justice Scalia, in Arthur Andersen LLP v United States (No. 04-368, 2004) said as much about the destruction of records relating to Enron by Arthur Anderson:

‘… we all know that what are euphemistically termed “record-retention programs” are, in fact, record-destruction programs, and that one of the purposes of the destruction is to eliminate from the files information that private individuals can use for lawsuits and that Government investigators can use for investigations.’

Almost ten years on, it still seems an appropriate way to introduce a post about the retention of records, this time in relation to records stored in Office 365.

Bottom line – you need to plan for it, and make sure your legal team is consulted.

Blatant plug for a great book

Before you read further, I recommend you have a look at the comprehensive e-book ‘Office 365 for IT Pros‘. This 1000+ page ebook includes, in Chapter 19 – Office 365 Data Governance, a comprehensive description of how to create, apply and manage retention policies in Office 365.

What do we mean by retention?

The retention of records is generally based on business, legal or regulatory requirements to keep certain records for a minimum period of time. In the case of government records, there may also be an archival requirement.

The retention period may relate to or be based on a statute of limitations that governs when potential legal actions expire. For example, simple contracts generally need to be kept for a minimum of six or seven years (depending on jurisdiction after they expire. More complex contracts (including deeds) may need to be kept for much longer.

Records that need to be retained should not be deleted and must remain accessible for the period of time during which the integrity, authenticity and reliability of – and often the context for – the retained records must remain inviolate.

Retention is not IT back up or (or for) disaster recovery

Retention management is not about IT backups or ‘archiving’, or disaster recovery programs. These activities are focused more on the ability to recover data and records.

On-premise to online – a different paradigm

Many organisations have (or should have) records retention schedules, also known as disposal or disposition authorities. Records retention schedules and authorities define what needs to be kept and for how long.

Most records are managed in similar ways:

  • As paper (usually printed from digital records), stored in files and/or boxes. These records may be tracked in a database.
  • As digital records, uploaded to a third-party electronic document management system (EDMS), while leaving the original records stored in Exchange mailboxes or File Explorer.
  • As entire business systems (with little thought given to individual records).
An example of old-style paper file storage. These records are around 20 years old and are well overdue for disposal. 

Into the on-premise mix:

  • MRM policies may be enabled on Exchange mailboxes, allowing end users to apply retention tags to emails. An archiving policy may be in place as well.
  • Individual user mailboxes and ‘home drives’ may be retained for a period of time after the user account is deactivated.
  • There is a backup regime.

Many of the options above will not, or may not, exist (at least in the same way) in Office 365.

On the other hand, Office 365 now includes a range of records retention options that can be used to better manage retention.

Why you need a plan for retention in Office 365

Implementing Office 365 retention policies without a good plan to transition from the on-premise environment, is fraught with potential failure, potential confusion, uncertainty, and legal risk.

To quote from page 882 of Office 365 for IT Pros:

‘… it is wise to take time to chart out how retention will work across the tenant for all workloads before you create any policies. Fools rush to implement retention without thought!

A good starting point is to contact the records management team and get a copy of the organisation’s records retention schedules or authorities to understand what needs to be kept and for how long and also – importantly – where the records are currently stored.

Retention options in Office 365

In simple terms there are two types of retention that can be applied to records in Office 365. The following paraphrases parts of chapter 19 of the book Office 365 for IT Pros.

Explicit (visible) retention policies

This option involves (a) creating retention labels that define a retention period (and if a disposition review is required), (b) publishing the labels as retention policies to specific Office 365 workloads, and (c) applying them manually (including via PS scripts) to content that needs to be retained.

Retention labels published as explicit retention policies can be applied (including automatically, in certain circumstances and/or with an E5 licence) to the following workloads

  • Exchange email (all/select)
  • SPO sites (all/select)
  • ODfB accounts (all/select)
  • O365 groups (all/select)


Implicit (invisible) retention policies

This option involves (a) creating retention policies (that do not include a disposition review) and then (b) applying them to all or specific Office 365 workloads.

Implicit retention policies can be applied to:

  • Exchange email (all/select)
  • SPO sites inc O365 Group sites (all/select)
  • ODfB accounts (all/select)
  • O365 groups (all/select)
  • Skype for Business (specific users)
  • Exchange public folders (all)
  • Teams channel messages (specific teams)
  • Team chats (specific users)

The first four workloads are the same for both types. Which one should you choose – explicit or implicit?

Implicit retention policy

Keep in mind that explicit policies take priority over implicit policies.

Retention policy limits

Both explicit and implicit retention policies have specific limits. You can create:

  • Up to 10 organisation-wide retention policies. For example, all mailboxes, all OneDrive accounts, all SharePoint sites, all Office 365 Groups. 
  • Up to 1000 narrow/specific retention policies. Each of these can point to up to 100 sites, 100 ODfB/O365 group accounts, and 1000 mailboxes. 

These limits, and the difference between explicit and implicit, show why planning for retention is essential.

Questions you might want to ask

Some questions to consider as part of the planning process:

  • For Exchange mailboxes, is it better to have (a) a single implicit policy to keep all  mailboxes for x years, or (b) a single implicit policy that targets only certain mailboxes (e.g., senior managers only), or (c) multiple explicit policies that end-users can apply? What do you do now with Exchange on-premise? Do you journal emails? How will you do that if you go completely online? Could a single implicit policy achieve the same outcome as backing up mailboxes?
  • For OneDrive accounts, is it better to (a) have a single implicit policy to keep all ODfB account for x years, or (b) rely on the ODfB admin storage setting to keep the content after an account becomes inactive (default is 30 days), or (c) have an explicit policy that end users can apply themselves?
  • For SharePoint sites, is it better to (a) have a single implicit policy to keep all SPO sites for x years, or (b) have a single implicit policy applied to up to 100 sites at a time, or (c) create multiple explicit policies that end-users can apply?
  • For Office 365 Groups, is it better to (a) have a single implicit policy, or (b) focus instead on MS Teams channel retention and/or (c) a retention policy for the associated SharePoint sites? Do you have AD premium where Group expiry can be implemented? If yes, should you enable or disable it?

And for all of the above – how will you keep track of what has been applied where?


My suggested recommendations would be:

  • Exchange mailboxes. If the organisation keeps back ups of on-premise mailboxes so these can be recovered after a period of time, remove the default MRM policies and create a single organisation-wide implicit retention policy.
  • OneDrive for Business. For similar reasons to the Exchange mailboxes, create a single organisation-wide implicit retention policy to retain content in user accounts for a given period of time (say, 7 years). Also change the default storage period from 30 days to the same period of time.
  • SharePoint Online. My sense is that a single implicit retention policy for all SharePoint sites is unwise. Retention options should be considered when sites are created. For example, try not to mix (or allows users to mix) content that may have different retention requirements in the same document library – aim to apply the aggregation to the highest level of ‘aggregation’ – site or library. Create labels for and publish a small number of specific explicit retention policies (mapped to the organisation’s records retention schedule). Create one or more implicit policies for specific groups of sites (for example, all inactive project sites). Whatever model you implement, ensure you know if you need to record what was destroyed, including unique metadata from document libraries.
  • Office 365 Groups. The SPO part of Groups can be covered by the SPO retention policy, the email by the Exchange mailbox policy. You may need to consider if you need to create teams chat or channel retention policies.

What happens at the end of the retention period?

So far this post has raised questions about the type of policy you might apply to different workloads.

But what happens when the retention period ends? Should you allow records to be deleted without any kind of disposition review, or check first? This single point may be a key factor in your decision around what type of policy to create and implement, and where.

Some questions to ask:

  • Is is appropriate in your environment for end users to destroy business records by applying a policy?
  • Should someone review the content before it is disposed of?
  • Do you need to keep the metadata associated with content stored in SharePoint document libraries? If yes, where is it going to be stored?
  • Do you need a permanent record of what was destroyed?
  • What do you do if you dispose of something that should not be disposed of?

The answers to these questions may differ depending on the workload to which the retention policy has been applied and whether the retention policy is explicit or implicit.

What does a retention plan look like?

Pages 880 and 881 of Office 365 for IT Pros has an excellent model plan for retention in Office 365. The following (slightly edited) points should be documented for every retention policy that is created and published.

  • Name: It seems obvious, but naming can be important especially for explicit policies. Consider, for explicit policies, adding the retention period to the name, e.g., ‘Company Financial Records – 7 years’.
  • Purpose: What is the purpose of the policy?
  • Retention settings: How long should the content be kept for? Should this be based on when it was created, modified, or when the label was applied? Should there be a disposition review? Who will review the content when it is due for disposition?
  • File Plan: Explicit retention policies can be mapped to a file plan and thereby linked to the retention schedules. If they do, what part of the File Plan should the policy map to?
  • Type: Will the policy be implicit (invisible to users) or explicit (visible to users)?
  • Scope: What Office 365 workloads will this policy cover?
  • Broad or Narrow: Will this policy be applied across an entire workload or to specific mailboxes, sites, accounts? If an explict policy uses retention labels, what are those labels?
  • End of retention: What should happen when the retention period expires? For example, does the metadata need to be kept, should a record be kept of what was destroyed?
  • Lock (optional): Is the content that comes under the scope of the policy considered to be a formal record for the company and if so, is a preservation lock needed? (This option requires additional PowerShell work)

Joint planning is a must

Your organisation is almost certainly going to have business, legal or regulatory requirements for keeping records.

Records managers know how to interpret and apply these to records, and what to do when records reach the end of their retention period. It’s a good idea to consult with these experts, and with your legal team.

It would be a very brave IT shop that unilaterally applies retention policies to records stored in Office 365 without reference to or consultation with records managers, legal teams, or records retention schedules.

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’.



Posted in Flow, Information Management, Microsoft Forms, Office 365, Products and applications, SharePoint Designer, SharePoint Online

Capture data in Microsoft Forms to create a new template agreement in SharePoint

In my previous post I described how to auto-create and populate Word template agreements or other similar types of standard documents in SharePoint from a SharePoint list. This post describes how to capture data in a form in Microsoft (MS) Forms – including from external users – to create a template document. It assumes you have an E3 or E5 licence.


In simple terms the model works as follows:

  • A person completes a form in MS Forms. When saved, a Microsoft Flow workflow copies all or some of that data to a SharePoint list.
  • A workflow created in SharePoint Designer copies all or some of the data in the list to a SharePoint library.
  • After the data is copied to the SharePoint library, another SharePoint Designer workflow auto-creates and populates the Word template as described in my previous post. (This step will not be described again in this post).

Use case

This example model is based on a live working example where:

  • The potential (internal or external) participants of a business area program could register an interest in participating in the program. This was named the ‘Registration of interest‘. Internal participants could register their interest directly in the internal SharePoint list.
  • The data from the MS Form was copied to a SharePoint list called ‘Client Registration‘. Internal users could also register their interest by creating a new item in the list (via newform.aspx). Internal users could only see the items they created, controlled via the list settings. The list included a choice field to indicate if the person had accepted into the program; if they had, some of the data was then copied to the next stage, the ‘Client Register’.
  • The Client Register list, the primary client record which included additional columns used to keep track of the progress of each client, was used to keep a record of anyone who had been accepted into the program. If the person was ready to start the program, the workflow would create the required agreement in a document library.
  • The document library named ‘Client Agreements‘ was used solely to create new agreements and store signed (scanned or saved-as PDF) agreements.

In the details below I describe only three steps, from Forms (via Flow) to a SPO list, then from the list to a SPO library.

Creating the form in MS Forms

The first step is to create the form in MS Forms. Note that the person who creates the form is the default owner and administrator. To change this, see below.

Note that the format ‘type’ of each question must match the format type in the SharePoint list – text to text, date to date, choice to choice. In this example, the form has four fields:

  • First name
  • Surname
  • Address
  • Date of birth – date field
  • Registration reason – ‘Learning’ or ‘Social’ choice options


By default, internal users with Office 365 licences can respond to the new form without any changes. However, it is possible to allow external users access to the form by changing the settings as shown in the screenshot below. Other options are also visible.


The ‘Share’ option in the ribbon menu does the following, once the form is created:

  • Displays the shareable hyperlink to the new form.
  • Allows the form to be shared as a template, allowing it to be duplicated.
  • Allows the form owner to ‘share to collaborate’, which allows another person access to modify and edit the form. It is good practice to allow at least one other person access.

Create the associated SharePoint list

The associated SharePoint list must have the same columns, and column types, as the form. It may of course have other columns that do not appear in the Form – and the Form may also have other columns that aren’t copied to the list. In this example, the columns are the same.

For the list (named ‘Client Registration’), the original ‘Title’ field was renamed ‘Surname’, and the next three columns are site columns used in the client agreements library.


Create the Flow to link the Form and the list

From the Office 365 application menu, choose Flow. Note that the Flow that is created, like the Form, is ‘owned’ by the person who creates it. Once again, it may be necessary to ensure that others can access the Flow if required.

From the list of available templates, choose ‘Record form responses in SharePoint’.


When this is selected, the next page confirms that the person creating the Flow is authenticated for both Forms and SharePoint. If this is not checked, the Flow will not work. Otherwise, click Continue to create the Flow.

The blank Flow shows a number of options as shown below (described below the image).


  • When a new response is submitted. This will show the list of Forms that the user has access to. In this case, the ‘New Client Registration’ form is selected.
  • Do not change ‘Apply to each’.
  • In ‘Get response details’, select the name of the Form – in this case ‘New Client Registration’.
  • In the ‘Create item’ section, choose the Site Address from the drop down list (again, only what the user has access to), then the List name. This does NOT work for document libraries. When the list is selected, each of the available columns from the list appears below the list name.
  • Click on each column field and a list of fields from the Form now appear on the right hand side. For each list column field, select the matching Form field.
    • Note, for date fields, first click on the search option ‘Search dynamic content’ and type in the first letter of the field (e.g., ‘d’ for Date)

Save the Flow. Now, when a person completes the form, a new list item will appear.

You can now close both MS Forms and also Flow as these only relate to the first part.

List to library workflow – SharePoint Designer

In the example described above, a workflow created in SharePoint Designer first copies the data to one SharePoint list (Client Registration), and that data (or some of it) is copied to a new list (Client Register). Here, we will simply copy the data from the first list (Client Registration) that has been populated from a Form via Flow, to the document library (from where an agreement will be created). The workflow is almost identical whether it copies to the second list or to a library.

Note that it is not yet possible to copy data using Flow from a Form directly to a SPO document library, it must be to a list first.

For this example we are going to create a very simple one-line workflow instruction with no variables. Additional, more complex options are described further below.

  • Open SharePoint Designer and click on the list from where the data will be copied to the library – in this case, ‘Client Registration’ list.
  • Click on ‘List Workflow’ and give the workflow a meaningful name – for example, ‘Copy client data to client agreements’.
  • Choose SharePoint 2010 workflow and click OK.

Now go to the Workflow settings to modify – if required – whether the workflow will only run manually (default) or automatically when a new item is created or modified. In most cases it will be better to run this manually as otherwise the submission of a new form will automatically created client documents, and this may not always be required.

For the purpose of this example, we will leave the workflow to run manually, which means the end user must click on the three dot ‘ellipsis’ menu and choose More – Workflows, choose the workflow and click ‘Start’.

The new SPD workflow is ready to create.


Note that we are copying data from the list to create a new document set in the library NOT a document.

Choose ‘Create List Item’ from the ‘Action’ menu.

When that option is selected, and the new option appears (as shown below), select ‘this list’ and from the drop down, choose the name of the library (in this case ‘Client Agreements’. For the ‘Content Type ID’, change the default option (if required) to the name of the document set content type (in this case ‘Client Folder’). You don’t need to change the variable.


Set the ‘Path and Name (*)’ to the Current Item and select a column. This column will be the name given to the document set so it’s probably a good idea to choose a column that makes some sense.


Now, for each of the columns that need to be copied from the list to the library, click ‘Add’ then set or ‘match’ the columns in both the list and the library document set, as shown:SPD_CreateNewListItemOptions

Click OK and Publish. When the workflow is run (manually) by the end user, this will create a new document set but NOT the document. You will need to have and run the workflow described in my previous post to do that.

Additional options

Workflow settings – Create the document set automatically

If you select the option in the list to library SPD workflow described above to run when a new item is added (from the Flow), it will create the document set automatically. You would still have to run the document set-linked SPD workflow for the documents to be created.

Conditional start – Make the creation process subject to conditions

You may wish to make the creation process subject to certain conditions, using a combination of ‘IF – ELSE’ statements and variables. For example, you could set the workflow to run only if certain metadata conditions are met, or only if the workflow was created or modified by a specific person.

Other actions including email notifications

There is a long list of actions that can be added to the workflow. You can read all about them in this Microsoft guidance.

One common example is to send someone an email provided the email address is copied to the list. The email can contain other column content copied to the list. We used this option regularly to (a) send an acknowledgement to the person who submitted the Form (or list item) and (b) alert the a person or persons managing the list that a new item had been added.