Atlas Recommended Approval Scenarios

This article aims to provide an overview to some of the most common approaches to approval scenarios in Atlas.

Please be aware, this article is not a functional overview of the options available. We need to assume an understanding of both SharePoint and Atlas approval, versioning, and expiry options available in order to provide brief overviews. If you do not yet know enough about this functionality and terminology used, please consult the starting article for approval options here - Document Approval Options in Atlas

1. Guidance
2. Scenario 1 - SharePoint OOTB Approvals with self-approval
3. Scenario 2 - SharePoint OOTB Approvals by somebody else/another team
4. Scenario 3 - Atlas Status column with Expiry Date column for finalised versions (No SP Approvals)
5. Scenario 4 - Custom Power Automate flow
   1. What is Power Automate?
6. Conclusion

Guidance

After much debate on the best way to present and document the options available, ClearPeople consultants have agreed that there are some baseline scenarios which are most common, but that approvals are not a ‘one-size-fits-all’, and with so many possibilities in both function and process, it is best to discuss requirements at length, before suggesting which option may or may not be suitable as there are many variables.

Things to consider may include but are not limited to:

• Current approval processes
• How strict is document management?
• How large is the content management team? 2 people or 10?
• How much content do you expect to approve each month?
• Any outside pressures for requirements e.g. regulatory, legal, ISO, compliance
• Importance for end-users to see ‘approved’ status? Or just for management purposes
• Is versioning needed to formally track changes?
• Is communication about changes and alterations done through the submission and approval process, or is it discussed and validated offline?

Scenario 1 - SharePoint OOTB Approvals with self-approval

This scenario involves switching on the SharePoint OOTB Approvals with Major/Minor versioning and Drafts. Unique functionality applies here and must be followed

• If approval is needed within the content management team (no external approval), we recommend turning SharePoint OOTB approvals on and controlling the versioning and publishing of documentation through the OOTB features provided
• Uploaders will approve the documents themselves as soon as they are uploaded
• Library views should be set-up to group documents into Draft, Pending and Rejected so these non-approved documents can be viewed and managed more easily – without displaying the folder structure if necessary
• The ‘Alert Me’ emails within SharePoint should be set-up for email notifications (daily or weekly summary) or an automated email with a link to the library view (above point) is sent each week as a reminder Documents are created offline or managed as a draft whilst WIP
• Documents are identified as needing to be replaced or updated ‘manually’ by the team and managed ‘in-house’ with no functional marker
• No bespoke fields or columns needed in order to manage and approve content, just the SharePoint OOTB 'Status'

Advantages

• Straight forward self-managed process
• Small changes can be managed 'in house'
• OOTB Atlas document content type can be used

Disadvantages

• No expiry column or function
• Each major version approved overrides previous version’s approval comments

Scenario 2 - SharePoint OOTB Approvals by somebody else/another team

This scenario involves switching on the SharePoint OOTB Approvals with Major/Minor versioning and Drafts. Unique functionality applies here and must be followed

• If approval is needed from a party not directly involved in drafting content - just reviewing once submitted for approval - we recommend turning SharePoint OOTB approvals on and controlling the versioning and publishing of documentation through the OOTB features provided
  • • For example, if a marketing coordinator drafts a document they need to send it to the Head of Marketing for approval. The Head of Marketing, although in the same Department, is not in the same team, and therefore has no input into the document until they receive it for approval. They might have been aware a new version or an update was coming, but will need to review the changes prior to approving. No one else can approve.
• Uploaders (members) will submit the documents for approval as soon as they are uploaded, or work on them in draft format and submit for approval once completed
• Approvers (owners, or approver permissions level) will approve the documents within an agreed time
• Library views should be set-up to group documents into Draft, Pending and Rejected so these non-approved documents can be viewed and managed more easily – without displaying the folder structure if necessary
• The ‘Alert Me’ emails within SharePoint should be set-up for email notifications (daily or weekly summary) or an automated email with a link to the library view (above point) is sent each week as a reminder
• Documents are identified as needing to be replaced or updated ‘manually’ by the team and managed ‘in-house’ with no functional marker
• No bespoke fields or columns needed in order to manage and approve content, just the SharePoint OOTB 'Status'

Advantages

• Requirement for 'outside' approval is met
• Notifications are possible via email
• OOTB Atlas document content type can be used

Disadvantages

• Small changes need to wait for approval
• Delays to approval can cause bottlenecks or ungoverned or not-up-to-date libraries
• No expiry column or function
• Each major version approved overrides previous version’s approval comments
• Simple alert email is sent OOTB. It will not contain what has changes or where

Scenario 3 - Atlas Status column with Expiry Date column for finalized versions (No SP Approvals)

This scenario involves configuring some options for the 'Atlas status' column. Some common examples might include; 'Active', 'To be Reviewed' or 'Expired', but this has no bearing on version or functionality - it's just a mandatory choice which needs to be filled in and manually managed accordingly.

