When you manage a critical SharePoint list, you need to know who changed what and when. Manually tracking edits is error prone and time consuming. SharePoint does not log list changes to another list by default, but you can build a reliable audit trail using Power Automate. This article explains the best settings to log SharePoint list changes to another list, covering triggers, actions, and key configuration options.
Key Takeaways: Logging List Changes with Power Automate
- Power Automate trigger “When an item is created or modified”: Starts the flow when any existing item is edited or a new item is added to the source list.
- Action “Get changes for an item or a file (properties only)”: Retrieves only the changed columns, reducing log size and improving performance compared to fetching all columns.
- Action “Create item” in the audit list: Writes the change details to a separate destination list for long-term tracking.
How the SharePoint Change Logging Feature Works
SharePoint itself does not offer a built-in setting to automatically copy list changes to another list. The native version history stores all changes inside the same list, but it does not push those changes to a second location. To log changes to a separate list, you must use Power Automate, a Microsoft 365 workflow service that connects SharePoint to hundreds of other systems.
The core mechanism is a Power Automate flow that triggers every time an item in the source list is created or modified. The flow then captures the changed data and writes a new entry into a dedicated audit list. This audit list can hold a permanent record of who changed what and when, even after the source item is deleted.
Prerequisites for Setting Up the Logging Flow
Before you build the flow, you need the following:
- A SharePoint site where you have at least Edit permissions on the source list and the audit list.
- A source list that contains the data you want to track. This can be a custom list, a document library, or any standard SharePoint list.
- An audit list that will receive the change records. This list should have columns for the changed field name, old value, new value, change type, timestamp, and the user who made the change.
- Access to Power Automate from your Microsoft 365 app launcher or directly at make.powerautomate.com.
Steps to Configure the Change Logging Flow
- Create the audit destination list
In your SharePoint site, create a new custom list named “Change Log” or “Audit Log”. Add these columns: Title (single line of text), ChangedField (single line of text), OldValue (multiple lines of text), NewValue (multiple lines of text), ChangeType (choice: Created, Modified, Deleted), ChangedBy (person or group), and ChangeTime (date and time). These columns will store the details of each change. - Open Power Automate and create an automated flow
Go to make.powerautomate.com, sign in with your Microsoft 365 work account. Select Create from the left menu, then choose Automated cloud flow. Give the flow a name such as “Log list changes to audit list”. - Add the trigger: When an item is created or modified
Search for the SharePoint connector and select the trigger “When an item is created or modified”. Provide the site address and list name of the source list you want to monitor. Set the trigger condition to run for all changes, not just new items. - Add an action to get the changed properties
Search for the SharePoint connector and select the action “Get changes for an item or a file (properties only)”. Set the site address and list name to the same source list. For the Item ID, select the ID dynamic content from the trigger. This action returns only the columns that actually changed, which keeps your audit log clean and efficient. - Add a condition to handle new items vs modifications
Insert a Condition action. On the left side, select the dynamic content “Trigger Outputs” and then “Is new item”. Set the operator to “is equal to” and the value to “true”. This separates the logic for new items and modified items. - Configure the “If yes” branch for new items
Inside the “If yes” branch, add a Compose action. Set the input to the dynamic content “Create time” from the trigger. This captures the timestamp. Then add a Create item action targeting your audit list. Map the columns: Title = dynamic content “Title”, ChangedField = “All fields”, OldValue = “N/A”, NewValue = dynamic content “Title” (or other relevant fields), ChangeType = “Created”, ChangedBy = dynamic content “Modified by”, ChangeTime = output from the Compose step. - Configure the “If no” branch for modified items
Inside the “If no” branch, add an Apply to each loop. In the input, select the dynamic content “Changed Properties” from the Get changes action. Inside the loop, add a Create item action for the audit list. Map the columns: Title = dynamic content “Title” from the trigger, ChangedField = dynamic content “Display name” from the loop, OldValue = dynamic content “Old value” from the loop, NewValue = dynamic content “New value” from the loop, ChangeType = “Modified”, ChangedBy = dynamic content “Modified by” from the trigger, ChangeTime = dynamic content “Modified time” from the trigger. - Save and test the flow
Click Save, then select Test. Choose Manually and then Test. Create a new item in the source list and then edit an existing item. After a few seconds, check the audit list for the logged entries. Verify that the ChangedField, OldValue, NewValue, and other columns are populated correctly.
Common Mistakes and Performance Considerations
The flow logs all columns instead of only changed columns
If you use the standard “Get item” action instead of “Get changes for an item or a file (properties only)”, the flow will retrieve every column value, even if nothing changed. This creates a very large log and slows down the flow. Always use the dedicated Get changes action to capture only modified columns.
The audit list grows too large and slows down
An audit list that logs every change for years can exceed 5,000 items and trigger list view throttling. To prevent this, add a scheduled cleanup flow that deletes records older than 90 days, or create a retention policy in the Microsoft Purview compliance portal to automatically delete old entries.
The flow fails when the source item is deleted
The default SharePoint trigger does not fire when an item is deleted. To capture deletions, you need a separate flow that uses the trigger “When an item is deleted”. That flow should read the item ID from the trigger, then write a deletion record to the audit list with the ChangeType set to “Deleted”.
Power Automate Flow vs SharePoint Native Version History
| Item | Power Automate Change Log | SharePoint Version History |
|---|---|---|
| Storage location | Separate audit list | Inside the same list |
| Survives item deletion | Yes, if deletion is logged separately | No, version history is deleted with the item |
| Customizable columns | Fully customizable | Fixed columns (version number, date, editor) |
| Performance impact | Minimal if using Get changes action | No additional load |
| Requires licensing | Power Automate license (included with many M365 plans) | No extra license needed |
You can now set up a Power Automate flow to log SharePoint list changes to another list. Use the Get changes action to capture only modified columns and keep your audit list manageable. Add a separate flow for deleted items to maintain a complete record. For long-term archiving, set a retention policy in the Microsoft Purview compliance portal to automatically delete old audit entries after 90 days.