Introduction

Power Automate, since it’s recent inception, has been a tool to provide non-developers with the mechanism to define business processes.

Out of the box, Microsoft provide some useful templates to facilitate automation tasks in SharePoint such as Approval; the ability to approve / reject edited content, such as policies and procedures.

About this Article

For all business software solutions, it is very much the case of ‘the right tool for the job’. Power Automate and SharePoint are fantastic tools, but they have limitations. We have have been asked many times why we don’t just use Power Automate instead of developing an App like Read and Understood.

In this article describes an approach for how you might try to produce a Power Automate version of Read and Understood so you can understand the challenges and limitations.

SharePoint Structure

Before we embark on creating our Flows for Power Automate we’ll need to get some structure in SharePoint. To begin with, you may have more than one document library. It’s important to note that for every library you will need one Flow to monitor the changes, be it document Create or Modified.

User Acknowledgement List

You’ll need to keep a record somewhere of every user that is required to ‘acknowledge reading’ of a document. Remember, we will want to capture not only the fact that a user has acknowledged but to also know who was asked to but didn’t - because there will be some that don’t.

The structure of the list will require a couple of custom columns. We can use the out of the box Title field for storing Document Name we’re asking them to acknowledge. You will need a People column to store the employee you’re asking to do the acknowledgement. Also, a Choice field, set required with a minimum of one option ‘Acknowledged’. You might consider an ‘acknowleded with comments’ option so that users can feed back into the editorial process if they spot ommisions or errors. Why not a boolean (yes/no) column? The problem is making the field required, you can’t because the value will always be either Y/N and we need to use to select a value.

Definition List

This is optional, but you might want to think about how you might apply different rules against different content. For example, if you have Policies, Procedures and Guides, you might only want to capture acknowledgements for the Policies and Procedures only.

By using a custom column to store groups you can define the groups of users that need to participate in the acknowledgement process. A special mention for the SharePoint group ‘Everyone except external users’. Be warned this group does not phyically exist anywhere in SharePoint or Azure Active Directory so you can’t parse it for group membership.

If you are to create rules based on content and you’re using content types, then storing the Content Id’s would be a good place to start.

Document Library

One problem with SharePoint Online is that when users edit content there is an auto-save feature in office to keep regular saves of your work. The downside is that this creates multiple versions. If our Power Automate job is going to fire on the change event then this will be a problem.

Consider enabling Major and Minor versioning in your library. You can also include publishing approval. With Major / Minor versioning we can now control the PA Flow to only run if a Major version is created.

Automation

Before you start creating the Power Automate flows consider the following:

Child Flows are a great feature, create small reusable flows rather than trying to create one large flow.
If you have Dynamics 365 with multiple environments, then you have a great advantange if you have a Dev / UAT / Prod as you can manage the development / test / live use of your flows
If you don’t have Dynamics 365 then consider how you can have a Dev site in parellel to your production flows. The same goes for SharePoint site, duplicate your production site to test and build your automation.

User Acknowledgement Request

The first part of the automation is to store those users that are being asked to acknowledge reading the document in the ‘Acknowledgement list’. This PA Flow would be an ideal Child flow taking the following values:

a comma separated string of all the users that are going to participate in the acknowledgement. This can be converted to an Array so we can loop over each user in turn.
document sharing link,
the document name, and
document version

Now we have the data, it’s a matter of looping over each user and:

create a list item in the ‘Acknowledgement list’ setting the value of the columns using the Account, Document Name and Version
Next, we need to create a link to the record created in step 1
Send the user an email providing instructions and a link to the list item + document.

Document Definition Flow

Assuming you have different rules for different documents in your library, you may want to create a child flow to determine the documents to process. This would take a parameter of the Content Type Id of the document being processed. With this we perform a query looking for record in our ‘Definition list’ that has the same id.

The record that is returned has a People/Group picker that defines the groups we wish to use. By using groups we have a simplified approach to storing users. In our flow, to get the members of a group we can use Microsoft Graph.

For each group defined in our column, repeat the process of querying Graph for the users and store them in an array that we can pass back to the parent flow.

Document Major Version Flow

Bring it all together we can now have a single flow that will manage the process of calling the child flows. Firstly, we need the flow to run when a document is modified, however, as pointed out earlier we only want to process Major versions so if it is a minor version update - simply exit.

When we know we have a major version to process. we can:

Create a sharing link - be careful as you could be giving access to users that don’t have access, intentionally.
Call the child flow for the Definition list - this will return our users that we need process
Call our User Acknowledgement Request flow with:
1. The list of users,
2. Sharing link
3. Document Name, and
4. Document version

Challenges

Permissions

While we create list items for users to capure their acknowledgement of reading a document, it’s possible that everyone to see each others items. In addition, another user could acknowledge a document on someones behalf. One solution would be to secure the item to that user, which could be done having created the record. See securable item limit below.

List view threshold