• Ideal for smaller teams that are 'on-top' of managing their information and documentation
• Easy process to configure and to understand
• Great value and effective if used properly
• If an expiry date and expiry column is needed, we recommend both of these columns are utilized but with the SharePoint approvals left switched off (excl. major/minor versioning)
• OOTB Atlas Reference Date field can be used to track potential review date. If a different expiry date column is needed, a new content type will need to be built
• Utilizing the date and the Atlas status column, the content managers can manage expiry manually without the need for approvals. We usually assume close attention is paid to the documents which need changes and the 'status' of existing documents, so this is a common scenario for content which is not regularly updated but has to have a review date which acts as a driver for review and updates
• The approvals should be done pro-actively offline before documents become expired. There is no draft option so any document uploaded will be visible to all users with permissions. It is possible to build a list in a page which shows 'upcoming expiry's' to help with this process - this is always our recommendation
• It is sometimes also recommended to have a 'Published' document library to house approved content which is available to everyone, and a Work In Progress (WIP) or Draft document library where draft and in-progress content is being drafted and is not yet readily available for consumption - likely only visible to the team managing the content. This is useful as there are no draft and no approvals, so the functional management of content still only requires a 'light-touch'. This is done by limiting the permissions of the WIP/Draft document library. The publishing process of moving content from one library to the other is also straight forward utilizing the SharePoint OOTB 'Move To' feature. Atlas Date or Reference Date field can then be used for managing the 'date of release' or 'published date'.

Advantages

• No SP approvals for easier management
• Functional marker for expiry using Atlas Status column - where customized fields can be created
• Expiry date column can help track the management of information and content - this aids governance
• Small changes can be made easily
• Can use OOTB Atlas content type
• Date against content can be utilized for 'last review' date

Disadvantages

• No draft option, so all documents are live
• No approvals - so assume all documents have been reviewed and are correct
• No automated marker for when a document was published or when it was updated, as any changes will update the 'modify date'
• No notifications for 'upcoming' expiry's

Scenario 4 - Custom Power Automate flow

If the draft and versioning OOTB SharePoint function is required for document management, and an expiry date is needed, we recommend switching both on and utilizing Power Automate to manage these fields more automatically. If both are switched on (merging scenarios 1 or 2 and 3), there can be conflicting scenarios and adds pressure on the content management team to follow an exact process, with any deviation impacting the versioning history and becoming more 'technical' to sort out.

For example, if a document is approved in SharePoint and published, but the Atlas Status was still left as 'draft' or 'expired', any changes to this Atlas Status column to correct it will result in a new draft version of the document from SharePoint Approvals, and either the changes aren't published or the approver needs to approve again.

We have found in our experience this does not 'work' and users will not like to use the system and the overall quality of process, documentation, information, tagging, etc, as well as the team moral and motivation, will decrease.

To help automate these decisions to a defined process which leaves less opportunities to make mistakes or become confused, Power Automate can be utilized to undertake the appropriate rules for your user scenario, taking pressure off the team to do everything flawlessly. It can basically do anything and can even do custom actions not possible OOTB (such as publishing with a Watermark), so no matter how complex your submission or approval process, Power Automate can handle it, but if you are new to this Microsoft service, it is worth reviewing the information below as well as the advantages and disadvantages to understand more.

What is 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.

Advantages

• Any workflow can be written
• Ongoing complications can be saved by spending time building the initial power automate flow
• Workflows can be triggered automatically, or manually, and different flows can exist for different things. Different flows can even target different Submitters, Folders, or Document Type - all from within the same Library
• Workflows can be dynamic so 'roles' can be used instead of 'people' i.e. Colleagues that = Marketing and = Manager in their Azure Entra AD User Profile
• Custom notifications can be drafted in HTML, with information from the updated content
• Submission comments and approval comments can be written
  • • And even sent to subsequent approvers or placed in the document itself
• Teams Approvals App can be utilized
• Users to not have to fuss or perform extra actions, just submit the flow manually if not automated
• It is reliable and will not deviate from desired workflow
• Flows can be tracked

Disadvantages

• Although flows are very cheap they do cost money to run
• Workflows need ongoing maintenance and updates
• Workflows are usually managed by IT departments so a potential bottleneck or dependence is created to another department
• Power Automate could get complicated depending on your scenario. If it is complicated to perform manually it will be complicated to build and manage, and if there are multiple variables which follow one another a number of possible flow outcomes might need to be written (i.e. if it is a 3 step process which rely on 3 yes or no decisions, 3 Boolean options creates a wide number of possibilities which all need to be mapped, built, tested, and maintained.
• If workflows fail or do not complete, it is likely a notification is not sent and users or content managers or approvers will not know a flow has failed unless specifically made aware - so an assumption that everything has worked fine becomes the norm when this may not be the case

Conclusion

With so much to consider in terms of function and process, the correct approach needs to be considered carefully, with extra thought given to the key users who will be following or utilizing the process and related functionality, because although the process and functionality will work in practice, if it is not undertaken or followed properly - or used at all - in reality, it actually doesn't work and won't provide the anticipated return on investment either in time or simplicity.

Taking the above into account, if the solution is used and used properly, there is no 'wrong' way to do things as long as requirements have been met, but it might not be the optimum or easiest way, but if it works for you and the team - who is to argue!

To be honest, in our experience of discussing these available functions and possibilities in regards to approvals specifically, around half of our clients will say 'don't worry actually, we'll just manage it carefully with no need for approvals, versioning, status's, etc'. Because this is actually the best way for them. They thought approvals would be best, but it turns out it is just extra work with no additional value provided, especially if there's no requirements which needs to be met either legally or regulatory wise.

That being said, if there is a legal or regulatory requirement, this is enough to warrant a more defined process following one of our scenarios above, but the outcome will be process orientated and subsequent to a number of discussions, tests, validation and eventual roll-out with training.