Custom Logging in Power Automate

Easy, practical DIY approach using SharePoint Online lists

📅 Originally published January 1, 2025 - hamsandwich.dev

---

Examining Events, Errors and Outcomes

Handling errors gracefully within your flow logic is important. Fortunately, there is plenty of guidance to be found on the subject:

• Error Handling - THE FLYING POLYMATH

• Try Catch - D365 Demystified

• Error Handling Standards - Matthew Devaney

How can we investigate exceptions without wading through countless pages of flow run history?

If integrating with Azure Application Insights is not in scope and the information available within the Automation Center is not granular or specific enough, consider custom event logging.

Scenarios / Use Cases

• 🏭 Performing bulk content operations and a certain percentage of failures is expected
• 📆 Building a solution that involves chronological activities and events
• 🧺 Collecting flow errors in a centralized location, instead of relying on “push” notifications
• 🤖 Providing visibility to runs from higher environments or from a service account context
• 🖥 Displaying flow outcome data adjacent to the automation context (for SPO scenarios)

Log List Examples

Approval Event History

Scheduled Automation

Bulk Content Sync

Creating a Log or Event List

Columns

There’s no perfect recipe, but I usually include a column for each of these values:

• Run outcome (success, error, warning, etc.)

• Outcome details

• Associated item title

• Associated item ID

• Flow run ID

Then, add additional columns for your specific logging scenario, as needed.

💡 Keep in mind, simplicity is the goal here. Use single-line text columns whenever possible - avoid choice fields or complex data types (lookup columns, etc.)

For ALM scenarios, you may find adding these helpful:

• Flow name
• Solution name
• Environment

Configuration Tips

1. Disable search on the list (advanced settings) or restrict list permissions to only the relevant individuals/audiences

   

2. Index any columns that might be needed for sorting/filtering

3. Include a multi-line plain text column, if you’d like to store JSON output

   

4. Create view(s) and add custom column formatting, if that helps readability

5. Examine the list after log entries start to populate - you may think of another field or two worth capturing

Cloning an Existing List

Assuming custom logging proves useful, you may want to create more lists in the future. You can use an existing list as a template, to speed creation. Some options:

• ShareGate migration tool

• Use an existing list option in the SharePoint UI (under site contents)

  

• Microsoft Lists

Adding Logging Actions

Once your list is ready, it’s time to add some flow logic. New log entries will be added using a Create Item action.

There are two general approaches for adding logging steps - both achieve the same result, but have different considerations.

Add to Existing Flow(s)

You can sprinkle logging actions within your existing flow logic, utilizing copy/paste.

Pros	Cons
Simple, fast approach	If the list schema changes, you may need to update (and find) all previously-added actions
No additional licensing cost	Cannot add additional actions later (like sending notifications) unless done manually
Can store complex data types, JSON
Uses existing SharePoint Online connection / reference (if present)

Create Standalone Logging Flow

Alternatively, you can create a separate flow (HTTP trigger or child solution flow) to store your logging steps:

Once created, invoke it from existing flow(s) as needed:

Pros	Cons
Much easier to extend later, if needed	Additional setup time and complexity
Can handle complex data types (HTTP trigger only)	Requires premium licensing (HTTP trigger only)
One logging flow can be shared by multiple solutions / flows	Need to collect and send parent workflow context
Option to run asynchronously - won’t hold up parent flow

💡 Don’t forget a Response action (for HTTP trigger flows) or Respond to Power Apps or Flow action (for child solution flows)

Other Notes

• Consider disabling retry policies whenever a standalone logging flow gets invoked or a Create Item log action is called. You don’t want to hold up a parent flow run in the unlikely event that logging hits a snag.

• For logging hierarchical flow outcomes, consider creating an entry for when the parent begins, ends, and every child iteration in between. Store a shared identifier (like parent flow run ID) to help group entries later.

  

• Calculating overall flow run duration, error and success totals, etc. can add additional value to the last log entry for a given flow run. Don’t spend the time adding that logic unless the extra insight is worth it, however.

• You can use the logging technique described on this page to store errors / exceptions only, or you can include successful outcomes and other event types, depending on the situation.