Showing posts with label SharePoint Governance. Show all posts
Showing posts with label SharePoint Governance. Show all posts

Monday, May 21, 2018

OneNote Compliance, Records Management, and Governance - O365

Scenario
  • OneNote (part of the Office 365 suite of tools) is used to store information that may be considered records (official information)
  • Your compliance or governance teams may want retention, legal holds, or other policies configured on these records
Issues
  1. Mixed Content: OneNote notebooks contain mixed content with differing record policies.
    • Ex: Meeting minutes in one section, project info in another, and issues in a third section.
    • You cannot apply policies at the page level.
    • Note: This issue is the same as any other document containing mixed content (Word, Excel, etc.), however it is easier to use OneNote in this manner.
  2. Time Span: OneNote notebooks contain content spanning multiple days, months, or years
    1. This means disposition policies may not apply correctly, delaying or accelerating policy dates
  3. Legal Holds: Legal holds may inadvertently block an entire notebook from being editable
  4. Incompliant Locations: If  OneNote usage is discouraged or blocked, records are more likely to end up in  incompliant locations and users may experience broken integration features
    1. Incompliant alternatives: Notepad saved locally, Evernote, cell phone pictures and voice memos (Office Lens), emails, other online services, a personal OneDrive OneNote account, or a locally stored OneNote
    2. To avoid OneNote, users would also need to ignore the extensive OneNote integration features provided in Outlook, Windows, and the other Office products.
    3. There is not a good alternative note-taking tool that would better meet compliance policies.
Solutions

1. Mixed Content

OneNote notebooks with records should live in SharePoint, not in OneDrive or on a file share.
  • SharePoint allows for version tracking at the library level
    • Note: This is in addition to the limited OneNote versioning.
  • SharePoint also allows content policies to be applied at the section or Notebook level
OneNote notebooks with differing compliance policies should be split into separate notebooks
  • The policies should then be applied at the notebook level

2. Time Span

Notebook policies should be applied based on the parent SharePoint site policy whenever possible and should be defined based on the overall work being done. 
  • Example: A notebook for a project would last as long as the policy for the entire project.
  • Example: A team site notebook would expire when the team was disbanded.
  • Example: A department level knowledge-base notebook should not auto expire unless the department goes away.  A separate policy for archiving historical content can still be put into place.
Users can also be trained to export and archive specific content using any time frame required by your policies.  Users may automatically be assigned tasks to remind them to do this.
  • Example Policy: Meeting minutes should be exported quarterly to PDF format and minutes deleted from the notebook for the prior quarter.
  • Example: Project notebook should be exported yearly to XPS or PDF formats.

3. Legal Holds

For legal holds that block edits, records living in OneNote should be exported to an appropriate format (PDF, Word, etc.) and the hold should be applied to the exported document which would then be the official record and not block additional modifications to the entire notebook.  An alternative approach is to export the entire notebook and place a hold on the exported copy.  This issue applies to all document types that are actively used, but may be more impactful for OneNote if mixed content is contained in the notebook. 

4. Incompliant Locations

The best solution is to provide the user with compliant locations that are easy to use.  This can be done by provisioning SharePoint sites and OneNote notebooks for common records management use cases.  In this way, notebooks will already be split by appropriate policy groupings and correctly configured for versioning and compliance policies.

Restricting usage and adherence to best practices is the hardest to control and must be enforced through user training.  Some incompliant locations may be blocked by IT through firewall rules, but users can always get around these by using their own mobile devices.

Tuesday, July 19, 2016

Restricted Edit Event Receiver - SharePoint 2013

Scenario
  • You need to restrict edits to a document library based on the current value of a field.
  • Full trust farm solution for SharePoint 2013 scoped to Web.
Solution
  • I created a configurable event receiver that will restrict edits (metadata and content) based on the value in one of the document's metadata columns.
  • Additional feature: Delay implementation of the restriction for a number of seconds from Created Date to allow for additional automated processes to update new documents.
  • Additional feature: Exclude a document from the restriction based on a regular expression using its  filename.
  • Additional feature: Automatically populate the Title field (or other text field) based on another choice or text field.
  • Open-Source code is available here:  RestrictedSave ZIP
    • Feel free to modify and use this code.  You may not resell it or a modified version of it as part of a packaged solution without my permission.
  • Disclaimer:  This will only prevent edits that trigger the item updating event receiver.  Some programmatic and 3rd party API calls made using bulk edit operations, workflow actions, or other event receivers may bypass the event receiver.  In addition, this code is not hardened for high security scenarios and is only meant as a first line defense against unwanted typical user edits.
Installation
  • Download the RestrictedSave WSP file and deploy to your farm.
  • Enable the Restricted Save feature on your sub-site.
    • Feature Description:
      Configured via the RestrictedSave list. If this site does not have one, a RestrictedSave list will be added. Document libraries named in the RestrictedSave list will not save a file if the user is unauthorized and the assigned column contains a certain value. If no required permission is specified, then the field can only be edited if the restricted column's value is changed. Multiple document libraries, columns, or values may be configured but must exist in this subsite. Optional New File Delay and Regular Expression Exclusion may be configured as well. Will also set the document title and/or filename based on a choice field by using the 'Title Choice Field' columns.
  • Configure the RestrictedSave list that was added to the site according to your needs.
Example

  • A standard configuration of the RestrictedSave list to restrict edits on a document library named "RestrictDeleteTest" when the "LOBType" column is set to "Choice 1".

  • The resultant error displayed on a document's edit properties form in the "RestrictDeleteTest" library when a filename modification is attempted.


  • Error Message in clear text
UNABLE TO SAVE! -- When column "LOBType" is set to "Choice 1" the item is locked and cannot be updated. -- Please work from a new copy or change the column value.





RestrictedSave List Configurable Fields
  • Instructions are provided in-line on the form.
  • Add one line for each restriction.  All lines will be parsed for each document edited in the sub-site.

--------------------------------------------------------------------------------------


And again in text format for search-engines, visually impaired, and copy/paste:

Document Library Name *


Column Name


Column Value


Required Permission To Edit

   

New Item Delay Seconds


Title Exclusion Regex


Title Choice Field Name


Title Choice Target