Approval processes for document and knowledge management can be tricky. There are a number of options and a huge amount of combinations depending on your specific requirements. Each organization will have their own unique needs and procedures, some governed by what has worked in the past, by best practices, or by legal obligation.
This article aims to provide an overview and insightful deep-dive into the world of out-of-the-box approval options for documentation within Atlas. It will cover:
SharePoint OOTB Approvals
In Atlas it is possible within a document or page library to turn on Content Approval from within the List or Library settings > Versioning settings. Change this toggle to "Yes" to turn on approvals:
We also recommend, if approvals is switched on, that the Major/Minor versioning settings are switched on too:
Once Content Approval is switched on, an additional column is created that shows the Approval Status for the document and will appear in the default library view. This is automated and there are four possible statuses; Draft, Pending, Approved, Rejected.
- Newly uploaded documents will have ‘Draft’ in this column (if Major/Minor versioning is switched on)
- Draft documents submitted for approval will appear as Pending
- Approved documents will appear as Approved, and if approval is turned on when the library is already in use, existing documents will appear as Approved.
- Rejected documents which have not been approved, will appear as Rejected and that draft version will remain as a minor version.
The combination of Approvals and Major/Minor versioning will ensure that any document is in a Draft State (minor version 0.1) when first uploaded.
- Drafts are not picked up in Search
- By default, drafts cannot be seen by Visitors; only by Owners, a Member if they uploaded the document, and optionally all other Members. This can be controlled through the Library Versioning settings but we don't usually recommend allowing Visitors to see drafts:
For a draft document to be approved and appear in Search as a Major version they will need to be ‘published’ – i.e. submitted for approval. This is done via a button in the SharePoint action ribbon:
For a draft page to be submitted for approval you can do the same as above from the Site Pages library, or from the page itself click Submit for approval in the top right:
Once submitted for approval, with submission comments, the document/page will show as "Pending".
- No notification is sent to ‘approvers’ so this can be set-up OOTB using the "Alert Me" function, or by an automated email reminding approvers or owners to review all pending documents.
- Submission comments are not mandatory and the notice cannot be edited.
Pending items will need to be approved by someone with appropriate permissions. For documents this must be done from inside the Library against the specific document (right click > More > Review approvals). For pages you can do the same as for documents, or from the page itself click Review approvals in the top right:
The options for the approver are: Approved, Rejected, Pending. The approver can leave their comments against any of these choices.
- Notifications back to the original uploader are not sent
- Rejected documents are left in ‘draft’ state (minor version), and will need to be resubmitted for approval
- Pending documents are left in ‘pending’ state for subsequent approval (minor version)
Once Approved, the document will become visible in Search, available to all users with permissions, and will gain the Major version number of 1.0, 2.0, etc.
Any changes to approved documents, including metadata changes such as title or tags, will restart the submission process for approval and make that change a new Minor version (i.e. 1.1, 2.1).
The change will not be visible in search as it’s a minor version, however, the previously published Major version will remain open and visible unless either removed (through Version History) or the new minor version changes are approved and published as a Major Version (i.e. 2.0, 3.0)
- The screenshot below of the Version History against the document - we can see that the Major version of 1.0 is published. This is the version users see.
- A change has been made to the document and has been captured in a new Minor version (1.1). This change is in draft and not visible to end users, as such, the previously published Major version is still the one visible to end-users (shown through the 'This is the current published major version' text):
- Notes & Considerations
- Major/Minor versioning and approvals do not apply to Folders
- There is no Expired option
- No notifications are sent or produced OOTB
- Approval Status options do not show up in the document/page itself - this is a metadata field only, but because Draft versions are by definition not Published, you cannot query this in search. If you need to filter by Approval Status in search this may not be possible because only items with the status Published will be searchable (other statuses will be Minor versions).
- To show Approval Status in specific Library views as a column, filter or sort order you can do this as this does not rely on search.
It is possible, and also common, for content managers to ‘self-approve’, so each time they upload a document they approve it themselves – perhaps because they are responsible for the content and metadata but also to save time if no ‘external’ approval is needed. However if this is the case you may want to consider whether it is useful to force the user to approve at all.
Changes to metadata will induce a new version and draft, so it’s important as part of the approval process that the metadata and tag selections are correct, not just the content of the document. Perhaps even the document location in the folder structure should be considered.
Library Views can be made to group/show documents with a specific status (i.e. pending documents) and links can be produced to send users to these views.
The below flow diagram outlines a standard approval process with SharePoint approvals, where:
- Document uploaded in draft state, minor version (0.1)
- Document sent for approval
- Approver approves or rejects
- IF approved, major version 1.0 is published and available
- Document is edited and new minor version created (1.1)
- Document sent for approval
- Approver approves or rejects
- IF approved, major version 2.0 is published and available
Atlas Status Column
In each Atlas content type we have an optional column called ‘Status’. This column can be filled with choice fields, such as; Submitted, Live, Expired. Whatever is needed in your own terminology, a flexibility the SharePoint approval process doesn't allow.
- Please note this is just a choice field called Status - there is no special functionality mapped in. Ideally this will need to be built out into a process.
This column is created per workspace (as options in the 'site columns' site settings), so we usually recommend to template the options in the source workspace to ensure for consistency.
This column can be very helpful if users are to mark documents in their desired state, however it is a common scenario for this to be automatic in some way so that there is no dependency on regular manual reviews to change the status.
This column is not automated OOTB, and is not synced to the SharePoint Approval Status process or functionality. This can create a situation where, if both are used, the SharePoint approval column says ‘approved’ but the Atlas Status column could be blank or left on the default option if configured that way, or if a mandatory field may be ‘Pending’ which would be incorrect (as technically the document is 'approved' from the SharePoint Approval process).
This creates a situation where you have 2 fields to manage, and of course altering the Atlas Status column after approval has happened will put the document back into a draft state.
- In the screenshot below...
- The first row has no value in the Atlas status column but has been Rejected.
- The second row seems incorrect as although the Atlas status is Approved, the SharePoint approval status is Draft. Perhaps this draft is an edit but the original document is still approved and still valid
- The third option is matching and should be correct, unless of course that document has in fact expired and not been actioned accordingly on the platform.
- The fourth row should be correct depending - as expired documents should go back in to draft:
A common use case for the Atlas Status Column is so that an 'expired' value can be leveraged, to mark when a document has expired. This usually goes hand-in-hand with a separate date field, usually called either 'Reference Date', 'Review Date', or 'Expiry Date'.
- For the following examples, we will assume a date field has been leveraged or created to help manage the review process for a document.
If both status columns are to be used to take advantage of all the functionality available any ‘Expired’ status option triggered will need to be calculated from the 'Review Date' column set. We can calculate our status field to match the SharePoint Approval Status column or it can be done manually
If this ‘expired’ option is triggered and is to turn the document into draft and remove it from search, this needs to be actioned accordingly; the previous Major version which was approved may need to be removed as well, as the 'expired' document has a previous Major version which will still appear in Search for users. You may need to use Power Automate to automate this process, otherwise it will require an additional manual action for content managers.
- That is to say, when an 'approved' document becomes 'expired' in real life (opposed to functionally on the platform), the update to the Atlas Status column to make it Expired is a change and produces a new minor version of the document – someone would need to remove the previously published major version to remove the document from search.
- Selecting the expired choice in the Atlas Status column or resetting the review date will produce a new draft minor version and will need to be approved.
Atlas Status options do not show in the document itself, but CAN show in search on the cards itself by switching on the Show status option, see top-left corner on each card in the below screenshot:
We often recommend to use this status column but without the SharePoint approvals/versioning switched on, so the content managers have more freedom to mark things as they need to, altering regularly if necessary but without the need for draft/submit/approve processes or for managing major/minor versioning and notifications. This might be a good option for those areas where the Teams are self-sufficient and do not need outside approval from another team or area.
To help with this process, a date field can be leveraged, and a page set-up to show the documents that are approaching their expiry date. A call can then be made by content managers against each document, to have the expiry date reset and stay approved with no changes required, or, marked as expired, and actioned accordingly, usually by:
- Replacing with a new document
- Removing the document from search entirely
If SharePoint Approval status is switched OFF this can all be done very easily, however if it is switched on, expect that every change needed to a document will need to go back through the approval process which can create extra work, especially if many documents are expiring at the same time.
Power Automate
Power Automate is an app in Microsoft 365 where you can build any workflow you want - we will refer to these as flows. It is ideal for automating manual processes and steps.
Any flows needed will be managed by your IT department or respective owner with Power Automate experience or understanding. ClearPeople does not provide any Power Automate services, as this is a specialist tool which can be complex to implement and maintain depending on the requirements.
- However, we have a trusted implementation partner who specializes in Power Automate flows, tools, support, etc. who we can put you in contact with if required.
Flows are managed on a per site basis and need to be maintained separately if you use the tool as provided by Microsoft, but there is a ClearPeople recommended third party product which can replicate and re-apply a ‘master’ flow to multiple libraries for more efficient centralized flow management.
Flows need to be maintained. If you only need 1 flow for 1 workspace, this can be built and managed easily as a standalone exercise, however if you need to apply multiple flows to multiple sites this will need to be strategized. A test workspace with the master flow should be set-up for building and testing without impacting live end-user-accessed workspaces, and a training workspace with the flow can also be set-up for the content managers to practice in.
Flows can be triggered per new item, per folder, on a timed basis, or manually submitted by a user when needed. This selection would be driven from the requirements in play.
Due to the customized nature of workflows, the amount of options available do not necessarily reduce the complexity of assessing or building required options.
Power Automate can be an extremely helpful way of automating processes, but these processes need to be understood by the content managers and consistent across the area the flow is set to.
Flows can automate processes to make it easier for users, but can induce complexity elsewhere – either in IT or in a reality that doesn't match what the flow is doing
- For example, if there is a flow that, when the review date is hit, changes the ‘Atlas Status’ to ‘Expired’, sets the SP ‘Approval Status field to ‘draft’, and deletes the previous Major published version, and then sends a notification email or Teams message to specific people with a link to the document. It will do this regardless of the scenario in question, and undoing this can be awkward. So, if this wasn’t needed and the review date was incorrect, the content manager will need to go and reset the Review Date to the future and also reset both status’s to approved. If they don’t, the document will no longer be visible in search and questions might be raised as to where it’s gone. Flows do not provide rectifying actions - there is no undo button unless you design an additional "undo" flow!
Technically the flows are separate from the site and the content. You can assign a relationship and the flow can influence the content, and actions to content can start a workflow, but it is implied via configuration, not built in as a built-in feature of the site. As stated in the first point, Power Automate is a separate app.
Power Automate can do things that aren’t possible OOTB by providing access to custom features, third-party tools, and flows. For example, flows can add watermarks to documents, or even publish word .docx files as .pdfs. There are hundreds of actions for interacting with other M365 or even 3rd party apps (if you have Premium licensing).
There can also be cost implications to running flows (although not much) as Microsoft usually has a ‘pay as you go’ model for running power automate flows, as they take up more processing time to action. You will get some number of runs for free as part of your M365 licensing, but depending how many flows you run per month you may need to pay for additional runs.
For a simple approval workflow which pushes the approval process via the Microsoft Teams Approval app, please check this article.
Expiration / Archiving process (depending on your definition)
What happens to a document when it’s expired? We may need to combine some of the points and logic written in all above sections in order to answer this question, but we can create a process for any desired action or procedure using either manual options or Power Automate.
Depending on the document and area there might be different rules. Some considerations:
- Moving a document will create a new URL
- Renaming a document will create a new URL
- Moving a document with the OOTB 'Move To' SharePoint action keeps the version history AND the tags from the source destination (which depending on the scenario could either be useful or a drawback)
- Without SP Approvals = Marking the document as ‘expired’ doesn’t do anything OOTB
- A new document can be uploaded to replace it if it has the same name
- With SP Approvals = Making an expired document as ‘draft’ will restrict access to the new version but any previous major versions need to be removed as they will still be accessible. URLs will no longer work but the content and it’s version history will still exist
- If a new document is uploaded to replace it will be uploaded as a new version in draft and will need to be approved itself.
- If a replacement file does not have the exact same filename as an existing document it will be added as a new document, so the ‘expired’ document will need moving or actioning – maybe even renaming so it says DO NOT USE or EXPIRED, with the URL broken as the name has been changed.
- Leaving the document there even with the name changed could be a risk, it is usually better to remove it if it should no longer be used.
- Technically the only way a file can be ‘hidden’ from Search for everyone is to hide the document library, so a dedicated document library either centralised in a new workspace or one in each workspace can be leveraged
- Moving the document to this 'hidden from search' document library will break existing URLs, but new URLs can be provided/requested, and users will be able to access directly from the document library and static links can be built into the page or pasted in pages as text, etc, but will not be in Search (which may or may not be a problem depending on the user scenario)
- Removing permissions will restrict access, either via URL or via Search, but breaking permissions on a file is a custom action, and you cannot remove permissions for Owners, so this approach does not ‘clean up’ the document library as you go and over time it will become harder to manage as there’s no identifier to show which files have which permissions.
- We would advise to try and leave permissions as consistent where possible, using a separate folder or workspace to control permissions on files.
Combinations
It is possible to combine logic, best practices and approaches mentioned above from all four sections. There will be rules and guidelines which will need to be followed if using SharePoint Approvals, and combining this with the Atlas Status column can not only extend the functionality, but also induce complexity due to the considerations needed in managing both columns. Of course, you can automate the relationship between these columns using Power Automate.
It is likely a combination of approaches might be most attractive, however considerations will need to be outlined depending on the scenario and requirements needed. For example, the number of documents being submitted for approval or how often documents expire will influence decisions. Approving 100 documents per year by 2 people, all in the same month, is much more easily managed manually than 100 documents per month from 10 people, and therefore may not require any automation.
The larger the volume of approvals and expiry processes, the greater the need for Power Automate, but this effort saved over the long term by automating the process will need to have time and consideration given at the start when considering, building and testing the automation. Saving complexity in one area can often add to another.
Need more assistance?
To discuss these options in more detail, and for additional assistance with building a solution which fits your requirements and approval scenarios, please get in touch with your Atlas representative.
Comments
0 comments
Please sign in to leave a comment.