This post is part of a series where we examine the advantages and disadvantages of a document approval process, and then build an example automated solution with SharePoint and PowerAutomate.
Posts in this series:
- Should you automate your document approval process?
- Building a basic document approvals automation with SharePoint and PowerAutomate
In a previous post (Should you automate your document approval process?) we examined two document approval and publication solutions, one with and one without automation, and discussed whether it was worth the effort to implement automation.
In this post we present an example automated document approval and publication solution using SharePoint and PowerAutomate.
Solution overview
Lets take a closer look at each step in the above process.
In this solution, individuals collaborate on documents in authoring groups.
Each authoring group has its own SharePoint Team Site where members are able to create and modify draft documents.
When an authoring group completes their work on a draft document, they use SharePoint to run a PowerAutomate Flow which will orchestrate the review and publication of the document.
The flow will send an email with choices to the approvers for the authoring group asking them to review and approve the document. The email will include a link to the document to help the approver begin their review.
If the approver is satisfied with the document, they click the Approve option within the email sent to them, directing the flow to continue publishing the document.
The flow uses functionality provided by OneDrive to produce a PDF version of the document.
The PDF document is uploaded to the Published Documents Repository (SharePoint Communication Site).
The PDF document, hosted on the Published Documents Repository is readable by all users within the Microsoft 365 organisation.
Solution technical constraints
Trade offs are a fact of life when designing any IT solution. Technology choices in one area of the solution will constrain options available to us in other areas.
Some of the constraints identified below could be alleviated by introducing bespoke Pro Code components created by software developers using Azure and other technologies, but our current requirements call for keeping the solution in the No Code / Low Code domain.
Dedicated document library for each authoring group
For this solution, it was desirable for members of an authoring group to be able to launch the Approve Document PowerAutomate Flow for a selected document in their SharePoint Team Site. To launch a PowerAutomate flow in this way, users must have Edit permissions on the document library they working in.
The requirement to have Edit permissions on the document library meant that we couldn’t host a single ‘drafts’ library for use by all authoring groups. The need for Edit permission at the library level would have allowed the different groups access to each other’s draft documents and would have cause those documents to appear in M365 search results.
The solution is to assign each authoring group their own SharePoint Team Site where members of the group can have Edit permissions without the possibility of impacting the work of other groups.
PowerAutomate Flow required for each authoring group
PowerAutomate Flows can be triggered from SharePoint document libraries, but such flows can only be triggered by a single library – they cannot be shared across multiple libraries.
Since our solution has a constraint that all authoring groups have their own SharePoint Team Site (and therefore their own document library on that site) then we need to create a PowerAutomate Flow for each individual authoring group.
Approvers must have at least read access to an authoring group’s SharePoint Team Site
In this solution, approvers will be sent a link to any document they are asked to review. The link will only be useful if the approver already has read-only access to the document.
In many cases this access requirement will be addressed by the approver also being a member of the authoring group.
The Flow must have at least read access to an authoring group’s SharePoint Team Site
Once a document has been approved, the flow will carry out actions to produce a PDF version of the document. These actions will need read access to the document.
Building the solution
In the pages that follow, we walk you through the process of building a basic document approvals and publishing solution.
In this solution we will need the following resources:
- A single SharePoint Communications Site to act as the Published Documents Repository (PDR).
- For each authoring group, a SharePoint Team Site to act as the group’s collaboration space for the preparation of draft documents.
- For each authoring group, a PowerAutomate Flow to orchestrate the document approval and publication process.
The example actors in the solution
The above resources will be owned or accessed by various individuals and groups. The following describes those actors from our example solution.
Owns the Published Documents Repository (PDR) SharePoint site.
Owns the flows which orchestrate the document approval and publish process.
Requires write permission to the PDR.
Requires read permission to all authoring groups’ SharePoint Team Sites.
Approves documents produced by the Finance authoring group for publication to the Published Documents Repository.
Members:
- Alex
- Henrietta
Requires a SharePoint Team Site as a collaboration space to prepare draft documents.
Group members have edit permissions on the document library within the SharePoint Team Site, meaning they can launch PowerAutomate Flows associated with the document library.
Create the solution resources
Testing the solution
The post linked to below shows a walk-through the the solution’s functionality.
Conclusion
The example automation solution presented fulfils the business’ requirements and is something any organisation with Microsoft 365 could deploy today.
However there is definitely room for improvement! But these improvements likely increase solution complexity or require an increase in technical expertise to deliver.
- The set of approvers for each authoring group is hard-coded in the relevant flow. An alternative solution might look up approvers from a SharePoint list, making it easier for an administrator to keep up to date.
- As the solution scales out to more authoring groups (e.g. departments) we have to keep copying and amending the ‘trigger’ flow. For large numbers of authoring groups, it is worth looking at bespoke software development to trigger the approval process rather than adding more duplicate flows.
- Duplicate flows are laborious to update. Changing the text in the email sent to all approvers would necessitate an update to each flow in the solution.