SharePoint invokes a list view threshold and while the modern interface is great at dealing with this, if you want to produce reports across your User Acknowledgement List you may find that your list breaks and you can’t produces views of data e.g. Document ABC version 1.0 even though it might be for 10 or so records, if the list view is exceeded you can’t apply the filter.

Another Version Published

It happens. A major version gets published and the emails go out only for someone needing to make a change or add something else. This will trigger a new set of emails and list items. What happens to the previous items? You could delete them.

New Users added to Groups After Document Version Published

When you have new employees join or people move between departments they’re likely to move between AAD Groups. The issue here is that we want our automation process to pick these users up as being new members of the group and get them to read and acknowledge the documents.

Error Handling

Often, this gets forgotten but it has to be considered. Microsoft document transient errors and cloud computing. When something goes wrong, and it will, you need to be able to recover a situations. This may mean rerunning an automation job but have it pick-up from where it left off - this is difficult in Power Automate Flows without parsing what was done before..

Read and Understood Solution

All of what is described above, and more, is achieved by Read and Understood. We choose not to use SharePoint lists to store data, but instead use a dedicated SQL database to avoid Microsoft limitations.

Start by reading an introduction to Read and Understood …

Having worked with SharePoint since 2003 we have seen organisations implement the document management features of SharePoint in many ways. Some organisations just opt for version control, others go much further by implementing records management and other SharePoint features. In many cases the use of document libraries is prolific with the focus being on the association of content based on the perspective of its origins (often departmental). This is where most organisations stop, with the implementation viewed as a job done because all the documents are now in SharePoint and covered by one or more of SharePoint’s document management features.

But no matter how well controlled documents are in respect to their publication, review and editorial cycle; it's very often that the end user, the consumer of the content, that is left to find publications that are new or updated on their own devices.

SharePoint does offer solutions to this with Alerts, custom Workflows or Microsoft Power Automation - Flow. These are either too granular to configure and administer on a large scale to cover all users or require skills that most end users just don’t have. Therefore, after working with SharePoint for over 17 years, we decided to develop Read and Understood for SharePoint.

Read and Understood implements processes that keep users informed of new and updated policies, procedures and any other key documents without the complexity of custom workflow or arduous administrative overhead to manage Alerts on a company wide scale.

Q. In your opinion what are the main challenges faced by organisations needing to publish Polices and other key documents?

To save repetition the term key documents will be used in the remainder of this post to refer to Policies, Procedures and key company documents.

1. Ensuring the right employees read the key documents

As soon as a key document is approved and published its good practice to ensure that relevant employees have a chance to read it. Using SharePoint to control and publish is a great start but you still have no idea who’s read the document. Sending paper copies used to be a solution, getting users to sign the document, in years gone by but they typically just piled up on desks due to time constraints. Read and Understood was created so organisations maintain complete control over key documents by having controls to target specific groups (SharePoint or Azure Active Directory) of users with email-based notifications. Notification is the Read and Understood equivalent of a SharePoint Alert, with some significant enhancements. Management of Notifications is configured through a Settings List to simplify administration. Configuring a notification is as simple as writing an email; use relevant groups or individual employees to receive the email. Our quick start templates for the notification emails will provide the user with the information, provided in the template, including a link to the document.

Read and Understood provides two levels of Notification:

Notification - an email with details of the key document that’s been added or updated.

Acknowledge reading – the user is required, using a link in the email, to confirm they have Read and Understood the document. Through the Settings List you can define rules that sets how long users will have to acknowledge the document, during that time if they have not acknowledged then reminders can be sent. Read and Understood keeps a full audit trail of each document and its version cycle detailing who did or did not acknowledge within the allocated time. A report email is sent to key document owners summaries the information at the end of the cycle.

2. Smart user management for new starters and internal movements

All Read and Understood features can use a combinations of Azure Active Directory (AAD) user accounts or groups and/or SharePoint groups to notify users.

When Read and Understood enters its notification cycle, triggered by a new or updated document, it will ensure any new members of the groups are included in the notifications.

3. How much effort does it take to get Read and Understood add-in up and running?

With over 30 years’ experience in implementing 3rd party solutions we're acutely aware that the setup for any solution can be arduous and time-consuming. Read and Understood administration has been designed to ensure that implementation effort is kept to a minimum but of course this does depend on how your content is structured in SharePoint.

Read and Understood is administered through the creation of items in a Read and Understood Settings List working with one or more (no limit) document libraries in a site collection.

Read and Understood is an add-in that that is added to the SharePoint App Catalog. Once added and deployed, sites can be added to the sites you wish to enable it.

To enable Read and Understood notifications involves the following steps to be taken:

Identify all the document libraries that contain your key documents
Add the Read and Understood for SharePoint Add-in
Enable Read and Understood on the libraries identified in step 1
Define the type of notification you want to send, who should receive it by assigning the appropriate groups or users. If you want to, tailor the email message using the rich text editor to style it or get the message you want across.

That’s the end of this post and I hope you’ve found it informative and thought provoking.

Power Automate an alternative to Read and Understood App?