A practical, honest walkthrough of building policy acknowledgement in SharePoint using Power Automate and Microsoft Forms, plus a clear-eyed look at exactly where the DIY approach stops scaling.
If you want to track policy acknowledgements in SharePoint without paying for a separate tool, Power Automate is the most capable native route. With Microsoft Forms, a SharePoint list, and a flow or two, you can build something that genuinely works for a small set of policies. This guide shows you how to build it properly, and then tells you the truth about where it stops scaling, so you can decide with your eyes open.
What you are building
The goal is a record that ties a named person to a specific policy, with a system-generated timestamp, plus reminders for anyone who has not responded. The moving parts are a document library for the policies, a Microsoft Form to capture the confirmation, a SharePoint list to store results, and Power Automate to glue it together and chase non-responders.
Step 1: Set up the policy library and a tracking list
Start with a document library holding your policies, and add a column for the version or review date so you can refer to a specific iteration later. Then create a SharePoint list to hold acknowledgements, with columns for the person, the policy name, the policy version, and the acknowledgement date. Keep the version column on both, since this is the field that will save you when a policy is updated.
Step 2: Build the acknowledgement form
Create a Microsoft Form that names the policy, links to it in the library, and asks the person to confirm they have read and understood it. Configure the form to record the signed-in identity rather than asking people to type their name, so the record points to a real account. Keep one form per policy, or use a single form with the policy as a choice field if you want fewer objects to manage.
Step 3: Write the flow that logs responses
Create a Power Automate flow triggered by a new form response. Have it read the response, look up the submitter, and create an item in your acknowledgement list with the person, the policy, the version, and the submission time. Use the form's submission timestamp rather than a typed date, because a system timestamp is the part an auditor will actually trust.
Step 4: Add reminders for non-responders
This is where Power Automate earns its place. Build a scheduled flow that runs on a cadence, compares the list of people who should acknowledge a policy against the list of those who have, and emails the difference a reminder. To do this you need a defined audience for each policy, which usually means an Entra group or a list of users the flow can read.
Step 5: Build a basic report
Point a view or a simple Power BI report at the acknowledgement list so an owner can see responses. With clean version and date columns you can filter to the current version and get a usable picture of who has responded.
At this point you have a working system, and for a handful of policies and a stable team it can serve you well. It is worth being honest, though, about what happens as you grow.
Where the DIY approach hits its ceiling
The form and the document stay separate. Someone can submit the acknowledgement form without ever opening the policy, so you are recording a claim rather than a reading. No amount of flow logic closes that gap, because the reading and the confirming happen in two different places.
Version drift creeps in. The moment you update a policy, every flow, form, and list column that references the old version needs revisiting. Miss one and your report quietly counts old acknowledgements as current. Reconciling this by hand is exactly the manual work you were trying to avoid.
Maintenance concentrates in one person. A chain of flows, forms, and lists tends to be built and understood by a single individual. When they change role or leave, the system becomes a black box nobody wants to touch, and a broken flow can fail silently for weeks before anyone notices a missing reminder.
It strains past about 80 to 100 staff. With more policies, more versions, and more people, the number of forms and flows multiplies and the reconciliation grows faster than the team. The approach that felt clever at 40 people feels fragile at 200.
The model that removes the ceiling
The ceiling exists because acknowledgement lives next to the policy instead of inside the moment of reading. Close that gap and the rest of the problems go with it. The cleaner model presents the policy on the page, lets the person read and accept in the same view, and writes the acceptance, with the person, the exact version, and a server timestamp, automatically.
That is what Athena's Policy Pulse does inside your existing SharePoint, writing to a self-provisioning list so the audit trail builds itself and targeting through Entra groups so the right policy reaches the right people. If you have already built the Power Automate version, you will recognise everything it does; it just removes the parts that break. The principle matters more than the product: acknowledgement captured at the point of reading, bound to a version, timestamped by the system, does not drift and does not depend on one person's flows staying healthy.
Where to go next
Building it yourself is a good way to understand the problem, and for small setups it is a reasonable answer. If you are feeling the ceiling, see how SharePoint policy management handles acknowledgement natively, read why native tracking breaks down for the wider context, and when you want to compare against your own flows you can try it free for 21 days.
Athena adds policy management, a knowledge base, org chart, noticeboard and more to the SharePoint your team already uses. Per-tenant pricing, no separate SaaS.